 So, yeah, thanks everybody. This is envisioning a design system maintained by the Drupal community. Really excited to be here at Bad Camp. And even if I don't do anything, you've already been inspired today since you're in the inspiration room. But I am Brian Perry. I am a staff software engineer at Pantheon. I am one of the initiative coordinators for Drupal's decoupled menus initiative. I live in the Chicago suburbs. I like Drupal, JavaScript, and Nintendo. And the new trailer for the Mario movie is premiering today. Very exciting. And I'm sure there will be many memes about Chris Pratt's voice as Mario. Also relevant to today's topic, I own the domain webcomponents.wtf. Haven't done anything with it. But I think the fact that I own it is still an accomplishment. I'm on the internet in a variety of places and would love to internet with you. I'll try not to stand in front of the projector here. And as I mentioned, I work for Pantheon. And not all, but many of the things we'll be talking about today, there have been sponsored contributions from Pantheon. A lot of the work that I've been doing since I joined Pantheon is focused on open source projects related to decoupled architectures. And related to that, our front end sites product is in early access. So now you can host your next JS, your Gatsby sites on Pantheon, which is really exciting. And just in general, thanks to Pantheon for sponsoring for me to get out here. So this talk is called Envisioning a Design System Maintained by the Drupal Community. So let's, in this inspiration room, start envisioning. So yeah, we'll be asking a bunch of what if questions to lead us down the road today. So what if there were a set of Drupal friendly components that anybody could use, and they could be used in twig, and they could be used with any JavaScript framework. And it was easy to extend those components or contribute new ones. It sounds awesome to me if that was a thing. So what if web components could make this possible? And specifically talking about web components, whatever you explain what web components the spec is, you've probably already lost. But I'll do it anyway. So this is not necessarily referring to React or View or specific JavaScript frameworks. Web components are a set of web platform APIs making up custom elements, the shadow DOM, and HTML templates. So it's essentially a browser native representation of a component or custom element. And it's not tied to any specific framework. So it doesn't matter what framework is super hot right now, web components will always exist as a core browser technology. So let's actually look at a couple, an example of a card web component in a few different contexts. So this is the card component from the generic Drupal web components library, which we'll talk more about. But in our JavaScript file, we're just importing the library of components and a style sheet. And then in our HTML file, we can use that card component. Gwc-card is the custom element. We're just including it in our markup and passing in a number of attributes to it. The image, headline, body text, the link, etc. And then it takes that and renders it as a card, in the style of a card. And it has its own scope styling as you can see here below. There's just regular markup that has the styles associated, the global styles associated with the DOM. So the styles for this component don't necessarily leak out of it, affecting the rest of your page. All right, so that's just in an HTML document. No fancy JavaScript framework or bundler required. This is that same card component in a Olivero theme in Drupal. It looks the same. The data from Drupal is being passed into the card. Here's a quick look at the pieces that can make that possible. So we define a library that has our style sheet and our JavaScript file for our components. And then in the article teaser template is where we're actually rendering out the card and setting all of the necessary attributes like we saw before. Except we get to use Drupal's twig helper functions to do that. Makes it a little bit easier to do it in a Drupal way. Get out that data and everything. And don't really go into this in this talk since it's breaking news, but there's an issue going around that is the new hotness about a concept for a future version of Drupal of a single directory component concept that really fits nicely into this. It would allow a directory to contain the CSS JavaScript and markup for a thing, which is exactly what's on this screen. So I'm interested to see what happens there. It could make something like this even more pleasant for front-end Drupal developers. So let's see the same component in a fancy JavaScript framework. So this is a view in this case. Just a sample view code sandbox. And here in our script, we're importing the components and the style sheet, just like we saw in all the other examples. And in our view template, we can just use that same custom elements. Exactly the same. The styles are exactly the same. We can use it right in view. Same sort of deal. So, yeah, that idea of literally a component that you can use anywhere is really exciting to me, kind of always been the dream. So some things that I think are pros about web components as a technology. They use core web APIs, as I mentioned. They do now have wide browser support that hasn't always been the case in the long path of web components becoming a real thing. They can use the shadow DOM, which is essentially like a scoped version of the DOM specific to that component, which can give you a lot more control over styling or even JavaScript events. And essentially, you can play traffic pop as far as what does come in and out of your component. And as we saw with some examples, it really does get a lot closer to that right once use anywhere dream that at least I've had. But not without some cons. Things are definitely getting better. Web components are evolving, but there are challenges. So I think a common expectation is that web components are going to be like React, for example. But as a lower level browser technology, it doesn't have the ergonomics of what you might be expected as a developer with something like React. So it doesn't have opinions about bundling, using just plain vanilla web components. There's a lot that you have to do in JavaScript to create elements and structure your component. So there are a number of supporting libraries that make it easier. Lit is one. It's a Google project. From my perspective, it's kind of one-to-one with web components in my head. It's pretty close to the spec, but there's a lot of things that it makes much easier. Then styling can be unintuitive, especially to someone who is not familiar with the shadow DOM in web components. And we'll look at some examples of that as we go on. It's powerful, but it can also be, it's different from what the traditional front end developer is familiar with with styles that are global and affect the whole DOM. Yeah, I kind of already hit on this, but, you know, it doesn't, out of the box, have the developer experience of a framework. You know, it doesn't have necessarily opinions baked in about things like state management and things like that. And there are also some ongoing challenges related to server side rendering of web components. So, you know, this is not necessarily all that different from the JavaScript frameworks, but for a web component to mount on the page, you need JavaScript. There's definitely ways that you can structure your web components so that there is content that will load and display without JavaScript. But you have the fully interactive enhanced element. I really don't want to upgrade Chrome. This is two for two on most recent talks where that has happened. Yeah, so you need JavaScript. There is a new enhancement to web components called declarative shadow DOM that actually provides a way that you can essentially have a representation of your web component that will render without JavaScript. And then when JavaScript mounts, it will enhance the component. So that's gaining browser adoption. Also, the challenge there from the Drupal perspective is that all of the solutions for that are node packages. There's a lot of great tools to make to allow you to easily server render web components in that way. But there really isn't that I can see anyway, a clear solution to how we can do that in PHP or, you know, in Drupal, which doesn't necessarily have node as a dependency. But my personal opinion is that on an infinite time scale, these web components, browser native components, will be an important part of building for the web. But what I don't know is, you know, how much they'll evolve along the way. Are we going to continue down the path that we're on now, where this concept just continues to evolve and, you know, be enhanced and improved? Lately, I'm getting the feeling that that is what's going to happen. Previously, like a year ago, you know, I wasn't so confident. I do think that some sort of browser native component is going to be an important thing about how we build front end sites. But, you know, was it going to be this one? However, I am also very confident that in the short term, web components are going to be a growing part of your your front end bundle, your dependencies, even if you don't know it. More and more, there are going to be things that you can NPM install that just work and the whole component or part of the component is going to be based on this web web component technology. So even if you're not out there trying to, you know, I want to get a web component to do this, you may just have it. And it might be something that, you know, just works in your reactor or view or spelt or whatever project. So I have in the past given a talk specifically focused on web components and my experience learning about them and the challenges and tricks. This is a link to a version of the talk I gave at a past a couple of days. So if you're interested, check that out. So moving on to another what if question. So I mentioned Drupal's decoupled menus initiative. One thing that the initiative took on at a past Drupal con was with a new menu endpoint that was built to try to get people together to essentially do a hackathon and create a variety of different front end components that consumed that menu data. We had some built in react and view. But as I was interested in learning about web components, I wanted to see could I make a menu web component? Excuse me. So we did. And this is it. So, you know, similar to what we saw before where we're importing the JavaScript for the component and importing a style sheet. I'll get down on the level so I don't break my back here. And you'll see the component is rendered on the right hand side. If I expand it, I see items from my main menu. It's in the mobile view. If I change the, so well, I guess to get into the elements here, so the attributes. So there's branding, which is the title of the menu. The base URL is the root URL of your Drupal instance that has the menus endpoint exposed. The menu ID is the machine name of the menu in Drupal. So if I change this to account, is it account? I thought it was account. There you go. So here we just see a link to login. When we're not authenticated, that's the only link that's in the menu. It respects permissions and all of that. So if we just pass another menu ID, it goes, fetches the appropriate menu and spits it out into the component. There's also the concept of a theme attribute here. So this is horizontal. If I don't pass a theme element, it's just a unordered list. But if I bring back the main menu, you'll see that there still is light, expand and collapse. The idea here is that we were trying to create a component that could be restyled and overridden in a bunch of ways. Or we could actually make the theme unstyled, which literally just is an unordered list. If anybody's looking to join, there are seats in the front. I won't bite. Yeah, so that is the component that we built. And I think the concept of being able to kind of abstract away some of the work of talking to Drupal's API, parsing out that data, and just making it a thing that people can plug in, the URL of their Drupal site, specify the menu, and you get a functioning component is really cool. So we started talking about how could we try to build more components in that library? And what we found pretty quickly when we're trying to make more things is that some of the approaches that we took in that menu web component, which really is kind of a proof of concept, didn't scale well when we tried to think about a whole system of components. So let's look at some of those things that were hard to scale. One was the concept of styling. So we kept that component really pretty bare bones and provided some ways that the styles can be overwritten. So what we'll look at here is the storybook for this generic Drupal web components project. And we'll start by looking at the menu web component that we've been talking about. So there are a bunch of different ways that we essentially expose styling hooks and see it's a little blurry here. I don't know if I can make it bigger in a way that will help maybe a little bit. So we exposed a few different styling hooks. So we already saw that there are the different themes that we created an attribute for. So depending on the value of that attribute, it's going to affect the styles that are used inside of the component. There also is a concept of shadow parts. So we talked about the shadow DOM and the fact that styles from outside can't leak in. So outside styles can't affect the component when you're using the shadow DOM for styling unless you allow it to and provide specific hooks. So there's this concept of shadow parts and you can define essentially any element in your component as a part. So I think the parts here is like menu section and menu item. And then that allows them to be styled from the outside. There's a part selector and you can say parts menu section. And that's how we make this pink, blue background, dotted outline, all that stuff. And then there is also the concept of a slot. So there's a default slot, which is essentially just any unnamed element inside of the web component. But you can also create name slots. So if you wanted to have something for the branding like we have here, you can define the slot for that and then it allows you to pass in any markup for that slot that will then be rendered. And that slotted markup is part of the traditional DOM. So the styles for your global page will affect it. So that's the way that you could have some styling that comes in from outside another way. And then here under the documentation, we kind of go into some of these options, many of which we've talked about. Another common approach in these types of web components is using CSS custom properties or CSS variables. And the reason that that can be useful is that, so the one exception to the whole shadow DOM and styling leaking in is things that cascade. So like font declarations and things like that, colors I believe do cascade down to children. Custom properties do the same thing. So you can define these different variables that then do cascade into your web component and you can have the web component take advantage of those variables. So for example, you could set a font stack at the root of your document and it will cascade down to everything, including these web components so that could easily allow your web component to be like, if the document has font set, I'm gonna honor that. And let's see, what else? We talked about theme property, shadow part, slots. You can also, since these are JavaScript classes at the end of the day, you can also extend the class in order to affect the markup that's rendered out, styling, things like that. That's definitely like power user territory, but it's possible. And another thing that you can do, we didn't really find this, we didn't really go with this approach in this library, but you can also just use traditional classes. So you can set a class on your component and within your style, say, if this class exists, these styles will apply. But again, all of those things really are hooks that you have to define. So I'm sure that the styling and the ways to affect the styling of a web component could be an entire talk in and of itself. I'm sure it was tough to catch all that in the run through that I just did. But there's so many options and a lot of them do put too much responsibility, in my opinion, on the consumer of the component. Like think of that menu web component. To make that thing look the way you want it to, to get it to match the rest of your site, it's definitely possible, but it's a lot of work, more work than I would want it to be. So yeah, there are all these approaches that still do require some intent, but are possible. So as we worked on building out more of these components, we started gravitating towards using CSS custom properties, looking at other web component libraries, that seems to be a common approach as well. And we already touched on some of the reasons why I think this makes sense. So CSS custom properties are inherited, so they do pierce the shadow DOM, and it does kind of provide a level playing field, because you can define these properties that will in fact apply to everything on the page. But you still have to take the intentional step of building your component in such a way that it uses those variables. And related to this, something, a library that we found and are taking advantage of in this project is OpenProps. So this is my personal opinion, but I describe OpenProps as kind of tailwind just the good parts. I don't know if you're familiar with that. With tailwind, I definitely understand why many people doing front end work really like tailwind. The thing that I don't really love about tailwind is the kind of atomic classes, the utility classes, that require you to put a whole lot of that in your markup. Reason being for me is just that that's not the way I learn to style things, right? That's not the way my brain works. I can definitely get the job done, but I can do things faster, styling the way that I know how to style. However, the thing that I think is amazing about tailwind is it has a really robust, well-defined set of custom properties, well, design tokens in the case of tailwind. So that's really the main thing that OpenProps provides is a really great set of design tokens as CSS custom properties. That rather than having to figure out what all those things are, figure out the naming, a package like this one can just use it. Yeah, and I think I got to a lot of this, so they provide styles that can be scoped to the regular DOM or the shadow DOM. That actually was an enhancement that we submitted against the library that they added, which is fantastic. And yeah, all the advantages to variables that we talked about, and by kind of incorporating this library into the generic Drupal Web Components project as a whole, it gives a whole kind of well-thought-out system that these components can opt into for theming control. So let's take a quick look at what that actually means. Actually, I'm gonna do it in Storybook again, and we'll look at our card component, the always default kind of general example. But basically, in this library, there are just a set of custom properties that you can allow these components to opt into. You can then use them in the styles or have them just affect things globally. So it gives you a lot of potential control. Simple example, there's a font family custom property that uses the font family values that OpenProps has. So I can change this to a serif font that automatically cascades down to all the stuff, or I can make it mono. And there's long lists, but there's so many things that we can do to, we have the basic structure of this card, but then to tweak it so that it meets our needs. So there is the heading text. We could make that red. We could do something like add a, I don't know, add some padding here to the component and make it even a little bit bigger. Round the corners, give ourselves some border radius. Let's see what else, there's a shadow here. Give it fancy drop shadow. We can even do something terrible like, yeah, eventually you'll combine things in such a way that you can make something ugly, but there's also a set of gradients that are available in OpenProps. So I can just randomly select a gradient that is gonna be very inaccessible. Can I land on one that's kind of okay? That's kind of okay. So obviously made quite a lot of tweaks to this card, still the same general structure, but those are all just custom properties that this card can take advantage of, and you can set them at whatever level you want. You can set those custom properties at the scope of this instance of a card. You can set it for all cards. You could also set them at the root of your DOM and have them cascade all the way down. So, for example, if you wanted all the fonts to be mono, for all of these components, you can just set that at the root and it'll just be taken care of. So thanks to a system like this, I feel like this makes it a lot more achievable for a library like this to have ways to affect the styling to better match an application rather than essentially having to have custom theme controls in every single component. Took a while to get there, but I think it's pretty cool. And let's look at one more quick example of this in practice. So this is a view, the same view example that we saw before that renders the card. If you look carefully, if you have your front end goggles on, maybe a little harder to see in this screen, but the font stack doesn't quite match, right? The default fonts are different from the view fonts. So we have that custom property font family and we can just set it to match the font family that the rest of the app is using. And now it matches the rest of the view app. They're all cascades down. We're setting that at the root of the app. So any other components in this library that are used would pick up the same stuff. So it's a nice low effort shortcut to being able to make these fit into the style of your app. So another what if question, what if these components could work with any data, but actually knew a few things about Drupal. So we have some higher level components that we've worked on, like cards or a hero, within those some lower level things, like links and images. So let's take a look at the link component. So it's a link, not all that exciting. It does have all of those styling controls that we talked about. You can pass in the different attributes of a link, HREF, title, rel, target, et cetera. And it accepts a slot as well. There's not a whole lot of value necessarily in using this link component because you could just use a regular link tag. However, once we start to layer on some light knowledge of the structure of data that comes from Drupal, I feel like something like this could be useful. So there's a couple of examples here that use data that comes from Drupal. So this is just an example of the output of a link field from JSON API. So we have the URI title and there's a couple of different examples, like what does it look like if it's for a referenced entity? What does it look like if it's a link that points outward? So you'll see here that we don't manually pass in HREF for any of that stuff. We just pass in that data object and it's still possible for us to render our link with data from Drupal. So hopefully here that makes it a little bit easier to take fields that come from Drupal with a specific structure and use them alongside these components where otherwise there would probably have to be some work that you have to do, either in like top level state management or within the component to kind of parse that out and get the individual pieces and slot them into all of the attributes. I don't think this is something that would apply to all components but for some of these more atomic elements like a link or an image or things like that. I think this could be really useful. So let's look a little bit more about what's happening behind the scenes here. It's surprisingly somewhat uncomplicated. So in the component there is our render method that renders out the markup and if the data attribute exists if we're passing in data then it runs that process data method and if not it will just return the markup and use the attributes that exist like href, target, et cetera. So if we look at the process data method, really simple, there's definitely some ways that we might be able to abstract this out make it a little bit smarter but all it does is it looks at that data object and if it has a URI it does some light processing on it. So if it's prefixed with entity or internal we need to make some adjustments to make it an actual link that can be used. If the title exists in that object it sets the title attribute and then when it goes back to the render method it will just use those things if they've been set. So that's starting to get a little bit at the data aspect of this but another thing that we ran into pretty quickly looking at these components is what if we wanted to manage application stage across a variety of these components rather than thinking of the one example of just the menu component. So remind everybody of the menu component here and all you have to do is pass in essentially a base URL and the menu ID and this component does the work of talking to Drupal, getting the stuff, parsing it out, rendering it as a menu which is great. And here is a little bit more detail on what's actually happening behind the scenes. So one of the life cycle hooks when the component mounts calls this fetch data method and not the most complicated JavaScript in the world here but it using the base URL and the menu ID it structures, it determines the endpoint that it needs to talk to or the core's upcoming menu endpoint and then it just uses JavaScript fetch to call that endpoint, get the data back, there's light error handling and then it also processes and parses the response so that it is a nice hierarchical structure that you can use. So again, not a ton of logic or JavaScript here but a sum and it's all embedded within the component but really quickly as we try to apply that in other places that concept just doesn't scale somewhat obviously so think of the card that we saw before if you take this approach and you got one card on the page that's one fetch request and you might already have one for your menu if you got 10 cards in a grid that's 10 of them if you have 100 cards or some sort of auto scroll that starts to get pretty problematic and really what you want is a place where this data can live that all of the components can access and share. So that kind of led me on a pretty long tangent away from this project working on a project called Drupal State and this is another thing that I've given a full talk on at past DrupalCon so there's a link there if you want to learn more but at the highest level it's a library that makes it easier to communicate with JSON API and has lightweight state management. So it's framework agnostic so it works in any JavaScript framework or no JavaScript framework at all works on the server and the client and at its like highest level it will if you ask for an object from Drupal's API it will first check local state to see if it's there and then if not it will request it from Drupal's JSON API and then if you ask for it again in the life cycle of the app it will get it from local storage if it exists so that'll cut down on your API calls and also by default it represents the data in a flattened DC realized structure JSON API still is a little nested has some Drupalisms not necessarily what JavaScript developers who are either not familiar with Drupal or not familiar with JSON API expect so that makes it a little bit easier to work with in my opinion. So this is a really super quick example of what that actually looks like in practice so we can import Drupal state and then create an instance of the store so we provide an API base it's also possible to provide an API prefix it's optional by default it's JSON API but if you have your API under some other prefix you can specify it there's a handful of other options that you can use here but that's enough to get you going and then if we wanted to get recipes from the Drupal site that has the umami demo data it's as simple as creating a constant and then store get object and then providing the object name so a node recipe in this case and what that does behind the scenes it calls out to the root of JSON API it figures out what the endpoint for node recipe is and then it will parse all of that data and return it and store it in local state so you'll see here that the result on the right hand side it's nice and flat things aren't nested under attributes or includes like in the traditional JSON API response and then if we ask for a particular recipe after doing that so we provide an ID here it's just gonna get that from the local store since it already has that recipe with that ID and it doesn't have to make another call to Drupal so that utility in and of itself helps for a library like this at the time that we started working on Drupal state there really wasn't and there still really isn't any sort of common set of utilities for talking to JSON API there's nothing under the Drupal namespace on NPM there are a handful of different clients but they all do things differently some have assumptions baked in for specific JavaScript frameworks but having this utility that can interface in a reliable way with JSON API opens up the possibilities for a design system like this so the next step there is how can we continue to make it easier to get data from Drupal when working with components in the system so what if we created a web component that could just source data from Drupal and with Drupal state as a dependency that sort of thing becomes possible so just like we've seen before we're just importing the components in this library and then we created two new components a store component and a provider component so the store is really similar to what we saw when we created the instance of the store in the previous example we specify what the Drupal endpoint is and then any provider inside of that store it's essentially an interface to like that get object request that we saw so it can use the store to get data and store it so if we say here that we wanna get a new recipe with a specific ID and include additional reference entities on it you'll see here that we have a card that renders out so yeah about the card so inside a provider you can use an HTML template which we see here and that can be any valid markup custom elements anything so it can be traditional markup like we see down here so you can just use the HTML that you know and love it could be custom elements from this library it could be any custom elements so there's the outline library from phase two which is another set of Drupal friendly web components there's no reason that you couldn't use the outline components here in the template as well and then as you'll see here in a kind of a twig like double curly braces syntax you can reference variables that are within the scope of the provider and they get rendered out on the screen so like really simple example we have a headline here so we can just say title and now we get our deep Mediterranean quiche and then so this is the one recipe comes back here so it's just rendering out one recipe but if we remove the ID it will iterate over the template for every result so now we see all of the recipes on the site we probably don't need this markup anymore and then since this is all just an HTML templates we can also do things like if we wanted to embed styling in here so we add some light styling for it to use a grid so now we have a two column grid using CSS grid and then also this library recognizes all of those custom properties so we can add a few custom properties to clean up the cards a little bit give them a little bit more of a matching style add some flair to them and all of that really just within markup so this isn't necessarily the only way that you might want to source data from Drupal to use with these components but I think it's really cool that you can do all of this kind of inside just markup or you could use these components separately if you want to so yeah I think we're just about up on time here so a few last things thinking of this generic Drupal web components project if we wanted this project to be sustainable it really in my opinion needs to be a community effort and not a solo project not just because I only have so much time to contribute to it but really if this is going to be a thing that is useful to a lot of front end developers who are using Drupal it needs to represent the needs of a lot of front end developers who are using Drupal there's a meta issue that is just kind of a clearing house for components that people might want to see built there also is in the library a scaffolder probably don't have time to show the example but you can run npm run create component and it scaffolds out a component for you that takes advantage of the styling hooks that we talked about so feel free to just kind of spin it up and experiment we welcome your contributions but also if you're just looking for a way to experiment with web components and lit might be a decent way to do that as well and this last thing so you know I think that if this library is able to continue to evolve I hope that it can be useful another area that I think could be a really important offshoot from this work or just work around web components in general that is a pretty hard problem is server side rendering of web components in PHP we touched on it a little bit before you know these things require JavaScript to mount you know it is not in my opinion an unreasonable expectation that there will be some functionality on your website that requires JavaScript these days however being able to have things server side rendered so that the JavaScript portion is a progressive enhancement is certainly better and as I mentioned there's been a lot of work in the Node community to be able to solve this problem for JavaScript projects but I don't yet see a clear path to how Drupal can solve this and literally render out all of the markup necessary for a web component in its traditional template so that on the initial load all the stuff is there and then the JavaScript part is progressive enhancement if we can solve that problem I think that would be great for Drupal great for PHP projects in general so you know hopefully more to come there and you know up on time but definitely want to thank a handful of contributors who contributed to the menu web component as part of the couple menus initiative we had someone participating in summer of code that contributed some new components others who dropped in and made some useful contributions people who have made a lot of meaningful improvements to Drupal state and I probably missed some people and I mean everybody here thank you for contributing to this inspiration quiet down so yeah I passed time but perhaps if the talk was over and you had questions we might be able to talk about it oh thank you thank you very much thank you thank you yeah any questions if not now I'll certainly be around the next couple of days we'd love to talk more yes how do we get involved do we go to that meta issue yep yeah how to get involved go to that meta issue so it is a Drupal.org project it's a general project on Drupal.org even though it's published on NPM there's issues in the issue queue meta issue great idea to throw ideas out there as interest has begun to increase we also have a Slack channel in Drupal Slack I think it's just generic Drupal web components so people are kind of throwing in ideas there or just general web component learnings can you throw that QR code back up? yeah love it question was can I throw up the QR code and the answer is yes yes are there any accessibility considerations with web components? ah yes are there any accessibility considerations with web components yes I would say that there are not many that are specific to web components but a lot of the considerations that you would have to make for accessibility elsewhere apply so you know the markup that you're creating in your web component should be accessible from a accessibility standpoint there are certainly advantages for the JavaScript piece being a progressive enhancement rather than you know the component does not exist until JavaScript loads things like that but those same sort of problems you know exist with the JavaScript frameworks I'm not aware of I might just not be aware of it but I'm not aware of any web component specific accessibility cool alright thanks everybody and yeah I'll be around when we talk more you're welcome