Eric Meyer: Hello and welcome to Igalia Chats. I am Eric Meyer, a developer advocate at Igalia.
Brian Kardell: And I am Brian Kardell. I'm also a developer advocate at Igalia. And on today's show we invited back a repeat guest, our friend Miriam Suzanne.
Miriam Suzanne: Hi. It's good to be here.
Brian Kardell: We invited Mia on to talk about custom elements and styling and Shadow DOM. And particularly there's this thing going on, we've said before, that custom elements are sort of having a moment. We had a show a couple of episodes ago where Eric wrote a number of posts about ...
Eric Meyer: It was really just one post that was incredibly, incredibly long.
Brian Kardell: If you mean only those posts, but there were a lot of posts on social media and things like that that were going back and forth that were talking about Eric discovering custom elements and going, 'I thought that custom elements involved the Shadow DOM.' That was part of it and that prevented you from trying them out and adopting them, right?
Eric Meyer: Yeah, which I also got into in my stupidly long post. But yes, that was the perception that I had, was that the whole point of web components was there was a special Shadow DOM and you did stuff so that you could plug components into a page one time or many times. And what you were plugging in was encapsulated in its own little world. And then I realized that, no, actually, you can do that, but you don't have to. You can keep everything in the Light DOM and not have to mess with a Shadow DOM.
Brian Kardell: Yeah, they're bundled up under this banner with some other things, too, but mainly custom elements and Shadow DOM bundled up under this banner of web components. And I think they got meshed together. Why exactly do you think you might even want Shadow DOM? Because like Eric said, you don't need it, actually, for a whole bunch of stuff. So if you're building the components that you're talking about, your website and you're just like, 'Boy, I just find myself repeating myself a lot,' and a lot of these elements are in here for honestly just styling hooks and some Meyer stuff or I have these couple of event handlers that I just hook up and I want just an easy way to make sure that they get hooked up, regardless of when they're put in or whatever. Custom elements, you can use the Light DOM and what you're doing there is a transform, this old ... It's basically what we used to do with jQuery. It's go into the dom, find this dom and turn it into some other dom. The trouble is ... Go ahead. What were you going to say?
Eric Meyer: No, I was laughing.
Brian Kardell: Yeah. The trouble is that this creates a problem where when exactly does that happen and how do you manage an active lifecycle that things could get added later? And everybody's trying to reason about the DOM, but nobody can. The person authoring the component, they can't reason about the DOM once it's been created in the page because we don't know what the user put in there or what the user might do to it while the program is sort of running. And the page author can't know what was being created. That's kind of the point. So if you get into more complicated use cases and applications and long-lived things that have lots of script and complex composite things, then what you want is the ability to make some abstraction, like the video element. And then you want to be able to expose parts of it as not their individual DOM nodes, but as this is the play pause thing. And you can style that specifically.
Miriam Suzanne: Or on a range slider, we've got a track and a thumb.
Brian Kardell: Exactly. That's a much better example. Thank you. And it does seem that the Shadow DOM is offputting at least. It's something new and different that we don't have experience with that we haven't done before. And it closes you off from the things of CSS, which is kind of part of the point of it, right?
Eric Meyer: The Shadow DOM part, yeah.
Miriam Suzanne: Or old and different maybe is the ... It's not particularly new, but it is different from what I'm used to. And I think also the way they get pushed together in our minds, custom elements and Shadow DOM, is that when we think about components in other settings, say JavaScript frameworks, that's what we think of. It involves both a template of some kind that we get to repeat and then also the behaviors that you might attach to a custom element. So we're used to thinking of those together.
Brian Kardell: Right, but what we're not used to is that somewhere in there is an H1. And if I put an H1 in my page, it doesn't affect the stuff in there. It's disorienting in a way, right? Sometimes.
Miriam Suzanne: Right.
Eric Meyer: Yeah, the way that I at least used to, and sort of still do, the way that I think of web components with Shadow DOM is that they're kind of like iframes, except they're not iframes. But they act like iframes, at least in the ways that I'm interested in.
Brian Kardell: They act a little bit like iframes in that respect, but they have no kind of script encapsulation, so they're completely devoid of any of that. I mean, it was discussed whether that should be a thing or not. And in fact, I think that is where things get really interesting, is the history of it.
Eric Meyer: But you and I always think the history is interesting.
Brian Kardell: We do. I don't know. Mia, do you also think the history is interesting?
Miriam Suzanne: I also always think the history is interesting.
Brian Kardell: Yay. We can talk about history. No, I mean, the history of this goes back a really, really long time. The Shadow DOM, a Shadow DOM, not this Shadow DOM exactly, was part of XBL. XBL predates any of this. And I mean, we're talking about mid, late 2000s. A lot of things in Firefox were built with XBL and it stood for extensible bindings language and you could build components with it and it had this concept of Shadow DOM. And so when web components, when this effort was taken up by Google, people were like, 'There's a bunch of interesting things here, but we don't know what to do with it.' And so Google started to get into all these and the Shadow DOM thing was clear. And in these discussions, people are using these words like encapsulation. And when people were asking questions, they were saying like, 'Okay, but wait, when I make a component, I don't want the outside to mess up my inside.' Sometimes is really important. And another way of looking at that is like, 'Well, wait, I'm on the outside. I don't want you to mess up my stuff.' And so in this, Maciej from Apple, who is the director now of web kit engineering I think is his title, he responded with this email that's kind of famous now, I guess, that talked about we need to agree what we mean by encapsulation because there's at least five different kinds of encapsulation that I can list here and we're not all saying the same thing. You could think about this as you have a tree. There's no tree in your computer. It's pointers. It's pointers that are parent and child and we call this structure a tree, these relationships, but you can have other pointers in there. Even attributes are similar. They're also nodes. They're attribute nodes and text is also nodes, but they're not element parent and children. And so the thinking was like, 'Well, would we make a different connector in there that's just called a Shadow root?' And it's like because everything in CSS is based on selecting via this parent and child concept, descendants, ancestors, that will just not go through and affect the stuff inside. And so sign, but could you, if you wanted to, cross the boundary, Google said, 'Sure, why not? We're all amongst friends.' But Apple said 'none shall pass'. That's what we need. We need the Gandalf mode. And so we added that. That became the open Shadow root and the closed Shadow route. And the one that he said was most important to him was sort of the one that browsers do. You want to make sure that nobody can build dependencies based on your insides so that we can make sure that when they update, when I update, they don't break. So that's the use cases that the Shadow DOM was built around.
Miriam Suzanne: Yeah, which is an interesting use case.
Brian Kardell: It is an interesting use case.
Miriam Suzanne: It's not what a lot of people are doing.
Eric Meyer: What are people doing, if that's not what a lot of people are doing?
Miriam Suzanne: Yeah. Well, I mean, I think there's a real mix. And I can't claim to be an expert on all things web components or custom elements. I mean, I feel also like Eric's blog posts are part of what made me take a deeper look and play around with it now quite a bit, but recently and learning from the people who have been doing it longer. But it seems to me that there's a mix and there's a lot of us coming in from the outside that are expecting something a little more like components that we're used to in not just JavaScript frameworks, but even when I think back to early days of writing PHP includes. I expect there to be a template that I'm reusing across the page and I'm using it as part of a component library or design system. I mean, maybe I'm putting some things in there that I don't want to get out, but I'm not really trying to isolate it from the page otherwise. It's part of the page, it's part of my design system. It's just a reusable template in my toolkit, so I don't need all of that isolation from it. I think a lot of us are coming at it from that perspective, which is pretty different from providing primitives, like the browser does.
Eric Meyer: Okay.
Brian Kardell: I think what Mia said is totally accurate. I think that the real thing that Shadow DOM wants to solve is more a cooperation thing. It's not like we're on opposing sides of a military here. We're on the same side frequently and the trouble is it's still too easy to have friendly fire. We can accidentally hurt one another and what we need is some model for cooperation. And I think that the Shadow DOM in its current state is sort of not that, right?
Miriam Suzanne: Right. And I've been thinking a little bit about this. When I use a tool rarely, like Bootstrap, on one side there is the tool and on the other side it's very clear I am the one using it. And so there's sort of the direction of flow is one way and clear. I'm not pushing anything back into Bootstrap. I'm just importing it into my page and then doing what I want. And there's some amount of that with a web component. I can pull it into my page and it has become part of my page and I should be able to do what I want. And on the other hand, if I'm able to reach into it, that's a little bit of a different thing than what I'm doing with Bootstrap. What does it mean for me to reach into a web component as the page author and do something to what's inside? There's sort of a two-way flow. Yeah.
Brian Kardell: You can think about something like a video element is a nice one because we all know what ... We put a video tag in your HTML and it can be just a tag with the source and then suddenly there's the actual canvas that the video renders on and there's a whole bunch of buttons. There's a scrub bar, there's all kinds of stuff. And if you inspect, you can see that in a Shadow DOM. And so if you are in the outer document and you say document query selector all button, you need a way to say those are not your buttons. You don't want to accidentally select those buttons, right?
Miriam Suzanne: Right.
Brian Kardell: But the question is should you be able to select those buttons and should you be able to, in CSSm style those buttons? I don't think those are even the same question, right?
Miriam Suzanne: Well, and who gets to make that decision? Is it the person writing the component who may want to not reveal their internals in a way that makes you reliant on them or is it you as the person pulling it into your page? Who gets to make that call?
Brian Kardell: There's a lot of care taken to make sure that you can close the Shadow DOM and then it would literally be impossible for it to leak any secret out into the page, which puts it, you think, squarely in the hands of component authors. I mean, that's I'm sure what it sounds like, except that the page author can override the prototype with three lines of code and say, 'No, there's no such thing as closed Shadow DOM. Whatever. You say closed, I interpret it as open.'
Miriam Suzanne: Is this those little stickers, that if you cut the sticker now you've voided the warranty?
Brian Kardell: Yeah, maybe. Maybe. I mean, that's a good point, but I don't think that it holds up because if you designed things to work that way, that's the idea with your browser default elements. Not your browser default. Your browser native elements, is that you shouldn't be able to say query selector in and get their button. They say, 'No, you can't. That's a secret.' And if somehow you managed to, would a browser just be able to like, 'Sorry, you shouldn't have done that.' The answer is no because if that gets deployed, any important thing that has people depend on it, then we can't go breaking things. But that's different, though, than websites because websites, you do update libraries yourself. You would say, 'Well, I'm going to get a new version of Bootstrap.' And then you get it and you see that it doesn't work and you go, 'Well, I should not deploy that.'
Miriam Suzanne: Right. You're saying as a page author, you don't get to decide when you upgrade browsers. The people coming to your website decide when they upgrade the browser. But when you update a web component, you make that call.
Brian Kardell: Exactly.
Miriam Suzanne: Yeah.
Brian Kardell: Yeah.
Miriam Suzanne: Yeah, that is a big difference.
Brian Kardell: I think that's huge. So this has been a big debate for a long time and a couple of years ago there was this issue that was opened and it was called open styleable. I think it was Justin who opened it from Google. I could be wrong about that, but I was talking to Tab Atkins on a bus in Spain, actually. We had the CSS working group there and I was saying, 'We need to open an issue for this.' And he said, 'I was just thinking the same thing. We need to open an issue for this.' One of my examples was I have a markdown element where you put markdown in and it can give you the preview of the HTML as it will be rendered. This is a really common thing and that's not a secret. That's a shorthand. That's a completely different use case, a shorthand, right?
Miriam Suzanne: Right.
Brian Kardell: It's not a secret at all. And it's just really handy to illustrate exactly the kind of thing that you're saying.
Miriam Suzanne: And I think even when I look at browser components, I can see a difference there. You were talking about the video element and it has some buttons inside of it if you turn on the controls. And those aren't normal buttons. Those are special video buttons. They've got a special design. They don't look like buttons. They've got their own look, their own thing that they do. They're special and you don't want to ... You write a button style, you don't want it to apply to the video buttons. That wouldn't make sense. That would break your page, but then they've got a file input and it gives you this button. And now here's a button that looks like a default button. It's got the button for uploading a file and then the text next to it that says what file you've selected. And that one, in every other way, looks like a default button, but now it's weird that you can't easily access it and style it along with all of your other buttons. Those are really different situations, even coming from the browser. And I think we have those again with people building custom elements and using Shadow DOM. Some buttons are buttons and some buttons are something special.
Brian Kardell: Even though they're something special, when you say you wouldn't want to, I say 'don't tell me what to do.'
Miriam Suzanne: Ha, yeah... Well, I think I don't know you. That's true. I think I wouldn't want to by default. I would want to say something specific if I'm going to grab the buttons on a control for a video. I'm going to want to do that explicitly, but I'm going to with the file upload, it feels weird that it doesn't happen implicitly.
Brian Kardell: Yeah. Justin opened this issue and it turned out that what Justin opened was not like my shorthand case. It was like a completely different case. And then I believe it was Greg Whitworth who was coming from maybe Salesforce at the time. He's at Salesforce now. I'm not sure if he was then, but he said, 'I also have need for this.' And then when he described it, it was also neither what Justin was saying or what I was saying, but all of us described it as open styleable. And that is basically this is just some way to style a web component from the outside. And it sounds really straightforward on the one hand, sure, but there are three things before the issue is even open that all wanted something actually totally different. So that's kind of interesting.
Miriam Suzanne: Yeah. Yeah.
Brian Kardell: So yeah, we were talking about this and also there's this new thing that was happening at the time, scope CSS. And it was determined way back to not do scope CSS because we need sort of one primitive that explains encapsulation of style. Let's not invent two at the same time because it's hard enough to get one. So we just took it off the table, but now that's coming back and we're getting some kind of even donut scopey thing. Could you tell us about that a little bit?
Miriam Suzanne: Sure. And I wasn't paying close attention to web standards the first round. I mean, I've done a lot of research on what it did the last time because I helped design the new one, but the new feature is entirely CSS based. It's sort of a totally different mental model from either Shadow DOM or some of how the old feature worked. The idea is entirely that a style can decide for itself or a selector can decide for itself that it should only match within a certain segment of the DOM, but that's also done by selectors. So you've got selectors for every part of this and that's different from Shadow DOM, where it's not determined by selector. It's determined by the element in the DOM. So the one is a DOM out approach to encapsulation and this is not really encapsulation. It's more like just limiting selectors in a bit more of a specific way. So you can say find a scope that goes from this outer selector, it's called. It's a class of outer scope. And take anything inside of if you find an outer scope class, an element that matches that, take all of its descendants until you find these other selectors that are lower boundaries and only match within that donut. So it's a donut because it's all of the descendants until something, so you can have a content class inside of it. So you say from outer scope to content, only match within that and we're not matching anything inside of the content. We're just matching between the two. And then we can have a third selector. I mean, it's a little funny. It takes three selectors to do this. You say what is the outer range of the scope, what is the inner boundary of the scope, and then within that, what things do I want to select? So it's a way of defining ownership. I think this is something people have used conventions like BEM, block element modifier, to do this in the past to say, 'I don't just want to select title. I want to select the post title.' And that's not exactly the same as every title in a post. It might be that I have comment titles that are in a post or something. They don't belong to the post. They're just inside of it. And so donut scope allows us to do that, to say things that actually belong to this component and not to things that I've put inside of this component. Did I explain that in a way that makes sense?
Eric Meyer: Yeah, and also now I want donuts.
Brian Kardell: I was going to say can we splice in a Homer Simpson going, 'Mm, donuts.'
Eric Meyer: Mm, Donuts. Probably.
Brian Kardell: Yeah, you had me at donut.
Eric Meyer: Yeah, big time.
Miriam Suzanne: Yeah, great. It's interesting to me that after that initial email that you mentioned, pointing out how many different types of encapsulation there are. That even after that, the group resolved that we should have only one.
Brian Kardell: There can be only one.
Miriam Suzanne: That seems like a weird choice to me. If there are multiple different types of encapsulation we want to talk about, shouldn't we have different approaches to the different types of encapsulation?
Brian Kardell: So the answer is yes, but I think the fact that we didn't, it's just due to the fact that if you make it too complicated we'll never get it done. But I do have some regrets that we didn't find a way to talk about this cooperation more. So Tab had brought to the CSS working group one day, 'Okay, so we have these open Shadow roots and you can't cross the boundary, but you can.' You can walk across the boundary. You can say get the element and then say it's .shadowroot and then you have the subtree and you can do whatever you want in there. And so why not have a selector for that? It's a different connector, but doesn't mean CSS couldn't understand it. And then you could have the sort of like, 'Hey, I know what I'm doing.' And then that becomes like you said, Mia, which is like, 'Sorry, you cut the little tag off the mattress, so the warranty is void.' And that passed without any controversy. It was like of course you need that. Of course you should have that. And they went by a number of names, but basically they were just Shadow root combinator and there was a deep combinator, too. Do you want to cross every Shadow root or just the nearest one? And that year at W3C TPAC, there was a web components breakout and they said, 'Yeah, we shouldn't do that.' And even the people that we gave it to, they were like, 'Once we had it, we were like we have no feet left. We have foot gunned our feet away. We have regrets ever asking for this. We're not going to use it ever.' So yeah, I mean, that was the extent of the cooperation, but I do think that this is tricky, though, because if you think about programming languages, you have private. It's like nobody can use this, but me. And you have public, which is like anybody can use this, but you also have something friendly or protected or something that's like if I want to let you access it, you can kind of access it, too. And it's up to you to invent something like that. So without inventing a way to share secrets or whatever, they can't.
Miriam Suzanne: Right. I mean, this is why I keep thinking of it as a cascade issue. I mean when we're talking specifically about styles because this is what the cascade is designed for. It's designed for collaboration across different needs and desires. So it starts with origins. The browser provides some base styles that make a thing readable and then user preferences can update those defaults. Again, sort of globally potentially or maybe you could try to target a specific site. And then author styles sort of by default override everybody, unless people have used bang important. And then they take the power back and the browser styles, if you look at the browser styles, you can see they do use bang important several places. It's a way of saying you're not allowed to change this thing. And in user preferences you can do the same thing. You can just change your default font size, but you can also say, 'Enforce this.' And depending on the browser, it will enforce it. And it's the same as putting bang important on it. CSS is designed around this idea of collaboration. So when I look at this problem, I think, 'We're in a similar situation.' And there's a little bit of it built in where the by default shadow styles go first. They act like browser defaults, basically. And then if you can access the same components or the same elements, if you can style the same elements from the outside, which is true on the host element and sometimes true on parts that have been exposed, then the page wins, unless things are marked as important. And when things are marked as important, the component wins again. So again, there's been some attempt to do this from that perspective, but now I think the question is could we open it up more? And if we do, how do we allow you to style more things and collaborate even more on the layering between them?
Brian Kardell: No, you're right that it is about how would we open it up, assuming that we want to open it up? Maybe even before we say whether we should open it up, like the donut styles thing, it doesn't address all those use cases either. You would agree, right?
Miriam Suzanne: Right.
Brian Kardell: You can't make composite things with that. It doesn't affect JavaScript.
Miriam Suzanne: No. It's very specifically just it's a selector utility. It's helping you select more exactly what you're trying to select and that's all it is. It doesn't keep other things from getting in, it doesn't keep inheritance from getting out. There's sort of nothing besides all it does is let you select exactly what you want to select in a more specific way that we weren't able to describe before. It's a selector.
Brian Kardell: I think they were really handy for those many, many. I mean, I think it's an incredible amount of times when you could just use the Light DOM approach because it's you or it's you and your coworkers and it's like the use cases are fairly straightforward. I think that would be great for a lot of those, where they just want to say there's no Shadow DOM involved here. We just need to manage the complexity and select these things in an intelligible way.
Miriam Suzanne: And it does have a utility for that. Instead of giving it an explicit scope root, you can put it inside of a style element inside of the DOM. And then it uses the parent of that style element as the scope root. So that's a little bit like Shadow DOM styles without being Shadow DOM styles. It just assumes that the host is the root and you're styling things inside of it. So it does have that ability as well.
Brian Kardell: That's kind of what the old model was, right, if I recall?
Miriam Suzanne: Yeah.
Brian Kardell: The old model was just sort of that and not any of the other stuff?
Miriam Suzanne: Right. I think that's right.
Brian Kardell: Yeah, okay. So now assume that we want to open it up and say, 'Okay, lots of people seem to be asking for something.' Not all the same thing. And also how do we balance it so that we try to make it unlikely that we implement a thing and we give it to a bunch of people and then they have buyer's remorse, like the people who we gave the other thing to. Because once you let that genie out of the bottle on the web, well... You know. It also seemed to me that you can make all these dreams more or less possible with some JavaScript because, like I said, you're the page author. You can override prototypes and stuff. You can say when you attach a shadow root, I would like you to cooperate with the page and coordinate your style sheet situation. So now the question is, okay, but now what does it do? And so I made this little library and it had four different modes. Eric really helped me come up with some kind of names for these because everything is so complicated a name unless you're Mia because Mia names everything ...
Miriam Suzanne: Bruce?
Brian Kardell: Bruce, yeah.
Miriam Suzanne: Yeah, I think you can just call things Bruce.
Brian Kardell: Yes, all things are just called Bruce.
Eric Meyer: That makes sense.
Brian Kardell: Yeah.
Miriam Suzanne: Yeah, simplifies.
Brian Kardell: It does. It simplifies a lot of things. And it's really clear because it's easy to spell. It's short, right?
Miriam Suzanne: Yeah.
Brian Kardell: So one mode is actually there already existed a library from Nolan Lawson who's at Salesforce now and it's been out there for a year or so. And the solution is when you say MyClass extends HTMLElement, instead of saying that, you say it extends OpenStyleable element. So that the proposal would be to add a new class that you could extend. And if you extend that class, that's your way of signaling as a component author I would like to pull down all the page styles. Is that clear or did you get the ...
Miriam Suzanne: Yeah.
Eric Meyer: Yeah.
Brian Kardell: I had developed a similar solution to that before I came to Igalia. And the only kind of tweak was that I didn't want to pull down all of the styles. I wanted to say specifically from the outer page these are the styles that can be pulled down. So we call this component pull mode and component pull marked mode. So marked would just get the ones that you marked with a special attribute. And after a little while, I thought that is challenging because you can get your custom elements from anywhere. Mia was saying bootstrap. Surely there will be libraries of custom elements or one-offs. Dave Rupert has the awesome standalones. Have you seen that?
Miriam Suzanne: Mm-hmm.
Brian Kardell: Maybe there's another custom element somewhere else that you pick up. And the trouble is that they're not going to probably agree on the classes. So as a page author, it's really limiting if I want to try that. So I came up with this alternative model that goes the other way, where the page just finds all the shadow roots and says, 'Sorry, you weren't designed for this, but I'm going to push this down anyway.' And that just also has two variants. That was page push that'd push everything and page push marked that would just push the styles that have an extra attribute that say this one. And I published that and then Mia opened an issue on that and Mia said, 'Thanks, but no thanks,' and came up with another one. And can you describe the other one? Do you even remember? Because moved on from it.
Miriam Suzanne: Yeah, I've moved on from it as well. So I don't quite remember what it was. It was some combination of things, right? It was ...
Brian Kardell: Oh, right... It was 'I want to be able to say on the individual element as the author. I want to be able to say I want to add an attribute that says ...''
Miriam Suzanne: Right, I'm willing to accept.
Brian Kardell: Yeah, but not as the component author, as the page author.
Miriam Suzanne: Right. Yeah.
Brian Kardell: Yeah, so wow. And then that has the same two variants, so now we're up to six possible modes. And then so I published that and about that time Chris Coyer published a thing and said, 'But can't I just use CSS?' And Dave Rupert published a thing that was kind of a feedback and he said, 'Can't I just use CSS?' And when I was making these, I also ran into the case where I wanted to make a code pen and Mia and I brainstormed a whole bunch and could not come up with a way, even with Chris Coyer himself, to create a CodePen for the old way because it relied on you adding attributes to the HTML element and you can't do that in CodePen. So very quickly ran into limits and frustrations with that myself and we came up with this hack that ... How would you describe this, Mia?
Miriam Suzanne: Well, it uses media queries or the idea of custom media queries, but instead of really querying anything, you're almost doing a container query, really. But you use app media and I think we're just grabbing that because it works. The proposal isn't ... This is the right syntax, but we probably need some sort of at rule to wrap things. And app media is one that we have and we can say app media across the Light DOM and the Shadow DOM apply these styles or app media just in the Shadow DOM of these elements or just in the Light DOM. And we can sort of use media queries to say we're only targeting some or all of those different locations with these styles.
Brian Kardell: Yeah, I think that's a probably good parallel, but we're just using the at media because the parser doesn't throw it away. If you don't know, the CSS OM, there's a lot you can put in CSS that just won't appear in the CSS OM. Which means that if you want to use something like that that gets thrown away by the parser, you have to fetch the thing again, which will have problems with cross origin issues. You have to get at the text and you have to parse CSS. You have to reparse CSS. So we're just sort of subverting, we're using the fact that media queries are very flexible and don't throw much away. If you stay within some very basic rules, it'll work. And then you can just use the CSS OM. So it lets us keep the size of the library to it's literally 100 lines, I think. It's not even 100 lines.
Miriam Suzanne: Yeah, it's a really interesting solution. And the thing that I keep coming back to is it maybe needs a coordination layer as well or there's some way that this relates to layering.
Brian Kardell: I agree.
Miriam Suzanne: And this solution doesn't get to that. So how do I say as a component author, here are the layers that I'm providing and here's how you can slot in below, above, or between them? And I can decide not to provide layers you can go between or maybe I don't even let you go above or below. I only let you go to one of those, but is there some way as a component author I can say here are the layers internally and here's how you're allowed to interact with them? And then is there some way as a page author that I can say I want to provide some defaults? I want my reset to come before. I want it to apply to these components before the component styles. And I also have some things I want to do to override component styles, so I want to slot those in at different layers. How do you coordinate that between the component author and the page author?
Brian Kardell: That's a great question. I have no ideas. If you or anybody has ideas, please submit them.
Eric Meyer: Yeah, I mean, these are all really hard questions. We're grappling with it here just in this conversation and these questions of when can things be overridden and by whom and in what ways? And it's really challenging in the context of the web.
Brian Kardell: Yeah, because the answer is very much it depends, right?
Eric Meyer: The answer to all web questions is it depends. But yes, once again, it depends.
Miriam Suzanne: But that's why we provide things like the cascade that give us hooks into those decisions. The reason importance exists is so that we can decide that while generally the author of the page gets priority, in the final word they don't because other people can mark things as important and take back that control. So is there a way that we can do that again? Provide some hook into an algorithm that says by default we think it should go this way, but we're giving you an option to change it around.
Brian Kardell: Yeah, more ideas and feedback. I am really, really keen on not lingering too long on the speculation and theory and giving people something, even if it's not the thing. It's kind of close enough to the thing that you can evaluate whether that idea is useful. Do you know what I mean?
Miriam Suzanne: Yeah, for sure.
Brian Kardell: So I feel like I provided four that I could think of. Very quickly we got this other feedback and then very quickly we got this other feedback. And I feel like sort of night of day to me, I don't think there's any competition. I like the most recent thing better and I don't think that's likely to happen unless we can give people stuff and say, 'Here's a CodePen, go play with it.' But now I think also we need help evaluating it. And I don't know. How do you think we get developers more engaged in that kind of thing? Because I have this idea on this one to share a single GitHub issue and say, 'Leave an emoji.' How do you feel about this? If you want to put other comments, you can do that. If you want to open other issues, you can do that, but just give me an idea of your sentiment of this. What do you think is a good way to increase engagement with developers in terms of ...
Miriam Suzanne: Yeah, I mean, I think we run into this all the time with standards. I mean, it seems hard to me because with anything like this, we've got people who are fine with it the way it is and use it quite a bit. So would be ideal testers, but they don't need something new. It works. And we've got people who aren't using the thing because it doesn't work the way that they want. And so they maybe don't even know exactly what to test because they haven't played with it. And then there's people who are sort of playing with it, but if it's not my day job, if nobody's paying me to go try the new thing, when am I supposed to do that? On who's budget?
Brian Kardell: Yeah, that's huge, right?
Miriam Suzanne: Yeah.
Brian Kardell: I mean, we can get maybe some. Here's a CodePen and just spend five, 10 minutes with it sometime when you have five, 10 minutes. But that's a whole different thing than the kind of real feedback that would ultimately be the most helpful, which is like, 'Go try this at your project at work.' And trick is not everybody has this use case or this need or this situation right now.
Miriam Suzanne: Right. And there are still several different use cases and needs floating around, like you mentioned at the beginning. Definitely I've found that sometimes talking about it on social media, we're just talking about different use cases. Different people disagreeing with each other not because one idea actually solves the problem and the other doesn't, but because they're solving different problems.
Brian Kardell: Yeah. What's the law, the best way to get the right answer on the internet?
Eric Meyer: It's Cunningin's Law.
Brian Kardell: Yeah.
Eric Meyer: Best way to get the right answer to a question is to post the incorrect answer. So sort of the classic one is you post a picture of a duck and say, 'This is a really attractive goose.' And then you'll have six people telling you that is a female mallard duck.
Brian Kardell: Right.
Eric Meyer: Thank you.
Brian Kardell: So I don't know. I guess we're not going to solve this here or probably, but ...
Eric Meyer: Also I should say that I just misspoke. It's actually Cunningham's Law and I almost left it in to get a bunch of people to reply, but ...
Brian Kardell: I think you should just leave it in just to see who replies.
Eric Meyer: We could do that.
Brian Kardell: It's full of interesting problems and I hope that we can continue to work on them together. Mia, if you have ideas for the later stuff, I'm definitely all ears for that. I just have no idea how we can do that effectively. It's a good question, actually. Do you know the answer about ... You should know the answer I guess because you invented it sort of. But if you have a Shadow root, are layers global or are they ...
Miriam Suzanne: No, layers are contained to the Shadow root. So I mean, I think one approach here ...
Brian Kardell: So named layers I mean specifically.
Miriam Suzanne: Right. Layer names are scoped to the Shadow root, so they don't cross the boundary. So there's no potential for accidental conflicts there. So then the question is can we provide a way to have intentional crossover between layers? I think that might be interesting and I haven't thought through exactly what a syntax for that would look like or ... I mean, I think this goes back to the thing I was saying before of we designed layers so that they would clearly work for the bootstrap case. Bootstrap can provide layers and you can consume those layers and interact with them in ways that Bootstrap has exposed. So the one tool can decide to expose some layers and then the page author can decide to interact with them or not. And the question here would be who's exposing which layers? Is it that the page exposes some layers that the component author can pull in? I mean, this is sort of the component pull versus page push in your first model. Is it the page provides some things and the component author is allowed to pull them in or is it like the component provides an interface for layers where you're allowed to push into? I'm not sure. I haven't dug into all of that, but I think that's the question that is bugging me right now.
Eric Meyer: Yeah.
Brian Kardell: Me, too.
Eric Meyer: With that note, thank you, Miriam, for coming online. Where can people find you on the inter tubes?
Miriam Suzanne: They can find me on Macedon, Mia at Front End Social, or they can go to the OddBird website. OddBird is the web agency that I co-founded. We do a lot of work in various areas of the web, so oddbird.net.
Eric Meyer: Cool. And I assume you are open for new clients?
Miriam Suzanne: We are open for new clients and we do all sorts of things from refactors to custom built applications.
Eric Meyer: Nice. Very cool. All right, so thank you so much and hopefully after some period of time we'll be able to do this again with an update on what has been learned and figured out.
Miriam Suzanne: Yeah. Hopefully you'll figure it out and let us know.
Eric Meyer: Yeah, right, right, right, right. Thanks, Miriam.
Eric Meyer
Brian Kardell
Miriam Suzanne