The Shadow DOM {Frontend.Darkside}

For March 6th 2025, it's the Lullabot podcast. 

Hey everybody, It's the Lullabot Podcast Episode 2-7-3 I'm Matt Kleve, Senior Developer at Lullabot with me, co-host of the show, front end developer, Morgan Eck. Hi, Morgan
 

We're literally sitting across the table in Palm Springs, California right now. 
It's beautiful. 
 

We end up on Zoom calls and you know, we're on the same project together and we end up talking but never like this. 
 

No, this is very intimate. 
 

I'm glad to be here. 
 

You hail from Idaho? Yes, Boise. 
 

And it's much colder there today than it is here. 
 

It is. 
 

Although it's a little overcast here, I miss the sun. 
 

One time a year, the company gets together. 
 

We have a company retreat. 
 

We talk about things that are going on in the company and how to make work better. 
 

We're very lucky to be here. 
Yeah. 
Yeah. 
And since we're here, we try and we try and bring in some folks and create some good podcast content for all of our listeners. 
With us today, we have lead engineer Andy Bloom. 
Hello. 
From Minster, Ohio, middle of nowhere. 
But I guarantee the weather here is nicer today than it is in Ohio. 
Yes. 
But not by as much as I would have hoped. 
We've both put sweatshirts on. 
Yeah. 
But it's still kind of sunny and little bit of a breeze. 
It feels like spring. 
You smell the flowers. 
The clouds rolling down the mountains here. 
Yeah. 
Yeah. 
That's tomorrow. 
It's going to rain tomorrow, but whatever. 
We're here to talk today about Shadow DOM, a little bit about web components. 
It's kind of changing the way a lot of people are building the web using reusable components. 
And Andy has been on a project doing a little bit about that work. 
Yeah. 
And I've heard some about that in the past. 
I just thought it'd be a good idea to bring him on and we can both become a little more educated Morgan. 
Most definitely. 
We're not doing that. 
I have no familiarity with Shadow DOM elements. 
Tell us what are those. 
It sounds really like James Bond or something. 
It does. 
Yeah. 
I know when I started working with them, it felt like it came out at the same time as one of the seasons of Stranger Things. 
It was kind of like the upside down. 
The Shadow DOM was the upside down of the web development world. 
Yeah. 
So Shadow DOM is part of a suite of APIs in the world. 
A web platform that are generally grouped together into what people call web components. 
And there are some people that don't like the term web components because it does group kind of three things together all at once. 
The first of those three is custom elements. 
So in HTML, you have PTAGs, ATAGs, H1 through 6, all of those things. 
Blink, marquee. 
Yes. 
Sure. 
Used to. 
Yeah. 
Showing your age there. 
Yes. 
And so with custom elements, what you're able to do is create new HTML tags and tell the browser this is an HTML tag and this is how it works and what its internal properties are and what it does when you interact with it in some way. 
And so that's custom elements API. 
And then another part of the web components package is the template and slot elements. 
Those are new native ones. 
And they kind of help bridge the gap between your custom elements and the third part, which is the Shadow DOM. 
And the Shadow DOM is an API that lets you create kind of almost new HTML documents within an HTML element. 
So if you think of the DOM, the document object model, if you open up your inspector on a browser, you see HTML and the head tag and the body tag and you have all of that. 
The main HTML document. 
That structured tree that we're all used to by writing HTML. 
Yeah. 
And so you've got that. 
And then what you can do is with the Shadow DOM, you create a new subtree and you can attach it to an element. 
And so that could be a custom element, like whatever your web component is. 
But it's actually part of any element. 
You could put a Shadow DOM in a div if you wanted to. 
You could put it in a-- there's lots of-- I'm not sure-- actually, I have to stop my head if there's any limitations on what you can attach it to. 
There's an attached Shadow method on the element class. 
What does that do? It creates a new Shadow root and attaches it to that element. 
So it's the actual instantiation of a new document subtree and then attaching it to that element. 
OK. 
So we're going to create an element in the Shadow DOM and we're going to do that how? So with JavaScript, you can select some element. 
So document query selector, whatever your ID is on a div. 
So we have a div idea of-- --food. 
Right. 
So document query selector, pound foo. 
You get the reference to that element and then you can call dot attach Shadow and pass in several options. 
The main one is the mode, whether it's open or closed. 
And what that does-- Whether it's visible or not, then? It's a little fuzzy. 
So we'll get to that in a second. 
So when you attach a Shadow root, when you attach the Shadow DOM, what you're doing is you are creating that new document subtree. 
And then within the browser's memory, linking that subtree to the node that you're attaching it to. 
So it's almost like an iframe, how you're embedding a document inside of another document, but you have a lot more control. 
Yeah, that's a pretty good way to think of it, I think. 
So with an iframe, you have to define a source to some other HTML thing. 
It's going to make a new HTTP request and pull that document and shove it into wherever you've got it. 
But with Shadow DOM, you're programmatically creating that new document. 
You're not going and fetching a new thing and then adding it in. 
You're creating that new tree. 
And if you've defined a custom element to do this, it can then declare whatever its internal markup is. 
So if you wanted to do a-- You could do a video player where you have your component's name is video player. 
It has some kind of a source attribute. 
So you'd have some kind of a source attribute to the video resource. 
And then when that element is put in the DOM, it goes through and calls its constructor method. 
It creates its own Shadow DOM. 
And then inside that Shadow DOM, it can add in the video tag that we already have in a native HTML. 
And so instead of having to worry exactly about how you might want to read and use a-- Sorry, I'm trying to think about how to say this in a way that's not so ranty. 
You can rant. 
I think rants are encouraged on the podcast. 
So let's envision you're working in a design system. 
And you want to have a video that plays. 
And you have a set of buttons that control that video. 
You could go through and mark up a component that does it. 
And you have to put that same document or that same element structure everywhere. 
And then you have to wire these buttons to this video and these buttons to this video. 
But if you create a web component that does that, you can just pass it the video source that you need. 
And it's able to say, oh, I know all the things that I need within me. 
I need this set of buttons. 
I need to be able to play a video. 
And it's able to wire all that up. 
And then you just have one encapsulated unit that you can put in several places and not worry about them getting their wires crossed. 
This is something we talked about a few weeks ago, Andy, because it was something I wanted to add to a project. 
So I became an expert because I read like three websites in 10 minutes. 
So I kind of remember somebody using that video player example because browsers are actually doing this with the native player in the browser. 
They might be. 
Yeah. 
They might be. 
I don't know for sure. 
I thought maybe it was something you came up with because it was the way it worked. 
No, actually, I think the one that stands out to me as far as something that works similar to how web components work is the details element. 
So if you write something with a details element, you can put a summary tag within that. 
And then it acts kind of like a native HTML accordion. 
And it has within it, I believe, a closed shadow DOM that alters how things behave within it. 
And you're able to target certain things using the marker pseudo class pseudo selector. 
Yeah. 
So I mean, there are definitely overlaps in how web components work with some native elements. 
And it wouldn't surprise me if video was one of them or audio or other media ones. 
So did this come around an HTML5 then? No. 
That's a really good question. 
So HTML5, I guess, yes, it came around an HTML5 in the sense that we're still technically in HTML5. 
But it was not there when HTML5 was the new hotness. 
Which was a long time ago, correct. 
Right. 
And actually, actually, so it's not even HTML. 
The HTML spec is about the way that you write HTML code. 
It's about the text formats and the syntax in there. 
The shadow DOM shadow root is an API within browsers separate from, but interacting with HTML. 
It's also not part of JavaScript. 
JavaScript is like, if you look at Node.js, there's no, there's no such thing as the document, Node.js. 
Because it's, the document is an API that's part of the browser. 
For relying on browsers to do their job, do we assume they're all doing the same thing at this point? Or are there issues across browsers when we're doing this kind of thing? Four things that are ready to be done in production. 
We're pretty comfortable with how browsers do things. 
Handy. 
It's very nice. 
There are some things that are cutting edge and that Chrome's working on adding this thing because it serves Google's idea of what the web should be and Safari's working on other things. 
Because they're working on a lot of color functions and stuff in CSS because they want to be serving the creative and pushing their monitors that can do different color spaces. 
Firefox is struggling a bit, I think it doesn't really have a big corporate backer and so they're working on other things. 
But the shadow DOM is pretty at this point of baseline. 
We started off mentioning web components and a lot of that you think about reusability and portability of different components is that that all comes into play. 
It does, yeah. 
React came on the scene in web development in like 2013. 
And just after HTML5 probably. 
Yeah, fair. 
Wow. 
It's been a minute, right? Yeah. 
It feels so new, but it's been a while. 
I just remember HTML5 stickers at DrupalCon Denver, which was 2012. 
Wow. 
Like that was the coolest thing to have an HTML5 sticker on your laptop. 
Now it just tells people how old you are. 
And along with CSS3, right? Yeah. 
They're talking about bringing back the version numbers for CSS for a long time. 
CSS3 was kind of complete and they would add the different modules, but they're talking about now there's been so much growth since what CSS3 was that if you're looking at job posts and they say, well, you'd CSS3 is like, what does that include? Yeah. 
All of the new stuff that's come out since then. 
So much. 
I wrote CSS3, you know, back before Lullabot had front end developers on staff. 
Yeah. 
So that tells you how old it is. 
Flips and tables. 
Oh boy. 
Oh boy. 
So, yeah. 
So, you know, React comes on the scene in 2013. 
And the whole idea of React and all of those kind of JavaScript frameworks was how do we make front end development faster? How do we make it so that we're able to do development and we can prototype things out more quickly? And so around that same time, we saw things like bootstrap going out and they had their own idea of what a component was. 
But around that time when all these things were coming out, we saw this kind of paradigm shift in front end development away from table layouts, away from floats, away from just how do we make these super structural things or floats which were really abstract and hard to plan around? Yeah. 
How do we create these little subsections of a design and reuse them in a bunch of places where they're all uniform and they all match and we can get this nice thing called a design system with reusable components that manage their own internal state and whatnot. 
So React did that and React kind of created that and made it that paradigm fit for a lot of people and JavaScript after a while caught up and was, you know, yeah, components are a good idea. 
What would be a good way for the web platform to handle components and web components or custom elements, Shadow DOM and the template and slot APIs kind of filled that void. 
Awesome. 
We're talking web components. 
We're talking Shadow DOM. 
In Palm Springs, California, together as a company at the Lola Bot Retreat. 
Coming up, we'll talk about how this integrates with Drupal. 
Many sort of problems that might arise from using this new fangled stuff right after this. 
Welcome back to the Lola Bot podcast. 
We are with Andy Bloom today talking about Shadow DOM elements. 
Yeah. 
Good to have you here, Andy. 
Hi, Andy. 
I'm Andy Bloom. 
I'm Andy Bloom. 
I'm Andy Bloom. 
I'm Andy Bloom. 
Yes. 
That's my third retreat. 
My highlight is always karaoke for sure. 
Of course, you didn't sing any songs or anything. 
No, only like six, you know, and also on the sidelines, singing everyone else's songs as well. 
Maybe sometimes louder than them. 
And that's something that's interesting is like the support that's kind of built in with our teammates. 
Like the fact that it's nobody's embarrassed to go sing karaoke because everybody's just as silly as everybody else. 
There got up there. 
I mean, of all people. 
I won't tell her secrets safe with everybody who's listening. 
I love the chance. 
So in the evenings, a couple of times, there are talks and storytelling where people talk about whatever they want to talk about. 
And usually it's like an ignite style presentation. 
The original idea was everybody in the company had to do something. 
So it was like that we're going to limit people to just a few minutes so we can get in and get out. 
Even if you go quick, we're big enough now that I think it would take too long. 
Yeah, but the diversity of like, you don't have to talk about anything specific. 
Andy, you talked about how to how to be a better bolder. 
Yes. 
Yes. 
Right. 
Yes. 
And that has nothing to do with our work. 
But we kind of got the flavor of Andy as a person, which we don't necessarily get, you know, across the... 
I'm very reserved. 
I don't let people see. 
No, that's not true. 
No, you get funny ones. 
Sad ones sometimes. 
It gets pretty real. 
Sometimes learning about everybody else. 
It's an awesome thing. 
But today we're learning about web components and the Shadow DOM. 
Tell me how this kind of thing relates to single directory components. 
We just had a podcast about that and learned all about single directory components. 
I mean, so they relate in the fact that they're both about doing components, right? So with SDC, you are defining a set of markup in Twig. 
You have some styles in CSS within that same directory. 
You might have some JavaScript in that same directory. 
And all three of those play together into how a component renders on a page, how it presents with its styles and how it behaves with interaction in other parts of the page. 
And web components can do that same kind of thing. 
Generally, though, web components would be written all as a single file instead of within a single directory. 
When I'm making a web component, typically I'm reaching for a framework like Lit. 
And what Lit allows me to do is author a file in TypeScript. 
And then the styles can also be in that TypeScript file and the markup can also be in that TypeScript file. 
They don't have to be, but they can be. 
And then the web component knows based on some of the helper functions in that framework what markup to put within the Shadow DOM when it mounts the page, how to style those elements within the Shadow DOM. 
And how to handle interactions with the various parts of the Shadow DOM. 
- So you don't need a YAML file defining all of your parameters. 
- No, there is no YAML. 
There's no YAML in Lit anyway. 
So what you would be doing is you would be authoring a JavaScript class typically. 
And JavaScript has a long, weird history in how it's written. 
Classes are kind of a syntactical sugar is the way that I've heard of it. 
And you don't really have classes in JavaScript. 
You've got functions that have prototypes. 
And it's all weird history stuff because since JavaScript is in the browser and the browser needs to just work all the time, there's this long commitment to backwards compatibility. 
But I would be authoring a class for a new element. 
And that class could have props. 
That class could have its own methods. 
And so then when the element is put on the page, something else could interact with it by saying, hey, that component used this method or modify this property to be this value. 
- When have you seen web components used absolutely correctly? This is the way to do it. 
- I would hesitate to call anything absolutely the right way to use web components. 
It's just another tool in the toolbox. 
- So where are their strengths? - Their strengths are in being self-contained components that are usable accordingly. 
And across platforms, you could use it in Drupal. 
You could use it in Joomil. 
You could use it in WordPress. 
You could use it in a static site generator. 
You could use it anywhere you want to. 
- So a large organization that might have a wide web presence that isn't necessarily technically the same. 
- Correct, yeah. 
So in the case that we were using them, we had them for a design system that was built for a large client that had multiple channels. 
They had a big monolithic CMS that they were using web components on. 
And they also had smaller auxiliary teams that were building stuff in React. 
And React was able to then use the web components instead of rebuilding the component in React for themselves. 
And then having maybe two separate implementations that don't quite behave the same, that maybe don't quite look the same, that maybe don't quite interact with the rest of the page the same. 
- So a marketer or a branding person would love this because they can make sure their websites are fairly consistent. 
- Absolutely, yeah. 
- The design system and there's just, because you're using the component itself and not bringing in a whole bunch of additional styles to style that component, instead of copying and pasting in the markup, copying and pasting in the CSS, copying and pasting in the JavaScript, and then making sure everything ties together the right way. 
It's all bundled as one unit and there's kind of technical guardrails in place to keep that design system enforced. 
- And does that integrate with a storybook so that you can visualize these components - Yeah, we had a storybook for these components. 
You know, storybook is an app built in React and they have lots of different ways that you can-- - Which we talked about with single directory components, right? So we're kind of cuddling those waters again. 
- Yeah, and so right, 'cause what storybook is there for is to be a display showcase for your components and how you can customize them with various properties and content. 
And being able to model those outside of the scope of your application or website or whatever. 
- It's noisy around here, isn't it? - Yeah, that's what you get when you sit outside, I guess. 
- Normally we can just talk smack about somebody's office, like, "What are you doing, man? "Your house is noisy, but now everybody's noisy." - Yeah. 
- 'Cause we're here together and we're sitting outside 'cause, you know, Southern California. 
- You have to, we're going, we're all going home to snow, so we have to soak it up while we can. 
- The trash truck came by, I went by, I think we're good now, Andy. 
Sorry to interrupt. 
- Okay, what was the question? - I don't remember. 
(laughing) I think we're talking storybook. 
- Yeah, storybook. 
- Yeah, so storybook allows you to drop in the web components. 
And, you know, there's storybook, you can set up storybook to just render HTML if you wanted to. 
And so, there's lots of different ways to do storybook. 
There's, you know, there's other options, there's, you know, pattern lab, I think still exists, fractal, I think still exists. 
There's lots of different products that do the same thing, but the idea is the same is that you've got this showcase of all the components that you've built, and you let people kind of toy around with them in this isolated environment and figure out, is this the component I want to use in this place. 
- So how do we start dropping things into Drupal? How would we do that? - Sure, so once the web component is built, and sure we'll call it in storybook, once it's ready for use, all you really have to do is make sure that in Drupal you bring in the JavaScript file that defines that web component. 
Because it's gonna, you have to create that JavaScript class and you've got to register that class with the browser using custom elements.define. 
And so you tell it this class and this tag name which has to have a hyphen in it so that we don't ever have to worry about clashes between the custom elements that we're writing and anything that HTML may add in the future. 
And so that file has to exist within some library that's attached to the page. 
And then you've got to use that tag name that you've specified somewhere in your markup. 
- Wrap it in any of your twig files and have it called up for a field or an entity or a block or a page or a region or wherever that makes sense to use in your Drupal installation. 
- Is that with an embed and include or is it, you're just putting a class on the existing element? - It's not a class because you're not converting, it's not like you're putting a div on the page and then converting it into a web component. 
You have authored a custom HTML tag that is the open angle bracket, my dash component, close angle bracket. 
- Blinkier. 
- Well, but it has to have a hyphen in it. 
- Oh, okay. 
- So, most people, when they're building a system of web components, just standardize on a single prefix. 
So we could do, you know, LB dash blink if we wanted to make a blink web component. 
- So is having a namespace like doing an LB dash, is that a common pattern? - That's a common pattern that I've seen, yeah. 
- You asked earlier, where do I think web components have been done right? And I think one place that's a good example to look for if you'd like to see web components in action. 
And if you'd like to dip your toes in the water without actually authoring them, there's a component library called shoelace. 
And I believe the URL is shoelace.style. 
- Fancy. 
- Yeah, very nice. 
- I'll link to that. 
- And they've, well, and depending on when you're listening to this episode, that may not exist anymore. 
Because shoelace has been purchased by the same people that did font awesome icons. 
- Yes, okay. 
- And so they're kind of rebranding all of the shoelace components to, I think, web awesome. 
And I don't know what the URL is for that. 
- Maybe they'll reroute it though, you know. 
- Yeah, throw a redirect up there. 
- Yeah. 
- But they're a component library similar to what you might see from like a bootstrap, where it's, here are components that you will see very frequently in any standard website. 
They have an accordion with their set of properties and methods. 
And you can have them, you know, put multiples in together and demo them and that kind of stuff. 
They have tabs, they have drop downs, they have tool tips. 
And they're, at least as shoelace, they're fully open source. 
I imagine web awesome is also going to be open source. 
I would hope it would be open source. 
If you would want to go in there and peek at, you know, how is this component authored and what's it doing and what's it rendering within its shadow root? And how are they doing that and kind of get an idea of maybe patterns to follow? Because I think, in my experience, they've done it pretty well. 
- So if this is all browser side then, how does that go with performance? - That's a really good question. 
And is one that I think people don't necessarily jump straight to and they should. 
We were talking about React earlier. 
And React has gotten better and more performant. 
And a lot of the world around React has kind of gone from do everything client side back to, hey, can we render some of this React on the server and do it server side? And there's some of that as well in the web component world. 
There's a, what is it called? I think Behance, I think is what it's called, is something about trying to render web components as you can server side and then shipping down what was in their shadow root to the browser. 
And they have like some wasm stuff. 
So like if you were to, you could theoretically render your JavaScript web component through PHP, I'm not sure. 
I've never done the server side rendering stuff with that. 
But the. 
- It sounds like we're asking the browser to do a lot. 
- We do ask the browser to do a lot. 
And because your component is defined in JavaScript, and because of the way that JavaScript is implemented with the browser, you get a single thread. 
It's able to do one thing at a time. 
And it takes breaks while it waits on things. 
If it needs to do a fetch request or Ajax or whatever, it's able to do other things while it waits for that callback method to come back. 
But if your UI is entirely based on rendering everything through JavaScript and attaching Shadow DOM and creating these elements and dropping on the page, you could very quickly run into performance issues where you're less performant than just using HTML and CSS. 
So web components are a tool, but I would not call them the way that everything should be done by any means. 
- Turns out HTML is still good. 
- HTML is still really good. 
Browsers have been rendering HTML for, and the tech world eons longer than, - It's kind of what they're meant to do. 
- Exactly. 
- It's why you have a spec that's locked in stone and you get new versions of it, but there you have the backwards compatibility. 
I forget what the question was that we were trying to answer there. 
- Performance. 
- Yeah, we were talking about performance, yeah. 
- And I would imagine that would help with consistency. 
If you're handling more of it on the server side, not relying on someone's browser, someone's like, you know, maybe they haven't updated it lately or it's not. 
- Yeah, so the browser, I mean, at this point, web components are standard enough across the major browser vendors that I don't think you're gonna run an issue with somebody's device or phone not being able to render them. 
- Well, yeah, I mean, technology is kept up. 
- Yeah. 
- The phone in my pocket is stronger than my phone in my pocket two years ago. 
- Exactly. 
- And my laptop does a good job. 
People around the world may not have access to such technology, depending on what your target audience is. 
- And with Drupal being market or labeled as a digital public good, it's doing websites that need to be able to serve users that have slow connections. 
It needs to be able to serve users with inconsistent connections. 
It needs to be able to serve users with low powered devices or older devices. 
If you look at the browser usage statistics that are out there and you look at Africa, you look at big chunks of Asia, Eastern Europe, there's parts of the world where the devices don't have the same juice that we have here in the United States or in parts of Western Europe. 
And if you lose the connection, that part also weighs in. 
If you don't get the full JavaScript file that defines your component, you've got a broken UI shipped and now people can't buy your thing or they can't access your service or they can't access a critical government or education or news. 
If we're trying to serve, there's a natural disaster and here's where you go to get help. 
- Anything else that we should add, Andy, on the topic? - The answer about Shadow DOM and web components is that because we were talking about how you've got the main page document and then we're making a new one that's attached. 
When you put into your document the link and it's the for CSS files and you bring in a CSS file, CSS is scoped to the document to which it's attached. 
And what that means is that if you've defined some kind of markup in the Shadow DOM, check a class on that element and let that rule set inherit through. 
There are some things that do inherit any CSS property that inherits by default will pass through the Shadow DOM. 
- So stuff in my Shadow DOM element is not going to get my page CSS. 
So my list-- - It won't get all of it. 
- It'll get part of it, but it won't get all of it. 
- What parts will it get? - So if you created a, if you were making a UI and you put one web component on, then you had text nodes in your Shadow DOM within that markup. 
The font rules that style that font will come through because font family, font weight, font size, those all inherit by default. 
If you declare CSS variables, those custom properties and their values will inherit by default. 
So those will pass through the Shadow DOM. 
- This must be because of that's the way the browser is handling it or something. 
I'm trying to understand that a little bit. 
- Yeah, I don't know the exact reason behind it and I don't love it. 
There's something of a movement for people that do author a lot of web components trying to render stuff within unofficially called the light DOM. 
Not in the Shadow DOM, put it in the main page document. 
Can you render stuff just within that web component so that your CSS rules do apply the way you'd expect them to? So those inheritable properties, the ones that inherit by default will pass through. 
But if you have a CSS rule for dot my class and you put that class within the Shadow DOM, that rule set doesn't pass through. 
So you would need to then figure out a way to re-declare that rule set in the Shadow DOM. 
- That's kind of pain. 
- It used to be for Safari was the last one to get up to date. 
You used to have to put an actual style tag or you had to put a style tag within the Shadow DOM. 
But now everything uses adoptable style sheets which is a way for you to programmatically add CSS style sheets to a document. 
- There was like a JavaScript function or something that was like, this is my CSS. 
- Yeah, you can create a new style sheet programmatically. 
So you would say const style sheet equals new CSS style sheet. 
- Do you just remember these things? - I know. 
- This is the kind of stuff I always have to look up. 
- And then once you've created that style sheet, you can then say style sheet dot replay or replace sync and just pass it in text. 
And the text expects it to be in the proper CSS syntax. 
And then once that's there, you've got now a style sheet with the CSS rule sets defined within it. 
And then whatever you're trying to attach it to, you pick my component dot shadow root dot adopted style sheets, which is a getter setter. 
It could give you an array of all the style sheets that adopted or you could just dot push and add a new style sheet into it. 
- So does that mean it's twice the maintenance or you're almost importing your CSS? And it has to be CSS. 
You can't use SAS then. 
- Correct, 'cause the SAS is all pre-processed. 
The browser doesn't know anything about SAS. 
So is it twice the effort? It kind of depends on how you're architecting things. 
Theoretically what you could do if you wanted to, I wouldn't recommend this, but what you could do is if you had your component scan its parent document, find all the style sheets it's using, fetch all that CSS, create new ones. 
You could theoretically, big air quotes here, inherit that global documents CSS and have it within there. 
- Kind of a manual inheritance, good. 
- Yes, the problem you will immediately run into with that though, is that every time you do that, when you create that new style sheet, that's now stored in memory. 
And so you would need some kind of either global management system to be able to adopt the same style sheet that you've created programmatically across all those things, or you wind up with every component creates its own instance of that style sheet, and you will start crashing iPhones. 
Been there, done that. 
- That's the expert talking. 
- I do have to ask, how does this play with web accessibility? Do you have control over things like ARIA labels? - You do, yeah, and the ARIA, 'cause there's a lot of consequences when you start talking about having separate documents, because if you have ARIA label is fine, because it's just a string, and so when the browser gets into that sub document, it will read the label of that thing. 
One of the issues with that though, and one of the best practices is to instead use ARIA labeled by or described by, and then to reference some other element by its ID. 
If the element with its ID is in a different document, they don't connect. 
It's not gonna look across the shadow DOM for that element. 
And so if you have your label text, separate from the thing you're labeling, you're trying to use label by across that border, it gets tricky. 
Also, forms get really weird. 
There's something weird with form elements, and I've never had to do a ton with form, so it's not something that's stuck in my head, but yeah, you run into some issues with accessibility, you run into issues with forms, you run into issues with styling. 
So web components are a tool that you can reach for, but they can bite you if you're not ready for some of them. 
So do your research before you start reaching for them. 
- Right on. 
- Yeah, we're now smart, 'cause we sat next to Andy. 
- Yeah, I know everything about him now. 
I'm gonna start using them for everything. 
- Are you? - Yeah. 
- No, no, no, that's not what I recommend. 
- I don't think that's what he said. 
- But I'm still gonna do it anyways. 
- All right, well thanks Andy, thanks for joining us. 
- Thanks for having me. 
- Maybe we'll go play pickleball later. 
- See if we can get that in. 
- Yeah, good luck. 
(upbeat music) (upbeat music)