Brian Kardell: Okay. Hi, I am Brian Kardell. I'm a Developer Advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a Developer Advocate at Igalia.
Brian Kardell: And on this episode of Igalia Chats, we're going to talk about web components. They kind of seem to be having a moment where they've captured the attention of a lot of bloggers and things, right?
Eric Meyer: Yeah.
Brian Kardell: Including this guy, Eric Meyer. Meyerweb is his domain. I don't know if you read his stuff.
Eric Meyer: No, I try not to.
Brian Kardell: Yeah. You recently posted a thing, Blinded By the Light DOM.
Eric Meyer: Yeah.
Brian Kardell: Yeah, I don't know. Do you want to...
Eric Meyer: What the post is about is me going into a deep dive as to, 'Hey, here's a fully light DOM web component that I created,' and also doing this was the moment where I realized that custom elements and fully light DOM web components are cool actually, whereas for a long time, web components, it's just like I didn't get it. And there have been a number of posts along those lines. Jim Nielsen had a Using Web Components on My Icon Galleries Websites, which is one of the things that sort of bumped me to the point where I could have this breakthrough. He has a bunch of galleries of icons that he has collected, so he has all of the icons from the 1Password app for several versions. It's online that anyone could look at. And he wrote this post about how he redid his icon galleries to use web components. And when I read it I was like, 'I don't quite get what he's saying, but I can tell that there's something here that I should be interested in.' Which is nothing against Jim. He had a perfectly fine post. It's just like I didn't get it yet. And there's stuff that you've written, Brian, that again, nothing against you, but you've written about web components in the past and I read about them, I was like, 'Yeah, that seems cool, but I don't get it.'
Brian Kardell: I mean, this is kind of a statement on writing and evangelism and adoption of features in general, right? I think there's always that, 'Should I write about X? Because X is really interesting to me.' But I don't know, maybe 100 other people have already written about that. The answer is yes, because if you are just discovering it, you're just getting into it, the previous attempts really haven't reached you, so maybe you take your thing and you reach a whole bunch more people.
Eric Meyer: Yeah. I mean, always write about it because it might only be one other person that you achieve that breakthrough for, but that's one more person. Maybe they then, in the course of talking about what they learned, they reach a whole bunch more people. Or maybe when you blog about it and somebody notices it and it sort of goes viral, that leads to the break in for a lot of people. We don't all understand things in the same way. We don't process things in the same way. So sometimes what maybe you're waiting for is for someone to explain it in a way that you get, whereas maybe the other people explained it in a way that other people got but you didn't. But yeah, absolutely. And it doesn't have to be like my post, which was over 3,500 words. I went super long. A lot of the kids these days would be like, 'Yeah, TLDR.' But from feedback I've gotten on social media and in comments on the post itself, because I actually do allow comments, people have said, 'Wow, I finally get it.' And I had that moment just a little bit before they did, and I think Jim Nielsen maybe had that moment a little bit before I did. People like you and Jeremy Keith had that moment a long time ago. But for whatever reason, for me personally, it didn't sink in. And part of me thinks that, in my case, I probably had too much baggage, I'll be honest. From having written HTML since late 1993. In a month, it will have been literally 30 years since I wrote my first HTML document. Well, actually less than a month now that I look at the calendar. So I just had all these builtin assumptions that I wasn't reexamining, and the confluence of a few factors helped me break through that. There are probably other people who don't have that same baggage or who have different built-in assumptions and maybe your post that you put up, you person listening to this, if you discover a thing or suddenly understand a thing, write about it because somebody else might see that and you help them have the breakthrough that maybe they had been looking at a thing for years going, 'Yeah, it seems interesting, but I don't understand why it's useful.' Most of us had that moment at some point reading an article about CSS custom properties.
Brian Kardell: Yeah, I think that's a great example. And going back to that whole thing I was saying about the adoption curve and everything. When we begin to adopt things, typically, it's pretty basic simple things. It takes us a while, it takes people to push the envelope and then write things that are interesting, new ways of looking at or thinking about things. We'll be several years into a thing in general before really even anybody is doing the super, super interesting stuff because it takes a while to get your head around it and all that.
Eric Meyer: Yeah.
Brian Kardell: Yeah, so your example with custom properties, people are doing just phenomenally amazing things with custom properties now that I wouldn't have imagined, but they didn't do it 10 minutes after we released custom properties, right?
Eric Meyer: Yeah. I mean Roma Egorov, who we just had on the show recently is doing just mind bending things with custom properties that I would never have imagined. But like you say, Roma probably wasn't doing that 10 minutes after they came into contact with custom properties. They learned how to use custom properties at a basic level and then they started to push the envelope. They saw other people pushing the envelope. Sometimes that kind of code tennis for those who remember Photoshop Tennis or Layer Tennis. So Layer Tennis was a thing where two designers would be signed up for a 'match'. The first of the two would be given a Photoshop file and they'd have 15 minutes to do whatever they wanted to it, and then they would send the result to the other person in the match, who would then have 15 minutes to do whatever they wanted to, send it back, and they would go back and forth like five rounds or 10 rounds or something like that. Sometimes code tennis happens. That's been happening between me and Miriam Suzanne around web components. So I put up this post and I had some CodePen examples to go with it, and Miriam forked one of those examples and did some new stuff to it. I was like, 'Whoa, this is cool.' So I forked her fork and did some stuff to it and shared it with her and she said, 'Oh wow, some of this is cool.' And just like restructured. We were learning as we went, and anyone who watched that back and forth might also learn stuff. There were people who were watching this exchange, people who followed both of us on social media, and so could see our replies to each other who said things like, 'You can do custom events?' Which was a thing neither Miriam or I knew when we started, but it came up and it turns out, yes, you can do custom JavaScript events. You could just make up your own events and nobody will stop you.
Brian Kardell: For a long time. That one predates custom elements even.
Eric Meyer: I didn't really know that. Miriam apparently didn't know that and also didn't know about dispatch element, but I was using, in my example, I was creating a custom event and then dispatching it to cause a thing to happen. So Miriam riffed off of that and there were people saying, 'Oh wow, this is cool.' And actually another person chimed in, I think, today or yesterday saying, 'I had forgotten about this capability of custom events, but this whole back and forth using custom events reminded me of it in work I was doing today that made a really complicated thing I was doing way easier.'
Brian Kardell: Yeah, I love it when that happens.
Eric Meyer: Yeah. Even sometimes it's not so much your post will teach someone something new, it will remind someone of something that they did know but had never really used, or for some reason, had fallen into disuse. Or might cause them to see a thing that they already know about in just enough of a new way that they realize, 'Oh, I could use that for this thing that I'm working on and it would make things so much cleaner and easier.' Stuff like that is really cool. This is why some of us still blog and it's not all Stack Overflow and MDN, which don't get me wrong, a good deal of the stuff that I learned as I was doing this web component work, I looked up on either Stack Overflow or MDN, but putting them together and showing my work, literally I was like, 'Hey, this is how this works.' For some people, been really, really, really helpful. That's one of the things you have to keep in mind. That's always a possibility because you and I, I think, have both discovered a lot of times you'll just put so much thought and effort into saying a thing and it's crickets. Just for whatever reason, nobody really responds or shows interest or whatever, and then the thing that you never expected would change somebody's life does.
Brian Kardell: That is so accurate. I just can't even... You don't even have to get into just the things that change somebody's life. I mean, you can just look at social media too. Sometimes you write some very deep thoughtful thing and you share it on social media and it just seems to get nothing, and then you make one offhanded comment with five seconds thought into it and suddenly it explodes and it's this huge thing, right? It's completely unpredictable.
Eric Meyer: And it's the same thing with blogging. Yeah, I mean web components are just... I feel like, at least in the circles that we run in, there's sort of an awareness of, 'Oh, okay, wait, this is a thing that we can use to augment the web.' So Jeremy Keith just wrote about this where he was sort of casting about for, what do we call this? What is this? And actually he didn't exactly propose the term web augmentation, but I kind of like it because I think in some of the best patterns of using custom elements and light DOM web components, you're augmenting what HTML already provides. The post that I wrote about what I call super sliders, which is range inputs that have extra things associated with them through the scripts and the markup of the web component of the custom element, I didn't re-implement range sliders and I didn't re-implement buttons. I just used input range and button elements, stuff like that and just used JavaScript to sprinkle a little extra on top basically. And not to make them look different. In fact, I don't think I even tried to style the range input. It's just, as you change this input, the component has patterns that let you say, 'Okay, when this input value is changed, the effects are applied in this other place,' in sort of a very modular way, and Miriam made it even more modular. That was part of the code tennis that we were doing where she was taking what I had put together and making it much more flexible, more generic. Generic is not the right word, but you know what I mean. So that rather than being very focused on, 'Okay, so this is about changing font sizes,' she made it so that you can change this range slider and you can say what it's supposed to change, and then the JavaScript just looks at the markup and says, 'Okay, this is what we're doing.' Which is really useful, and now I want to completely rework the tool that I created that I was writing about in my post to use her pattern. I'm not going to do it, but I want to.
Brian Kardell: Yeah. That's really fun. And actually, it was one of the ideas with the extensible web manifesto was that we were supposed to go out and invent these because exactly that kind of thing happens in the wild. You can say, 'Hey, I have this really great idea and I've thought about it so deeply and here it is. Anybody can use it.' And very, very quickly somebody will come in and say, 'Oh yeah, but what if we just... And we'll improve it.' Right? And then the idea was things can compete in the wild and very, very rapidly improve and then we will have some component that is like this that winds up used everywhere. And then we can say, 'Boy, maybe we should just have that element. That would be really great, just have a standard version of that element or something.' I really love that that happens. One of the things that I think has always hung it up from happening more is that there's no great way other than here is a single author or a single component library made of web components that I like and trust for you to discover them and have any sort of faith or sense of them.
Eric Meyer: Yeah.
Brian Kardell: That's a thing that I also tried to set up. I think I mentioned this in our Brad Frost talk too, where I think we talked about web components kind of a bit in that one where I thought we should focus on that somehow. We should set up a sort of underwriters labs for web components where you could submit them and get other people to review them from cross-disciplinary, this is accessibility, this is performance, this is stylability and so on. And then you can help the cream rise to the top that way. But yeah, I love that that happens. I wanted to mention that Jeremy Keith wrote a really good post in 2016 that was called Extensible Web Components where he talks about some of the same things that you talk about, and I think we should highlight them here because I see repeatedly people discover similar-ish things and maybe we can just talk about them a little bit and mouth blog them. So it is very, very tempting for you to mint a new element that is just the element itself. The example you could use in yours is fancy slider, right?
Eric Meyer: Right.
Brian Kardell: You could just make a thing called Fancy Slider. It just has the attributes on it or whatever, but that's it. It's just you put the element in and good. But if anything goes wrong with that page or there's no JavaScript or whatever, while the page is loading, it's just empty. There's nothing there, right? It's just like putting an empty span in your page. That kind of sucks. The alternative to this is that you decorate some otherwise good HTML and CSS anyway, so like in your example, you put an input inside it and you say, 'This is what it's based on and you provide the raw materials and we'll just decorate it.' And that is actually the design of web components is supposed to be toward that. There is this tension in web components where when you define a web component, you say, 'Extends HTML elements.' Do you know what I mean, in the class?
Eric Meyer: Yep, I know what you're talking about because I actually did do that just recently.
Brian Kardell: Yeah, so you have to say, 'Extends HTML element,' and there was an idea in there that you could extend other elements so that you would inherit. But the reason that there's a tension there is that inheritance is limited and flawed. When you say something is a that, it means it is, and the trouble is it isn't. You have other parts of your fancy slider that aren't just the range. They're more. They contain more than just the range or else, in many cases, not all cases but in many cases, why would you be building it, right?
Eric Meyer: Yeah.
Brian Kardell: So there's this kind of tension, and this is an old observation and it's called the Liskov Substitution Principle that guides this and there's also the famous gang of four design patterns book that stresses composition overinheritance. So you're adopting a pattern that is saying, 'We're going to use composition here. You're going to give me these raw materials and I'm going to build something more than just their parts.' That's usually a better option anyway. I think it's great that people discover that and wind up there on their own and say, 'Boy, that is a really good idea.'
Eric Meyer: I think what you were talking about is there's the pattern where you can say something like, 'Input type equals range is equals super dash slider.' And then in your web component JavaScript, you are saying, 'Class super slider extends input.' I forget the exact syntax, but you basically say, 'This web component is specifically a customization of range inputs or of text areas,' or whatever element it is that you plan to extend, and then in your markup you have to say, 'This element is of this type.' And that's where you are modifying things that are already built into HTML. You're extending the elements themselves such that-
Brian Kardell: Or you would be if such a thing actually worked.
Eric Meyer: Okay. Whereas the other way to do it, which is the way that I was writing about is termed more composable or it is composable where you wrap some custom element name like Super Slider around an input type equals range and whatever else you might put in there, a button to reset it or whatever. It doesn't really matter, but you're wrapping this element name that you made up around native HTML elements. Then your script is adding things on top of that, but they're still just whatever elements they are inside so that, like you said, if for some reason the JavaScript fails or doesn't load or uses some pattern that 10 years from now isn't even supported anymore because it was discovered to be an enormous security risk and browsers no longer allow it, then you still have a range slider. Rather than the sorts of things that sometimes we think about doing, which is, 'Well, I'm going to make up this element and I'm not going to use any HTML in it because I'm inventing new stuff, so I have to do the whole thing myself. I have to do it all myself and I can't rely on the browser for anything.' When, 'Okay, maybe there are situations where that's necessary,' although we have so many capable elements now, I can't think of anything where you couldn't rely on existing HTML elements, but that's actually really fragile. Jake Lazaroff had, I think, a really good post about this.
Brian Kardell: Oh good. I'm glad you're bringing that one up.
Eric Meyer: Yeah, titled Web Components Will Outlive Your JavaScript Framework, which is talking about basically what we're talking about here saying, 'Hey, if you do web components that are based on actual HTML with a little bit of just light touch JavaScript,' just as much as you need and no more, then that is much more likely to live and be workable over long periods of time than if you use something like React or Svelte or Vue or whatever that doesn't take this approach where everything is sort of made up and there's JavaScript that takes this sort of made up markup and turns it into HTML. Because that's what those frameworks do, right? React at the end is outputting HTML and CSS and JavaScripts. It has to or else the browser won't render it. And if React one day follows the path of every other framework ever, which is it falls out of fever and becomes less desirable or whatever, just people aren't using it anymore in 10 years, let's say, your React site could be at risk of falling apart. It's like, React, nobody supports that anymore. Whereas if you just use the basic HTML and sprinkle a little bit of JavaScript on top of it, what we call 'vanilla JavaScript', it doesn't use pre-processor or frameworks or extra libraries or whatever, that is much more likely to be functional over long periods of time, not just web long periods of time, actual long periods of time. Decades.
Brian Kardell: And when you decide to move your blog from WordPress to 11 to some custom new thing in five years, your custom elements are still going to work flawlessly, and I've seen that work across an enterprise where there's 20-30 applications that are all sharing web components that are using different technologies to assemble the pages, and that's pretty amazing.
Eric Meyer: Yeah.
Brian Kardell: The main point I think here that a lot of people are latched onto are this light DOM. You could use the light DOM, and an interesting thing that I don't know if people necessarily realize is that shadow DOM is not part of custom elements at all. It's specifically designed to be separate from custom elements. At the time we were making all those proposals, there's Dojo and Ext, Sencha, it is now I think, and there's YUI. There are all these widget libraries floating around out there that basically you just put some hook in the DOM and then you call this magic function, or you put some classes on it and this magic function discovers them. jQuery UI did something like that and it magically writes a whole lot of DOM for you, right?
Eric Meyer: Yeah.
Brian Kardell: So there's two ends of that. One is you don't have to just put classes or worry about you figuring out when to scan the page for when those classes appear or something. Custom elements give you that part, right? So if you want to do that, you can do that, but even if you don't want to do that, there is a problem, I'll say. It's not a problem because we built exceptionally great things this far with just the light DOM, and for a whole bunch of cases, yeah, you should just continue to do that. If that works for you, then you should just continue to do that. But if you take your fancy slider now and you start distributing it to people and people start using it in all different kinds of contexts, dynamic context and things like that, if you're putting magical new elements in the tree, there's all kinds of new questions. What happens if somebody puts something before the element that you're expecting or after the element that you're expecting? What happens when they query selector expecting that the tree is exactly what they put in there and now it's different, or they write CSS classes that think about the last child or something? It's very easy for you to start getting into these friendly fire situations.
Eric Meyer: Right. Yeah. Name space collisions in effect because-
Brian Kardell: Yeah, right, exactly.
Eric Meyer: ... if you happen to use a class name in your page that is the same as a class name that the component is expecting, then you could end up accidentally turning your component to have a red background or something.
Brian Kardell: Yeah, absolutely. And a lot of components do use at a very basic level some similar concepts, like a class BTN is in so many things, right?
Eric Meyer: Yeah. btn for button, btn dash something.
Brian Kardell: Yeah, yeah.
Eric Meyer: Sometimes it's btn to say, 'Here's how I want style my button.'
Brian Kardell: Or more often, 'Here's how I want to style my div.'
Eric Meyer: Okay, true.
Brian Kardell: Yeah. So that was part of what shadow DOM was intended to solve was to allow component creators to create abstractions that were compositions to say, 'Hey, browsers do this internally. If you inspect, you can see the video element is full of buttons and spans and divs and classes.' Because they just use the same stuff as we would to build a video player in terms of the DOM parts at least.
Eric Meyer: But they're encapsulated, as they say.
Brian Kardell: They're encapsulated, but-
Eric Meyer: I think of them like iframes, which I understand is both apropos and completely inappropriate in various ways, but I think of a video element as being its own little iframe and all the stuff in there is just styled according to the stuff in that little box, that little encapsulated thing. And that's what shadow DOM is supposed to do, right? It's supposed to basically say, 'Okay, this over here is just in its own little capsule. It's encapsulated and your styles from your page do not cross the boundary into this little capsule, and the styles in this capsule do not break out to the page.'
Brian Kardell: Yeah. It's funny that you used the word encapsulation because that is actually a driving part of this story. So do you mind if I do some history?
Eric Meyer: Please.
Brian Kardell: I said this before, but people have wanted custom elements since 10 minutes after Tim announced HTML, right?
Eric Meyer: Right.
Brian Kardell: Cool, but how do I make my own elements? It's a natural kind of question. It seems very natural. Web components is not the first try at that. There were several tries, and the concept of a shadow DOM predates all of this. So the current web components is born from the ashes of another effort that was called XBL 2.0, which you might know replaced XBL 1.0. You would say built on, but it really kind of replaced because XBL 1.0 didn't really do a thing.
Eric Meyer: XBL was Extensible Binding Language. Is that correct?
Brian Kardell: Yeah, we liked our Xs back in the day.
Eric Meyer: We sure did.
Brian Kardell: Yeah. But it had a concept of a shadow DOM. It was a rather vague concept, but even SVG from the very beginnings had a shadow DOM, so this notion that there's this thing that's not your view of it from the tree is not the same as my view of it from the tree. You write this, but what the browser really has internally is more.
Eric Meyer: Yeah.
Brian Kardell: And that more is currently anyway, just more of the same. It's more of the same DOM stuff. When this was being worked out, this new generation of proposals that would come under this banner of web components, very quickly, there was a lot of engagement from... It was being proposed by this Parkour team at Google who had been working on it for kind of a long time, and there was a lot of engagement from Apple and Mozilla and even community people. In trying to describe this thing that is complex, unsurprisingly, we didn't have terminology that was great, and so people began throwing around those comparisons and also using lots of words that we try to use in programming. So there was isolation, encapsulation, and it very quickly got confusing because what is encapsulation? Is it what an iframe does? I mean, an iframe definitely encapsulates things, right?
Eric Meyer: Yeah.
Brian Kardell: So Maciej from Apple, the now is I think their director of WebKit, or at least the lead head of engineering for WebKit, he wrote this sort of seminal email that then drove a lot of things where he said, 'Okay, we were using all these different words, but let's take this one encapsulation and I would like to talk about... I think that there's many different kinds of encapsulation. Who are you trying to encapsulate from what?' Anybody who's listening about this who doesn't know about shadow DOM, the handiest way that I can think to explain this and what I wish the whole thing would have been is we have nodes, and nodes are just these constructs in memory that we can say represent a tree, but there is no tree. It's just pointers that happen to be parents and children, leafs and things. Shadow DOM just said, 'Okay, look, everything in the DOM works off this concept of parents and children, so what if there was just a pointer that was like a way for you to connect to this DOM, and then it doesn't just mean parent and child, it means this other kind of connection that you don't have to...' Everything just sort of works out because your style sheet on the outside, no selector will automatically cross that today, right? No query selector will select into that because when you walk the DOM in either direction, the chain is broken. You can't walk up because it's not a parent, you can't walk down because it's not a child. In retrospect, this has been not the greatest in a lot of ways because we see lots of requests for open style, little shadow roots, or slots in the light DOM. Basically people are like, 'It's too much,' right? It's too much.
Eric Meyer: Too much in the sense of being too closed the way things are now?
Brian Kardell: Yeah, in some ways. And in other ways, maybe it's not closed enough because your JavaScript, it's all global. It all has access to global in both directions, unlike an iframe, right?
Eric Meyer: Right. This whole confusion is, I think, a lot of why I have to admit I've just never shadow DOM. I just don't. Even though I sort of get the problem that it's trying to solve, the idea of I want to be able to have this little thing over here that's its own thing so that I can plug this thing into multiple pages is one way to use it. You create a web component that is attached to pages via shadow DOM, and so each of those components is sort of its own little thing and they don't conflict with each other. They don't conflict with the main page. I get that that can be useful, but just this whole, it's closed but it's not closed and maybe it should be less closed, but maybe it should be more closed. Just the way that it sets up this barrier that is difficult to cross has just never really sat well with me. I mean as a lot of the preexisting assumptions that I brought to web components in general, that probably kept me from understanding web components sooner and making that sort of breakthrough of, 'Oh, these are things that I can do,' because the things that I'm talking about in my post, and Jim and Jake were talking about in their post, Jeremy, you, these are completely light DOM. There's no shadow root involved. There's no shadow DOM at all. Everything is in the light DOM. Everything is completely accessible from the page, and in some cases, that might be a problem. So these are not going to solve every scenario, but they really work for me because it's like, 'Okay, well everything's here. I can style everything. I can script everything. I can talk to other parts of the page very easily from my component.' And that, to me, just fits better with my way of viewing how the web should work, better follows the grain of the web, and shadow DOM just has never seemed like it does.
Brian Kardell: I think the browser itself uses shadow DOM.
Eric Meyer: I know, and yet.
Brian Kardell: I think this is part of the trouble is that we don't have the answers at the start. To me personally, it feels like we missed some important aspects and use cases that have hindered the adoption of even custom elements, even though custom elements have nothing inherently to do with shadow DOM. But I think things that we missed at the time were treating everything as if they're a single ish case. One of the things that I see now is that we do have other cases. One that I have brought up in the past is what's a useful thing to use shadow DOM for maybe is there's lots of elements that are like, 'Here's a markdown processor or Akismet or a LaTeX processor,' that you, as the author, can just put in markdown or whatever. When you do that, you don't want to destroy the original content because you want it to be there and you want it to keep being edited and you don't want to be just constantly changing their whole tree, but it's not a secret what this component is doing. I'm not trying to hide from you that it's creating headings and ems and strongs. I want you to know that. It's actually the point of this component. So I feel like in those kind of cases, you just want your CSS to come through. You want your headings to look like your headings and your paragraphs to look like your paragraphs. That's a mistake to not have some means of cooperation there. That barrier is way too hard for those kinds of use cases. We don't have any solution for that. There's three or four different things that we've articulated in terms of what a more open shadow route might be like and why you might want that, but it's tricky because I really do think that there is a important role for something which will be shadow DOM. Because of the barrier, we missed a lot of important accessibility questions because accessibility in aria is almost all IDREF, and IDREFs are a global mechanism, and well, they don't cross the boundary. We have some answers to a whole bunch of those questions is not complete, but in the AOM work, which I think is great, and there's implementations in browsers of ways to do element references that do work in some of those cases. Work on that was done by Alice Boxhall, who's now here at Igalia, and some of that work was paid for by Salesforce.
Eric Meyer: Cool.
Brian Kardell: It's still very, very hard though. And the constraints, the goals of this have made it even harder.
Eric Meyer: Yeah. But I mean, we're making this up as we go. We're making the web up as we go from a technical perspective. I mean, from a content perspective certainly, but from a technical perspective, we have been pretty much since the beginning. This is why stuff gets into libraries and pre-processors and so on and so forth, and then eventually get folded into the native platform. We try things like XBL, and that didn't really work out, so we try XBL 2.0 and that didn't really work out. So there are these other proposals and eventually we come up with shadow DOM and shadow root and that worked relatively well, but now we might look at it and say, 'Okay, with the benefit of hindsight, it turns out maybe we should have done these things differently.' In some cases, we realized maybe we shouldn't have done the thing at all, like the visited styling. Eventually we realized, 'No, we should not be doing that for security and privacy reasons.' Because it turned out, yeah, it seemed like a good idea at the time, but turns out it wasn't.
Brian Kardell: Yeah, we're making it up as we go along and we need experiments. I think that the real primitive things that can only be done by the platform, there's no way other than for somebody to implement in the platform and try to get as much experimentation and feedback as possible. There's no other way to do that. And this plays off that thing we were talking about earlier about how it takes a long time. You have to have the thing for a long time before you can really realize how to use it well.
Eric Meyer: Yeah. Your design has to make contact with the real world basically. The CSS Working Group has been through this problem more than once where their design made contact with the real world, and sometimes it worked out great and other times less so. CSS Working Group maintains a page on their wiki of things we will fix if we ever get our hands on a time machine.
Brian Kardell: Yeah, yeah, absolutely. I think everybody should have one of those pages. I wonder if we have one actually for web components. It'd be an interesting thing to do. There's a web components community group. Did you know that?
Eric Meyer: I think I did actually.
Brian Kardell: Yeah, you could join that. That seems like it would be a fun community group activity, sort of critique that, and I kind of doubt that it would match what it would be if WHATWG did it. People will have different impressions about what was a mistake and not. I mean, this is why there's so much stress on use cases, right?
Eric Meyer: Yeah.
Brian Kardell: The trouble is I feel like we couldn't see the use cases from there that would be popular. I guess that's my take in the end. Like I said, there's thousands of custom elements out there, tens of thousands of custom elements, maybe hundreds of thousands of custom elements. Way too many probably. Maybe these use cases are... What percentage are they, and how much do we invest in them versus how many we're not covering? That's where I think you have some interesting things to think about.
Eric Meyer: So share your thoughts.
Brian Kardell: Definitely.
Eric Meyer: I think that's where we're coming. And web components. Web components are pretty cool.
Brian Kardell: Yeah, custom elements.
Eric Meyer: Custom elements. Very cool.
Brian Kardell: I think that's part of the problem. The banner we chose, web components, includes lots of things together that could be used to make the same thing that the browser has. But custom elements, they're just a way to plug into the lifecycle of the DOM, and that is pretty sweet.
Eric Meyer: Yeah. So if you're listening and you haven't checked out custom elements, maybe put that on your to-do list of things to just check out and play around with because they're very interesting. Thanks, Brian.
Brian Kardell
Eric Meyer