YouTube Video 04YKlSNf89o  ## Metadata - Author: [[YouTube]] - Full Title: YouTube Video 04YKlSNf89o - Category: #articles - Document Tags: [[drupal]] [[web]] - Summary: YouTube Video 04YKlSNf89o - URL: https://www.youtube.com/watch?v=04YKlSNf89o Good afternoon. Thank you for showing up. Um, today I'm going to be talking about declarative shadowdom and the future of Drupal theming. Uh, first off, a little bit about myself. Um, I've been doing a a lot of web stuff for a very long time. Um, web developer since 1993. Drupal developer since 2004. Drupal 4.5 was my first version of Drupal that I ever used. But I've done a bunch of stuff because I'm old. Um, so this is actually my second presentation about web components and the first was in 2014 at uh whatever Drupal Con 2014. I don't remember where it was. Um but uh during that first presentation in 2014, somebody asked me during the session which was more of a discussion um they said have you heard of React? And then I became a React developer for 10 years. Um web components weren't quite ready in 2014 for doing a lot of things. Um, but I think now there's a there's a change about to happen. Um, when I start with a a very sort of bold claim, um, the era of ReactJS is coming to an end. And that's simply, and it's not a React specific thing. It's simply because there is no JavaScript framework that will ever be as fast as the web platform. the APIs that are built into your browser are super fast and any JavaScript library will be slower, an order of magnitude slower because the web components APIs have matured um and becoming more broadly available. Um they're the ones that people are going to naturally gravitate to and these larger application frameworks will become legacy frameworks. Um I want to talk about why I'm talking about um web components now in the context of um this new thing which I'm not sure if you've seen you probably have actually on can I use um any feature that you look at there there'll be like a little thing that says baseline 2022 or baseline 2015 um this is a sort of community uh agreed upon on system of talking about individual features in the web whether it's CSS or JavaScript or whatever. Um, and there's basically sort of three levels of these baseline feature availability. So any feature can be called limited availability, meaning it'll be like one or two of the major browsers have it, but not all of them. Um, then there's what's called newly available. uh and that means that all of the major browsers have that feature but it just became available in all of them. And then lastly we have widely available and what that means is that that feature was newly available for 2 and a half years and then at the end of that period they just call it widely available. Um, I've seen a lot of features that after uh like even like a year and a half, they've been available in like two versions of every single browser. So, your requirements may not be as strict as widely available, but widely available is a great uh great usage for deciding whether or not to use a particular feature in your web applications and your websites. So the thing that I'm wanted to talk about today declared a shadowd bomb became widely available in August 5th 2024. So this is this is or sorry it became newly available August 5th 2024. Um so this is this is very new uh technology that is now in every single browser and if we do the math 2 and a half years from now means that it will become widely available February 5th 2027th so just a little bit more than a year from now. So it's time to sort of start thinking about this technology you know experimenting with it deciding how you're going to add it to new projects. Maybe you will even add it to a new project that starts next year that will be deployed at the beginning of 2027. So everything old is new again. I've been doing web web development for a very long time. You know, old school was like PHP serverside renders. Uh the new school is like you use React when it has this new technology called server components and client components. And that's a way for you to serverside render react.js. I actually gave a presentation about this just last year before I found out about this technology. Um, and then of course the newer school is now uh PHP server side renders. Um, and that's because we just the fastest thing for an application is going to be rendering something on the server to start with. If you wait until it gets loaded into the client, into the browser before you start rendering some of that HTML, it's just going to be too slow. It's much faster to have it rendered on the server. Um there's a pattern that I see with a lot of these serverside rendering decisions. They basically will split um any particular component into two parts. Um and React.js JS literally calls them server components and and client components but the server component doesn't have any client side JavaScripts. Um and then the client part has the client side JavaScript for like interactions you know whatever have you um and those who have been around a long time this is this is progressive enhancement that's that's all it is. Um but this pattern of splitting up the server parts and clients parts is useful for comparing across different types of tech of different libraries. So in 2023, ReactJS introduced server components and client components. And you could do this on production websites, but web components didn't have a server solution for this. If you wanted to have a web component in your application, you had to use JavaScript, which means it would had to be rendered on in the browser rather than rendered ahead of time. But then 2024, now we have declarative shadowd. So you can just use regular HTML, including these declarative shadow DOM that's part of the HTML. Uh and then you add on vanilla JavaScript uh for your client side components. Web components is basically broken down into three APIs which we're going to talk about um all of these different APIs. There's custom elements, templates, and the shadow dome. Um, and I've got a 95% working demo here. Um, I I decided at the last minute that I didn't actually want to do a live demo, so I took a screenshot. So, I have a 95% working screenshot of a live demo. Um, I hope I got I hope I got all the screenshots that I wanted. But, let's get started. Um, and I I do have uh this code available on my laptop. If you're you actually want me to prove it, I could show you it running on my laptop afterwards. Um, I wanted to build a a really useful example of a web component so you could see it rather than giving you um a very sort of the first time I did the presentation, I had custom paragraph as my custom element and all it did was the same thing as the paragraph, which was it was lame. So, I decided I was going to create a a color scheme toggle inside a uh a custom element that allows you to toggle between um between uh dark mode and light mode. And is there Yeah, there we go. So this is the the custom elements and it can also respond to the OS uh dark mode there. So like this is a fully functional custom element. Uh I don't know if you noticed but alo doesn't come with dark mode. Um, so I really wanted to have the demo look really cool. So I did a very old school John Alvin thing and I created an entire contrib just for this slide. Um, which you can also download now. It's called Oliver dark mode. It's just a sub theme of Olive Arrow and it just adds the CSS that you need for dark mode. It also adds that widget to uh like the footer I think. So you can download it and play with it. the way that custom elements work. Um, it actually works the same way that that there's this feature that's been available in every single browser since browsers first started in that if it sees a tag that it doesn't know, it goes, "Oh, I don't know how to style this, but I'm just going to treat it like a span." and any of its uh any of its children all rendered normally, right? That's how it treats it. The custom elements API formalizes that. If you create a a tag the browser doesn't know and there's at least one dash in the name, like this is toggle-color- scheme, the custom elements API guarantees that any official HTML element will never have a dash in it. So any any element that it sees any tag name with a dash in it, they know know that's going to be a custom element. Uh browsers are not going to redefine it. It's however you want to define it. So um you can see inside can I Oh yeah, there you will. Yay. Um, you can see I have the the tag name here and then I just have a um a form here which uh has a bunch of radio buttons to toggle between light auto and dark and then I just add some custom styling to look it make it look neat. Um yeah, and here's the CSS. Um the selector here um is just a regular element selector like you can style a P element. Well, we're styling the toggle color scheme element, right? This works uh in CSS the same way. Um if the browser doesn't know what that CSS selector is, um it sees that it is element and it goes, "Oh, okay. I guess that's a custom element. I'll apply those styles when I see this tag." Um, and the way that all of this all of this works so far is just stuff that already worked in browsers since the beginning of time. But the thing that makes it the custom elements API is the JavaScript that you add. And it's a pretty simple API. You create a class. Uh, in this case, we created a toggle color scheme class. And to extend the sort of official HTML element class that all browsers use for the official HTML elements, you uh add a constructor um or add this connected callback. I'll talk about in a second. Um and then at the very bottom here, the important bit. Yeah. Okay. Uh is this custom elements.define. Um and then that is telling the the browser um we're defining a custom element and we're giving it this name of toggle color scheme and anytime you see that element in the page I want you to run this class like attach an object of this class to that element in the DOM. Um, and let's So, what the browser will do is as it's parsing the page the first time, like it'll see a body tag, it'll, you know, see some divs and finally come down to your custom elements. And when it sees that custom element, it'll create this object. It'll run the constructor method on here to create it. But when it first parses the that tag, it doesn't know about its children yet. Um because it hasn't parsed it yet. So after it runs constructor, then it parses the children, creates all the children, and then finally it comes back and says, "Okay, I've got the children ready. Now I'm going to insert them into this element, and then take this element and attach it to the real DOM." And when it does that, it calls the connected callback because we're connecting it to the DOM. And then we're going to run some some things to actually make this custom element do something. Um we're gonna in this case uh I'm storing the the value of whether it's light mode or dark mode um in the local storage just so it it it you go to any page it'll still remember what your setting was on the first page. I'm calling a a method here set color scheme. Um, and the cool thing is, if I can find my cursor, there it is. Inside any of these methods, the this keyword is specifically it is that custom element in the DOM. So this query selector, I'm quering the children of this particular element to find in this case a field set to add a change listener. That's really easy. Like that's a lot easier than the way Drupal does it because you have to have Drupal behaviors and Drupal once and you sort of do everything all at once. Um but with the custom elements API, if you use that, you don't have to do this anymore. um because the browser then becomes in charge of applying the JavaScript to those custom elements and it even if the element is added later with like some Ajax or something it's going to go oh I know what that that element is because you've already defined it and it'll apply it to the new HTML to get added to the page afterwards. It's great. Really you you should be like thinking about and doing this now like this is this is super widely available. Um, this custom elements API has been around for years and years. Uh, I I haven't looked up what the cannot use was telling you about it, but it'll probably be like I don't even know like 2015 or something. It's it's a really old uh bit of the web platform. Okay, let's go on to templates. This is the second of the three APIs that are part of web components. um templates and slots. These are two new uh HTML elements. Um and if I look over here, um you can see I've got a template tag. Um and I have a slot tag. And uh here you can see that that div is what that dotted border is inside our page. Um, but the template itself is not shown. It's not displayed even though it has like an image in it and all these divs and stuff like that. That's the browser's default behavior when it sees a template. It's basically like display none. It's not in um you can't see any of the contents. Um accessibility won't try to any accessib accessibility tools won't try to read the contents of a template. Um it's just sort of it's you can see the template in the DOM but then you can't do anything else about it. Um the slot tag is a the way that you sort of define where the contents of your custom elements go. This will make more sense when I start talking about the shadowdom here. Um, so I'm gonna talk about it when I talk about the shadow guy. Oh yeah, this is just the the HTML sort of a little bit easier to see than inside the browser web inspector. Um, we have a template with the ID on it just so we can grab it with our JavaScript word and then slot with either names. So we have a a named slot here and then we have a slot that's not named. Um, and those mean different things, which I'll talk about in just a second. Um, I I went ahead and wrote some JavaScript to use a template, but it's really awkward because without the shadow DOM, you have to grab the template, pull its contents out, and then clone that, and then find all the slots in it using like query selector, and then insert your content into the slots, and and then finally stuff the whole thing back into the DOM. super awkward. Uh you wouldn't want to do it, but I went ahead and did it anyway just to show you templates as slots um can be used. So this button, the clone template, it's just taking that template that was in the HTML and you know adding some content to it and inserting it into the DOM. So they work kind of but not not in a useful way by themselves. So now let's talk start talking about the shadow dump. Um, so if you look at this uh this flip card custom element, you can see it's got shadow content there. That's our shadow dot. This is how it looks in the web inspector. Um, and um, it also has I'm getting a little ahead of myself in the the let me go back. Yeah. Um, this custom element also has a um, attribute on it called the image attributes where you could specify whether it's the image is on the left or the right hand side. And there's also a button I added for interactivity that flips or flops the which side the image on. It's just silly, but I wanted to show you some interactivity on it. And you can see that um the way that that button works is basically it just modifies the image attribute and then the image attribute controls what CSS is is applied which is why the CSS knows whether to put the image on the left or the right. So the custom element part of uh this web component is almost the same. We've got a flip card that extends HTML element at the bottom there. You can see that there's custom elements.define. Again, we're defining what flip-f means. Um, and the difference is in the constructor here where we're doing a this.attach shadow and that tells the browser not only is this a custom element, but it's got shadowdom attached to it. Um, and what the shadowdom is is it's basically like a its own sort of private DOM, right? So you've got the main DOM and then that custom element will have its own DOM for any of the things that are inside that element. So it's a separate DOM. Um, and the idea behind it is that you want to encapsulate that shadow DOM and prevents like styles from the main page bleeding to your web component or JavaScript that's doing a bunch of global things accidentally going in and changing the way the internals of how your JavaScript works in your web. That's the idea behind why it's separate and encapsulated. And there's very specific ways that the CSS and JS can actually communicate, but it's it's limited on purpose in order to ensure that the cap encapsulation is as is as good as possible, the isolation is good as possible. So, um I've attached a shadowdom, but like by itself that doesn't do anything. we have to look at the connected callback because um we want to take our template and insert the template into the shadow dog. So you can see here um in our connected callback we are we're finding in our HTML that um that template tag that has an ID of flip card. We're grabbing it by ID, and then we're pulling the the content of that template and saving it to this variable, the template variable. Then we're cloning the variable, the the template, uh, and appending it to this element's shadow DOM. So now the shadowdom is no longer empty. It has a copy of all the HTML that was in the template that's now at the root of the shadow DOM. Um, and then we're doing some other stuff where we're um, you know, adding some interactivity and stuff. Um, this is all the same as the custom elements API that I showed you earlier. Um, the next thing we're going to talk about is uh, the CSS. So um inside our template, one of the things that I have in this example is an inline style tag. Um this is one way that you can do styling of a web component because remember the CSS from the main DOM does not apply to the shadow DOM. So we have to write our own styles in there. And this is one way just have an inline uh style tag. Um I I don't think I will use this method but I wanted to show using this method um because you'll see it in a lot of documentation. Um and the just like in the main DOM we'll have like a colon root to apply some CSS to the root of the the main DOM. You can do colon host which is the root of the uh of the shadowdom for this component. Um and it's you know it's a normal selector. So you can like have you can add um an uh or sorry it's not a normal selector. It it can be used as a normal like element kind of like selector but it also has this uh option where it becomes a function with the parentheses around there where you can add additional selectors. So you can decide I want to apply this yes to the root but only when this additional selector also works on that element. So in this case, I only want to add some some CSS if the image attribute is set to left on the custom element. Um, and let's see. Once we've done that, then the way we use our flip card, the way we actually use it on a a page and get content into uh into our shadowdom or get content into the element. Um, looks like this. So, we've got our custom element flip card and then we're just giving it some some children elements, right? We've got a paragraph here. We've got an image and we have an H2. But you can see here there is a slot attribute on the image tag and that means that this image tag will be inserted into this slot in our template because here's the template. I made a copy of it in this page. Um, so in the shadowdom we'll have a slot that's named image and because we're using the slot attribute of image, this piece of content will be slotted into that spot um in our web component. And this one that has slot heading will be inserted into the heading. And you can see that the order of our content here doesn't really matter if we've used named uh slots. But this paragraph doesn't have a slot attribute which means it goes into the default slot and the default slot sorry the default slot is just a slot that does not have does not have its own name. So this slot has a name of heading but this slot uh doesn't have any name. It's just a a slot with no name attribute and that's the default attribute which means our paragraph is going to go into that slot of our web component. Now all of this requires JavaScript in order to work because we have to use JavaScript to create the shadowdom. Uh and then in you we have to use JavaScript to insert the template into the shadowDOM. And if we disable JavaScript, none of that CSS is going to apply. None of those slots the template doesn't apply. And you can see that we just we just have the rendering of the child components when when JavaScript is turned off. And it doesn't know how to style this. It doesn't know how to arrange it. It's all out of order. The the heading is at the bottom when it should be at the top. Like it doesn't work. There was no server side rendering of this because it was only done using JavaScript. But declarative shadowdom fixes that. So I wanted to show that uh this is really not using any JavaScript in order to be rendered properly. So I went into my um SDC that I was using for this particular demo and the JavaScript is literally like there's nothing in it, right? It's not creating a custom element. Um, it's not creating a shadowdom. It's doing nothing, but it still renders perfectly. It still has a shadow DOM in it. Um, let's see. And the way that that works is that inside our web page, when we have a flip card custom element, we include a copy of the template as the first item in the flip card custom element. And when the web browser sees this as it's parsing the markup, it'll see the template that's directly underneath the custom elements and it'll uh it'll take it out of the DOM. It'll take the template out of the DOM, create an empty shadow DOM, and then put that template into the shadow DOM. All because we have a um a custom element here with a a a template that's directly underneath it and we've done this shadow root mode um attribute on it. We tell it that we want a shadow uh shadow root on this particular element. So declaratively in the HTML we've told the browser how to build the shadow DOM for this component. And that means if we want to have multiple flip cards on our page, each time we have a flip card, we also have to have the same template there. That's the way the API works. It is a bit verbose. I agree. Um because you have to have you have to have the entire template every single time you use a custom element in your markup on your web page. But You don't need any JavaScript. There's no JavaScript running. In fact, um when I um when I run this uh when I load this page up, you can see here that it has a shadow content even though I didn't do any custom uh elements API. Um I didn't add a attach shadow. None of that is done, but the browser still created a shadowdom uh with the template in it. Um, and if we look at I'm going to reload it here in a second. Yeah. Reload it here. And you can see that it there's there's no JavaScript that was run on this page except for the JavaScript which prints out no JavaScript was run on this page into the console. Right? So that's declared a shadow. It's pretty simple. That's how you do serverside rendering of a web component and of a full web component using all three of the APIs. Um, and I wanted to talk about how you would style a element with um with the shadow DOM part because it's not it's not the way we're used to, right? Because none of our CSS that we're used to cascading in the main DOM applies at all to the shadow DOM. I wanted to give a diagram of like how uh the CSS works but it was really hard to visualize like this is the main DOM and then this is the shadow DOM and then like these are the slots. It was it was hard to sort of come up with an idea. So I wanted to take a web page and sort of like rotate it just like side view so that the the shadow do the sorry the light DOM is on the right hand side here and the shadow DOM is on the right on the on the left side. Um and like this is like our body tag. it's in the light DOM and as you add like divs and stuff th these are going to be displayed in this diagram um you know as sort of stacking up uh on the right here inside our light DOM if this particular element is a custom element it stays in the light DOM until we call attach shadow once we call attach shadow the browser will create a root shadow DOM for that custom element and it firmly inside the shadow DOM. Any divs that we add which which we can do with regular DOM API, we can add divs to our shadowdom manually or we can insert it with the template. Right? So all of those all of that markup that we add to the that we attach to the shadowdom stays in the shadow DOM. And the only thing that's a bit odd is that slots slots are a way where they're positioned in the shadow DOM, but any mark any content that you put into that slot is actually in the light DOM. So th those pieces of content are in the light DOM and they're positioned because they're inside the slot and the slot is in the shadow DOM. So, how do we how do we actually apply CSS to the shadow dome? Now that I've I've laid out exactly how the different pieces work here in this diagram. Um, the good news is that I said none of the CSS applies to the shadowdom, but actually every single custom property that you create that would apply to the custom elements goes into the shadowdom. So the shadowdom CSS can decide to use these properties or not. They can use those values in any CSS that they have. So this is a really powerful way to change the way your um web component actually looks by giving it custom properties and then using those custom properties in the CSS of the shadowdom part of our web component. Another way that we can have write CSS here is we also sometimes want to have control from inside the shadow DOM out into the light DOM because we'll want to like style the contents of our element, right? And we can do that with this slotted selector. Um, it allows us to select the um the the first DOM element in sorry not the first it allows us to select um any of the contents. Um so if you how do I how do I describe this? Um let me describe how it doesn't how it won't work. If you added an an unordered list to this uh a ul with like an ally, this CSS would be able to style the ul, but it can't apply any styles to the children of that first top element. Um, so you can't style the li. So the slotted div is is limited to the sort of root level of the slot. It can't style any the children of that content. That's what I want to say. But of course there's a workaround with this especially since we have STC in Drupal. It's really easy to add CSS to the lightdom in our SDC's. So we just write a some CSS in our lightdom CSS that is just a using an element selector custom element and then you can style the LI of your UL using a regular CSS selector like this. The other thing that you can do um inside your shadowdom CSS and I yeah I probably I just realized I just created this today and I just realized I put this uh this selector on the wrong side here. This custom element um Oh no no no no. Sorry. This is this is fine. This uh this is CSS that goes in your light DOM CSS and it allows you to style or change the style of different parts of the web component. Um and let me go back here. I didn't point this out. Yeah. So, inside our template here, I had added this part attribute to a couple different places. So we've got a um we've named this part as the text and this part as the image which means that from the light bomb we can style the we can change the style of those parts by using this part selector. I gota go back through this. Okay, so that's the CSS you would use from the light DOM to style or change the style of a part of a web component. And these are all of the the the ways that you can sort of cross communicate some CSS, but it's limited to just these things, right? Um, and I should point out because it's encapsulated that includes your base styles as well. So like that flip card, you saw how the the image stayed within, you know, the image part, the image half of our flip card. There's no default, you know, max width equals 100%. in the shadowdom CSS, you have to add that CSS specifically to this custom elements shadowdom CSS in order for it to shrink to its parent. Right? So that's just something to keep in mind. So that's everything with the shadow dump. Um it's custom elements, templates, and the shadow API. Now there is another thing that people are doing with these APIs. um that is a little bit simpler because this can be a lot uh to do. Um and there's a there's a thing called lightdom components. Um and like somebody asked me is is like is this furry handcuffs? Um no that's not what light do components means. It means that the component is just using the custom elements API and it's not using shadowdom at all. Um, this can be a good way to get into web components. Um, and some people just stay here. They're like, "This is enough for me. We don't need the the encapsulation is too heavy-handed for our uses and we're just not going to use it. We're just going to use the custom elements API." And the way that compares to a shadow DOM component is um, we using declare the shadowdom for serverside rendering our um, shadowdom components. So on the light components, we're not using templates. So we just put the markup that we need for that custom element in that custom element. Right? So that's that's really easy to do with STC. Our STC twig file is going to have the custom element. It's going to have any CSS that it needs the scaffolding for our CSS that'll be included inside that twig file. So we don't have to repeat the template every single time because it's it's a it's a Twig file. It's a twig SDC uh component. Um, so why choose the light? Less CSS drama. Um, standard CSS cascade. This is stuff we know, we've been using for for years. The the the ways that you interact with CSS, the different arrows that I had on that slide. It's it's a lot to get a handle on. There's also less accessibility drama. There's one part that uh the web community is still working on to fix and that is Arya and the shadowdom because remember the shadowdom is this separate DOM from the main DOM and that means if you add Arya attributes to shadowdom markup any accessibility tool can't see it it's in the shadowDOM it's not in your main DOM so all of those things are inaccessible to accessibility tools. That is a huge problem. Um and the sort of workaround for that is essentially if you need an element uh to have some area attribute or like it has its own intrinsic um intrinsic semantic area value like a button like a button element is a button but you wouldn't want to put the button in the shadowdom because then the accessibility users can't see the button but you could create a slot and then put the button in the slot. It's a bit awkward, but basically you don't want to add any markup that is useful for accessibility in the shadowdom markup. Um, that's a big problem. Um, I wanted to point it out. I just learned about this problem right before I did this presentation. So, so last thing I want to talk about uh and show you is a real world example of a single directory component um using web components. We're going to do the full uh shadow DOM components for this example just so you have you can see everything all together. Um this is the the fifth demo here for SDC web components. And you can see here I've added a new thing of a a primary variant. So if you um inside your SDC if you toggle the the variant um it will use different styling. It makes the the border a bit thicker and it adds sort of primary color to it. Um, this is what the file structure looks like. This is if you've used SDC before, this all looks very familiar. We've got a flip card as our directory. We've got a flip card.component.y where we define all of the the properties and slots and everything. And um, inside that file, we've got a flip card.css. Drupal is going to load that CSS file anytime this component is used. It's got a flip card.js. It's going to load that JavaScript every time this component is used. Um, it also has a shadow.css file which Drupal will completely ignore, but we're going to do something with it in our code. Let's show the component. This looks this is all standard uh component. Um, variance is a new thing in I think it's it's 11.2 that adds it to Drupal 11.2 2 added variants to uh the SEC API. So we're defining a a primary variant of it um that you know highlights the flip card, right? Um and then we've got um some props here image side. This is this is uh this is how we're going to control the the uh um the image attribute on our custom element. Remember we have that image attribute that can be left or right. We're going to control that with a property in SDC. So the the values that you can give to that property is left to right and we'll then write it inside that attribute instead inside that HTML attribute when we render the Twick file. Um there's a bunch of other things that are at the bottom of this file, but uh it's it's all standard component YAML. So I'm going to skip over that. And this is how you would use the component. I thought it would be useful to show like if uh in your templates directory like say you have a a node um a node file node- teaser example you could use that in that file to embed this specific um SDC component. Uh demo is the name of the theme that I created for this demo. So that's why it's using demo uh colon flip card as the name of the SDC component. And then we're just we're specifying what the variant is. Um SDC will automatically create an attributes variable for you for your Twix file unless you provide one for it when you call when you embed the SDC. So we're going to we're going to create our own because I want to add some some some classes to uh the outside of our of our SDC component. Image side prop. uh in SDC we're specifying an activity rights um and then we're using the Drupal content variable. We're going to pass that on down um because we want to print out specific fields that are inside uh this node type that I created. um the uh the heading uh the the main body text and the image those are all coming from from Drupal's you know node or paragraph right this is our um our flip-card twwig file you see it's printing out the attributes like normal um because we want to is declared of shadowdom. We're including the template here. This is the only place in Drupal where we have this template. So Drupal is now um responsible for printing out all this markup anytime you want to use flip card um as a SEC component which is nice. So that's there. I'm not using any CSS uh style tags here. Um, and that's because I wanted to uh I I prefer having a separate CSS file because you can do sort of linting on it and it's just easier for my IDE to like see the CSS instead of being embedded inside a twig file. The syntax highlighting doesn't work the same. So, um I um I'm going to come back to this include in a second here. Um, you can see here the image prompt is uh left or is right and I change the text that gets rendered to the the button. Uh, if uh if the image is supposed to be on the left instead of the default button saying uh flip, it's going to say flop, right? And that that is a change that I'm making to the template based on this particular invocation of this SDC and the value of the image side property that I gave it when I embedded it or included it. That's the only modification that I'm making to this template. Otherwise, all the modifications are just in the sort of content area of our custom elements. Right? So down here um I want to insert some content into my um into the slots of my flip component or sorry flip card component. So um inside the component YAML I specified um that you can have different options for the heading tag. You can specify either an H2 or an H3 um and it defaults to H2. So it'll it'll use the the heading level that you want. Um and then we're just inserting uh we're using a twig block to print out the heading that again is coming from a Drupal field. Um that's the way the uh flipcard.twig file works. And now let's go back to the CSS part. I wanted to have a this is a helper uh twig file. Shadowroot styles.html.twig. It's going to load um that shadow.css file that I have and also some global some base CSS that I want in every single component. So not just this flip card uh component but any other component that also uses shadowdom. Um, and the way that it worked here is to get that global the base styles, we're going to call the active theme path and then just insert a common CSS file into the the the template for every single uh quick component. Got like two minutes left or something like that. Um, I'm almost done. Um, and then the last bit of a little bit trickery here is when we include this helper twig file, we're going to pass this variable called component metadata. This is a variable that is available for every single SDC component in Drupal. Um, and it has some metadata in there, including the path to this SDC components. So, we're going to in our um in our little helper twig file here, we're going to use the component meta metadata.path. Uh and then that's how we access the shadowdom for this particular SDC component. Um by the way, all of these slides are available on my website already, john.alwood.net/presentations. Um, and uh, the last thing I wanted to show you, actually, I think I think I can skip these. Um, yeah. Yeah, let's skip this bit. Um, yeah, I just I I had some examples here of like showing how you can use parts. Um, but let's also skip that. Um, our shadow.css CSS is using the, you know, the host selector just like I showed you in previous pages. That's it. Thank you. There are any questions you can ask now. Probably we're going to get kicked out and we'll have to ask them outside then. >> Yeah. Thank you. Have a question about this shuttle dome page. Can we uh use JavaScript to clone the template not as a shadow dome but as a regular uh do so we use template clone uh and can we just get it and render as regular HTML not >> yeah so like I I had an example there that actually did it but it's it's not any more convenient than having a hidden chunk of HTML that you just clone using regular DOM APIs the fact that it's a template that's that's the only difference is is that the template is not displayed um by the browsers but you could also just apply CSS to regular div I I don't know it's >> and you can >> you can do it but it's >> yeah you can't use slots in that approach yeah >> if you clone not as a shadow do the slots will not work >> slots in the template when we clone it uh we can use slots >> yes yeah and shadowdoms the that's the Only way you can use slots is if they're in the shadow HTML. >> Yeah. And about CSS, can we use optimization on Drupal? You wrote the um CSS direct link to the CSS file and can we use optimized version of CSS using Drupal? So not the direct file to the z pass to the CSS file but the compile included into Drupal optimization. >> Sorry, I was just looking at the time. Um in 10 nine minutes here they're going to have um a a different session and we're going to miss drinking. So let's go talk out in the in the you can >> just go ahead quick. >> Sure. Further recording >> on the on the slide that had the light shadow of the pipe. uh it used colon root but in your CSS on the last side used col host um >> uh that the >> right the CSS use um I'll have to double check that I mean it definitely worked when I did this these are screenshots from a typo >> this is it's it's not well it's probably a typo in the slide because of the screenshots it's real code so that one actually works toy type on my slide. Yeah. Yeah. Thanks for pointing that out., YouTube Video 04YKlSNf89o, YouTube, 01kabwfc11cr57mdn7nq208ymk.