Brian Kardell: I'm Brian Kardell, I'm developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also developer advocate at Igalia.
Brian Kardell: And so we've had lots of different kinds of shows. But this time, we're talking that we see a lot of buzz on the Twitters, and in blog posts, and on podcasts that we listen to. Seems a lot of people are really excited by, 'Holy cow, wow! There's so much stuff happening in,' especially in CSS. But it's just really, really exciting. Like what happened to ignite this fire? Eric, you've you've seen this, yeah?
Eric Meyer: Yeah. Oh, yeah. Seems like at least once a week, and frequently, more frequently than that people, you'll see people on Twitter or in the RSS feeds, saying, 'Holy crap!' Like you said, 'This thing that was impossible for so long is suddenly easy to do,' or, 'Oh, this thing that I heard about a couple years ago that seemed like it would be really cool in some unspecified future when it was implemented is now already implemented.' For that matter, 'Hey, there's stuff that we've been wanting for a quarter century, and suddenly, it's here,' all that kind of stuff. It's been characterized, somebody referred to it as the Cambrian explosion of web standards. And I don't know who came up with that, but I've seen that floating around. It's just there's so much happening so quickly.
Brian Kardell: Yeah, definitely. Maybe you could list some examples, and I can maybe fill in a couple more based on what I hear you say of things that are maybe in the past a year or two and looking pretty good sense of landing in the next year or two?
Eric Meyer: Yeah. So there's container queries that have been mooted about for years now, suddenly look like they're going to be implemented like this year, like widely implemented this year. Cascade layers, which has been the sort of thing that people have been interested in for a long time. You know? This ability to group par parts of your style sheets together and have them be able to override anything else, no matter what the has. People have wanted a parent selector since basically there have been selectors, and certainly since there was the child selector, and that was 1998 when the child selector was basically formally introduced.
Brian Kardell: Amazing, right? Like that was in specs in 1998 and 1999.
Eric Meyer: Yeah.
Brian Kardell: That we basically were like it seems so obvious. Like you need that, right?
Eric Meyer: And the reason why it's taken this long. I mean, there are a lot of reasons it's taken this long, but the primary reason was performance concerns and work that's been done recently by Byungwoo Lee here at Igalia and Antía Kosovo, is it-
Brian Kardell: Mm-hmm.
Eric Meyer: ... at Apple? They've figured out some really interesting ways of minimizing the performance hit that ancestor selectors will create. And that's the thing, like there was a child selector. And so people said, 'Well, can we have a parent selector?' And the answer for a long time was, 'No, that would grind browsers to a halt.' And that was probably true at the time. I mean, that was 20 years ago, right? Browsers were not as fast as they are now. But the has pseudo-class is not just a parent selector, it's an arbitrary ancestor-level selector.
Brian Kardell: Yeah. It was originally in specs as subject, because in CSS terms, you write a rule, and the properties and values of the rule are applied to the subject. And thus far in the history of CSS, always the right-most thing in the selector, that's the subject.
Eric Meyer: Right.
Brian Kardell: And it's very carefully designed that way for performance reasons. But we should also probably note for somebody who's maybe listening that early on in CSS, just that actually had a lot of performance concerns. You remember way back we would talk about like, 'Well, that is not really very performant, or you have to keep an eye on how many rules you have,' because it was not really very practical. So we've spent the last 20 years more or less making that super efficient because of that particular construct. So when changes happen, they basically walk up the tree to the root because there's always a very short path from anywhere in the tree to the root.
Eric Meyer: Uh-huh.
Brian Kardell: And they check backwards, so they eliminate things really quickly. And we've added things like bloom filters and all kinds of really interesting ways to shortcut out of that as quickly as possible, because then the fastest work is the work you don't actually have to do.
Eric Meyer: Yeah.
Brian Kardell: So yeah, that's really interesting. And the problem with that has always been that the ask to invert that opens a new problem for which nobody has ever really provided a proven workable solution. And the ones that we had didn't seem like they were going to work.
Eric Meyer: Mm-hmm.
Brian Kardell: And this creates a problem, because you wind up with this blockage where you're asking for vendors to invest in research that may or may not lead anywhere.
Eric Meyer: Right.
Brian Kardell: Right? So we don't even know the scale or scope of the problem. We just we know enough about what we do and what the pains we had.
Eric Meyer: Mm-hmm.
Brian Kardell: And we know that changing that would be really, really hard at 60 frames per second.And so yeah, that's held that out for a really long time. And since you already have breached into this, the thing that got us out of that is some new investment from none of the browsers, actually, is from Eyeo, the company that makes the-
Eric Meyer: And to be clear, that's E-Y-E-O for Eyeo.
Brian Kardell: Yes. And they said, 'While this is a nice to have, it's always been a really nice to have on the web,' I would argue more than nice to have because the separation of concerns requires powerful features, right?
Eric Meyer: Mm, okay. Yeah.
Brian Kardell: That's what I think, right? I think that all of the workarounds and solutions to this have been like, 'Use some JavaScript and place the new class in there,' or something.
Eric Meyer: Right.
Brian Kardell: But the promise of CSS, we can only really live up to the promise of it if you can write your mark up and your styles separately. You know?
Eric Meyer: Right.
Brian Kardell: And without subject, it's actually really hard to live up to that a hundred percent.
Eric Meyer: Yeah. There are many problems in styling that you can't do them without some form of, well, I need to market thing up here, or I need to know that this thing is inside this other thing so I can style this other thing. I need to know that this... One of the simplest ones is if I want to remove the link underline from any link that has an image inside of it, I need to have a way to mark all the links that have images inside of them. And you could do that with literally typing class= into your HTML, or you could have JavaScript do it, which is how a lot of people have done it. With has, you can just do it straight in the CSS. You don't need extra script overhead. You don't need manual maintenance of the HTML, all that sort of thing. You could just say a:has(img) [inaudible] and you're styling the a instead of the img.To be clear, that's the most reduced version of this class of problems. There are plenty more. You know? I want to be able to style this product card based on whether or not there's a price in it, right? Until now, the only way you could do that was to have your CMS or your whatever do the work on the back end to say, 'Okay, is there a price in here? Okay, if there's a price, then we're going to add a class to this card that says has(price), and then we can style it based on that.' But now you don't need to do that sort of thing anymore.
Brian Kardell: Yeah. There's any number of cases you can come up with. I mean, there's-
Eric Meyer: Yeah.
Brian Kardell: ... literally just hundreds that I've had over the course of my career that I've been like, 'Ugh, [inaudible].' Well, I have to come up with some clever backend or build time thing that analyzes the data and injects some new context pushing up mechanism to do this kind of thing, and that's always been painful.And since we already have begun touching on this a little bit, first, big thanks to Eyeo.
Eric Meyer: Yep.
Brian Kardell: And they sponsored the research, which is amazing, because they did the thing that browsers wouldn't do.
Eric Meyer: Right.
Brian Kardell: But then once we unblock the nuclear standoff, suddenly Safari said, 'Oh, yeah. No. Hey, look, we can do that.' And in fact, they shipped it before our Chrome implementation. And that's amazing. Like I think this, this blockage thing comes up a lot.You already mentioned container queries, and it is similar there. Like it was all performance concerns, and complexity, and circularity, and things like that. And here, too, Igalia invested almost a year in different efforts behind the scenes, and talking to different people trying to get this unblocked. We had a proposal ready to go, and we shopped it around, and everybody supported it, thought it was a good idea, were like, 'Let's do it.'
Eric Meyer: Right.
Brian Kardell: Except for David Baron. David Baron said, 'Eh, I have this other idea, and I need some time to write it up.' But we were a forcing function then, right? Like we had the pressure to like, 'Well, it's sort of now or never. You know?' And so David did write that up, and it was actually really, really amazing and interesting, and that is what we ended up doing instead.But Igalia actually, the same week that Google announced they were going to pick up David's proposal, we show it. Like we had a running demo that we showed them on Twitter, like I think it was like the day before or something like that.But yeah, this is really interesting. We spent a bunch of time on those two things, but can you name some other ones?
Eric Meyer: CSS color space support, like color spaces beyond RGB, or SRGB, or the stuff that we're used to. And I don't just mean color notation, right? So there's things like HWB, HSL, okay lab, lab and okay lab, yeah, are a couple of color notations, like color value formats, some of which can go outside the RGB space. But browsers historically have been confined to the RGB space. Like you could define any color format you wanted that went outside the RGB space, browsers would just clip you off at the edges of the RGB color space. While there's stuff like Display-P3, which WebKit supports now, I think there's another one that I've just blanked on. But other browsers are looking to add the color spaces.There's smaller stuff, like in the CSS realm anyway, like gap, the property gap used to be grid gap. And as soon as grids had gaps, pretty much every other layout system or proponents thereof said, 'Why can't we have that for Flexbox, or multi-column, or whatever?' And so it's making its way out. You can have gaps in Flexbox now just by saying, 'Gap.'
Brian Kardell: Yes. Such just small seeming thing, but like big, big impact, and really exciting.
Eric Meyer: Yeah. Right. Because I mean, I've been to entire conference talks in the past about, 'Okay, so you've got your Flexbox layout, and you want your Flexbox items to be distributed, but they should never get any closer than this amount, but they should also not be skewed to one side, so you can't use side margins. Here are these hacks that we've come up with. Sometimes [inaudible]-'
Brian Kardell: And they have to be responsive, too, right?
Eric Meyer: Right. And sometimes hacks involve JavaScript, sometimes they don't, sometimes it's really clever usage of stuff, right, because there was no gap support Flexbox at those times, and those talks were absolutely needed at those moments. But now, all that stuff, we could just pretty much start getting rid of, because we could just say, in our Flex, 'Display flex,' and then, 'Gap 10 pixels, or 1M,' or whatever.
Brian Kardell: I mean, it just makes so much sense. I mean, remember back when all we had was float layouts, right? And it was like oh, man. What I-
Eric Meyer: I remember before float layouts, man.
Brian Kardell: What I would have given for just what I want is some space between these two things. You know?
Eric Meyer: Right.
Brian Kardell: Like such a huge, huge win.
Eric Meyer: And robust space, right? You could separate floats by setting the right margin, but that only worked as long as the layout never changed, or the writing directionality didn't change. You know?
Brian Kardell: Or like what if you have, like sometimes, an element is optional, and like-
Eric Meyer: Right.
Brian Kardell: ... where do you attach the things? And the interfaces are changing and evolving all the time.
Eric Meyer: Yep.
Brian Kardell: This is the source of a lot of churn for a lot of projects that I worked on. It was like just we need space between these two things. You know? And just getting that right and keeping it right was actually way harder than I think it should have been.
Eric Meyer: All floatists space or gif.
Brian Kardell: Yeah. I think also we got classes in JavaScript, and not just classes, but increasingly robust ones with private class fields, and methods, and things like that.
Eric Meyer: Yeah. The fact that now in JavaScript, you can really do strong encapsulation. Again, like I have seen talks, conference talks about how you could, like best practices for simulating encapsulation in JavaScript, right? Because there was no such thing as private classes and fields. And now there are private classes and fields, which are completely encapsulated natively. You know? If you define a private field inside of a function, it does not escape outside that function, stuff like that.
Brian Kardell: Yeah.
Eric Meyer: Yeah. Also, I was going to mention on the CSS realm, there's the dialog element and the backdrop pseudo-element. It's a pseudo-element, right? Pseudo-class, pseudo-element, I think it's a pseudo-element. Yeah, the ability to not only pop-up a dialog, but also to be able to say, 'Here's the backdrop I want for this modal dialog that has appeared.' So by backdrop, in this case, generally, that means, oh, that's a little bit of a dark pattern or at least an unwelcome pattern. But you know? You go to a website, and you're halfway through the article, and it pops up a thing that says, 'Subscribe now!' And the rest of the page sort of washes out or grays out or something. That's that wash out or gray out is the backdrop, and I guess those things will be more performant, which is a win? I would like to see them be less persistent, less prevalent. But yeah, I know, people-
Brian Kardell: It will be really, really interesting to see how this shakes out. Like we could probably do a whole entire show on that. But it's questionable to me. Could you override show dialog in some clever ways, and you have an ad blocker. You know?
Eric Meyer: Well, now that we have has support thanks to Eyeo, we could do a any element that has a dialog element, set it to display none or something.
Brian Kardell: So a dialog is actually really interesting. It's full of new features. It introduces the, really, top layer-
Eric Meyer: Mm-hmm.
Brian Kardell: ... introduced the concept of top layer. And also, that thing you were talking about, about what does it mean when something's on the top layer? That's largely about rendering. But then if you look at the HTML spec, it also says that the things in there become inert.
Eric Meyer: Mm-hmm.
Brian Kardell: It uses this term inert.
Eric Meyer: Yeah.
Brian Kardell: So dialog was stuck for a really long time on, actually, disagreements largely around accessibility, which is interesting because a lot of people want it for accessibility, right? They want to say like, 'This is an accessible dialog.'
Eric Meyer: Mm.
Brian Kardell: But there were some disagreements around how some of those things should actually work.So inert is a thing that was described by the HTML spec, and it turns out that is a really useful concept all on its own, and it didn't exist yet. So Alice Boxall, previously at the time at Google, and I worked on that.
Eric Meyer: Mm-hmm.
Brian Kardell: And she did the implementation in Chrome. And after a couple of years, there was an implementation done by Emilio in Firefox. It was a little bit different, but it sorted out, we had a poly fill that was used by Twitter, and Slack, and I think a bunch of places if I'm recalling correctly. We had a couple of projects going on, but I think inert was one of those ones that was used on a bunch of them.We did it as part of open prioritization, we offered inert, and it got really, really popular. A segment of people were really excited about it for dialogs. But a segment of people were also excited about it because you could use it for more than just a mobile dialog.
Eric Meyer: Like what?
Brian Kardell: Like for example, potentially drawers. Interface components are complicated. I just wrote a blog post on this, actually. They cross-influence each other, and we come up with new paradigms. And there is this concept of a drawer, and then there are lots of things that are like drawers, and the lines between them get sometimes blurry and vague. But there are some drawer constructs that are effectively like a dialog, but they're not presented as a dialog, but you do want to trap the focus in there and have it be on the top layer, more or less.So inert would let you do that. It's a way of saying all the stuff in here is just forget visibility. It's not necessarily connected with visibility. We may choose to just gray it out. But it shouldn't be selectable, like it should be as if it didn't really exist. It's just like a ghost of its real existence.
Eric Meyer: So an inert element is one that you can't really interact. You may be able to see it, but you can't interact with it.
Brian Kardell: Right. And to accessibility, it's like as if it's not there.
Eric Meyer: It wasn't there at all.
Brian Kardell: Right. Yep.
Eric Meyer: So that takes it out of the accessibility tree.
Brian Kardell: It takes it out the accessibility tree. It takes it out of sequential focus order.
Eric Meyer: Mm.
Brian Kardell: Like a whole bunch of stuff. There's a lot of things that it juggles.So the fact that that got, that didn't win, actually, but it came a really close second. Like it looked for a minute like that one would win. And I think that the combination of it having two implementations and there being a lot of excitement around it really helped push Apple to go, 'I mean, we should get this across the finish line, along with dialog.' And so we did that, and that's awesome.
Eric Meyer: That was just shipped just within the last few weeks, wasn't it?
Brian Kardell: Mm-hmm, yeah.
Eric Meyer: For the benefit of those who may be listening in the future, we're recording this right at the very beginning of May 2022, so would've been within the March, April timeframe of 2022.
Brian Kardell: I believe it is still behind a flag in technology preview, but I could be wrong about that. But it's really close, that's just the way that the process works. Even when a thing receives no changes from then until it ships, you have to go through technology preview.
Eric Meyer: Right. And I mean, like you said, it nearly won open prioritization. It actually lost out to focus-visible and WebKit-
Brian Kardell: Yes.
Eric Meyer: ... and getting that implemented, which Igalia did.
Brian Kardell: Which I also worked on with Alice Boxall, both of those were our proposals. Yeah, so we did the final implementation of that, as well, and that is amazing. Like there's a lot of happiness around that, I think.
Eric Meyer: Yeah.
Brian Kardell: But also, there's like all different kinds of stuff that's super relevant. There's internationalization stuff. JavaScript, in particular, is getting-
Eric Meyer: Mm-hmm.
Brian Kardell: ... all kinds of really good internationalization stuff baked right into it.
Eric Meyer: The ability to do internationalized date formatting, number formatting. To be clear, to be able to take a point in time that's, let's say it's represented as a UNIX time, number of seconds from the epic or whatever, and render that in an internationalized way. You know? In you Japan, it's rendered one way, in America, it's rendered a different way, in Europe, it's rendered yet a third way, et cetera. And a thing that we've been working on, there are two ways to pronounce it, either temporal or temporal. I usually say temporal, but whatever. Basically, taking the Moment.js library and making that native to JavaScript with a whole lot of extra stuff that MomentJS never actually had. Which, as you might expect, is intertwined with that internationalization stuff, day formatting, and time formatting, and other things like that.And that's starting to appear in browsers. I know that engineers at Igalia have been adding parts of the temporal API to WebKit. At least the technology previews, I don't think they've shipped publicly yet. And it's not all of the API yet.And temporal's been really interesting to me. Anyone who's done JavaScript and had to do date programming has come to curse the date object from what I could tell. The temporal API is much better, but it's also it's not just like one thing. It's actually broken up into sections. And so these various interfaces are being implemented one at a time. The last I checked, we've done about half of them, but it's possible that there have been a couple more that I missed recently.
Brian Kardell: I think that is super interesting, so interesting that we did a whole podcast episode on it. So if you're listening to this, you can go listen to that, and we actually get into it with some of the champions who were actually from the Moment library, the Moment project-
Eric Meyer: Mm-hmm.
Brian Kardell: ... and about why it wound up being not Moment-like. It's actually quite a bit different than Moment in the ways that Eric is saying.
Eric Meyer: Mm.
Brian Kardell: JavaScript is it gained its Java date stuff, it gained its date stuff from Java.
Eric Meyer: Mm.
Brian Kardell: But that was very, very early Java. And even Java was like, 'Oh, yeah. No, that's no good.' And they added a bunch of other stuff that people use instead. But because of the way that the web works, that's just kind of like cooking in time for JavaScript, so there was no way to fix it, and we've just lived with that for all this time, and so it's like what a huge thing. Because Moment is a really good library, it's probably one of the best ones. Or the one that is the spinoff project of that, I can't remember the name of it off the top of my head, is maybe better too.
Eric Meyer: Mm.
Brian Kardell: But it's huge, because this involves doing a lot of stuff and having a lot of knowledge to get this right.
Eric Meyer: Right. So for those who missed the earlier podcast, both Moment and temporal are aware of time zones, they're aware of summer time shifts, like when what locations move to summertime and when for every year. Every time zone in the world, which is way more complicated than it sounds, even for people who have a passing familiarity with time zones, because there are time zones that are like 15 minutes off their adjacent time zones sometimes for example.Anyway.
Brian Kardell: Yeah.
Eric Meyer: And so yeah, with Moment and with temporal you can say, all right, I have this date and time. Right. I'm just I'm going to pick the date and time. I have, 2:47 PM on Monday, May 2nd, 2022, and I want to know how many seconds it is until a date three and a half years in the future in a different time zone for whatever reason. You're doing some kind of a countdown to a party, I don't know, whatever, right? And I want to know how long, for that matter, how many days is it until this particular point in time in a different time zone, different country, whatever. And it will tell you. It'll tell you to the nanosecond what that interval is, and then there are all these methods that let you take that figure and express it in days, or in years, months, and days, or whatever.And you don't even have to match calendaring systems. You can feed it the date and time that I gave in the American format, and you can give the other date and time in the Hebrew calendar, right? And it's just it's all taken care of. You don't have to do any conversion yourself, it all happens at the back end. And that's all got to be built into the browser, right? All of that knowledge either had to be... Well, it had to be built into MomentJS, and it also all has to be built into the browser. It's not, neither of those is a trivial undertaking.
Brian Kardell: Yeah. And like there, if you listen to that podcast, you'll hear a couple of other examples of just phenomenally weird sorts of things in time and events. Like some thing that happened in World War II that briefly for these three days affected a calendar or something like that, and if you really want to do some historical analysis about time-
Eric Meyer: Mm-hmm.
Brian Kardell: ... you need to know that, so-
Eric Meyer: Right.
Brian Kardell: Yeah. All that is very, very complicated to get right, and that, I think, it's really exciting.But then also we have shadow realms is-
Eric Meyer: Yeah, you're going to have to explain this one to me because every time someone explains shadow realms to me, I get confused.
Brian Kardell: Shadow realm, the easy, the high level pitch of shadow realms is that all of the stuff in JavaScript executes in a realm. So a realm is sort of the context, I guess, right?
Eric Meyer: Okay.
Brian Kardell: And you could spin up two different things, and each have their own realm, and the realms have whatever, the information for that little container of stuff that you're running in.
Eric Meyer: Mm-hmm.
Brian Kardell: And each window in different things on the web have their own sand boxing basically, right?
Eric Meyer: Okay. So if I open a YouTube window and then Wikipedia window, each one of those is its own realm, right? There's the YouTube realm is in that window, and the Wikipedia realm is in that window. Is that-
Brian Kardell: Right. Those two instances have different ones, well, that are sand boxed from one another.
Eric Meyer: Right. So you can't have Wikipedia suddenly stop my YouTube or whatever.
Brian Kardell: Well, so the question has always been like, well, we would like something like that for different purposes that don't require iframes, and also have some differences, though. We have a couple of blog posts that are linked that explain this much, much better than I could. But for example, like if you have a iframe, can you walk in and out between them or something by references? Can you get access to the global somehow? And so this is a way that you could, at least in theory, build some... Like this stuff is completely isolated. It doesn't share anything with the outside, and you have to have a way for those to operate together.So this is a really complicated idea, and that's developing, and there's an implementation being worked on in WebKit. I think that's super exciting. It's being done by Salesforce now. Like most people won't probably use this directly-
Eric Meyer: Mm.
Brian Kardell: But that doesn't mean that they won't use it. Like a good, another example is option in Canvas. I gave a talk about this last year. Like most people are like, 'Oh, Canvas. I don't know. Cool, I guess.'
Eric Meyer: Right.
Brian Kardell: Like a lot of people don't use it. You could go a whole career and never program against Canvas, right?
Eric Meyer: Yeah.
Brian Kardell: But you use it every day. Like you literally use it every day.
Eric Meyer: Yeah.
Brian Kardell: Yeah, yeah. Because like maps, for example, all use the Canvas. So even though you, as a developer, don't directly program against the Canvas, like maybe you used a charting library and that used the Canvas, or you used a mapping library and that used the Canvas. Or as a user, you use charts, and maps, and Google Docs, and all kinds of things that are entirely Canvas-based.So yeah, the OffscreenCanvas is really interesting because when the Canvas was introduced, it was Apple actually introduced it.
Eric Meyer: Yep.
Brian Kardell: And it was an image, but with a programmatic drawing interface. And because of when it was introduced, I think there were not even browser tabs back then. Remember those days when you had just the window, the browser window.
Eric Meyer: Oh, I remember. I'm trying to remember. I feel like Canvas was a 2008 [inaudible]-
Brian Kardell: Four, I think.
Eric Meyer: Was it [inaudible]-
Brian Kardell: 2004, I think.
Eric Meyer: ... that far?
Brian Kardell: Yeah.
Eric Meyer: Okay. All right, 2004. Wow.
Brian Kardell: I could be wrong. I could be wrong. You're probably right. The W3C had a big meeting to decide what to do with HTML applications, which were not really supposed to exist. But a group of people said, 'And yet they do, and the state of them is really terrible, and we should do something about that.'
Eric Meyer: Yeah, I just checked. You're right, it was 2004.
Brian Kardell: Yeah. Okay. So this is like literally, literally the beginning. Because the meeting that established HTML5 was also in 2004. That led to the spin out creation of the WhatWig.But yeah, I think that's super interesting. But the historical notion of that, though, is that we didn't have like workers back then.
Eric Meyer: No.
Brian Kardell: Like a lot of our ideas were a lot simpler.
Eric Meyer: Mm.
Brian Kardell: And so basically, there was the main thread, and the Canvas and all those operations are synchronous. And they work on and block the main thread.
Eric Meyer: Right. The same thing that's trying to lay out the rest of the page.
Brian Kardell: Yeah, right. And also the thing that receives user input-
Eric Meyer: Yeah.
Brian Kardell: ... and blocks rendering. So if you have maps, and you want to like pan and zoom around the map, you want to draw things, you don't want to do that blocking the main thread.
Eric Meyer: Right.
Brian Kardell: And this is a really big deal if you're not on a high-end iPhone. If you're on a lower-end piece of hardware, something much lesser, which is what embedded systems are, right?
Eric Meyer: Right.
Brian Kardell: And so interestingly, OffscreenCanvas, which will benefit everybody in their real day-to-day lives-
Eric Meyer: Right.
Brian Kardell: ... every single day was sponsored by Comcast.
Eric Meyer: Right. Because they were using Canvas to run the UI on their set top boxes.
Brian Kardell: Exactly. Right.
Eric Meyer: And they wanted it to be less clunky, more performing.
Brian Kardell: Yeah.
Eric Meyer: Right. So right, because of that, they hired us to make that happen. And so the payoff there is that I know everyone's had that experience of trying to move really quickly across a map, and chunks just aren't loading because, or the whole thing slows down. OffscreenCanvas goes a long way towards fixing that. It makes it way more performant.
Brian Kardell: Definitely. You probably have seen that, like in an airplane or something like that, if you have somewhere where there's a map that you can point and drag around.
Eric Meyer: Mm-hmm.
Brian Kardell: So obviously, those things in your airplane are, they're not as capable as your iPhone, right? Like hardware-wise, they don't spend that kind of money on each.
Eric Meyer: Yeah. No, that's another class of embedded devices that would definitely benefit from something like OffscreenCanvas.And for that matter, I mean, Offscreen canvas is a great optimization. There's also been recently hardware acceleration of SVG-
Brian Kardell: Yes!
Eric Meyer: ... which tons of people, I'm sure lots of people listening to this would say, 'I never use SVG anyway, or what I do, it's just a little icon. What do I care about hardware color for SVG?'
Brian Kardell: But you do.
Eric Meyer: But right. Because...
Brian Kardell: No. Because, I mean, so many other things. It's very similar. Like there are plenty of people who do SVG, like they do a lot of SVG work.
Eric Meyer: Mm-hmm.
Brian Kardell: But also, a lot of us use libraries and other components that do use SVG, like use a lot of it.
Eric Meyer: Yeah. GreenSock comes to mind immediately.
Brian Kardell: So you're abstracted away from it. You don't even realize that the underlying stack is actually SVG, or Canvas, or whatever, right?
Eric Meyer: Right.
Brian Kardell: But yeah, like DataVis and all kinds of things.
Eric Meyer: And honestly, I would love to see more maps be SVG rather than-
Brian Kardell: Yeah. There are some experiments around that.
Eric Meyer: Yep.
Brian Kardell: It's like actually very complicated to do.
Eric Meyer: I'll bet.
Brian Kardell: And it is a lot different than a lot of what is done with maps today. But I agree it would be really, really interesting.But yeah, SVG, that was blocked for the longest of times. And there was a lot of discussion about like, 'Well, somebody should do something about that someday.' There were plans to do things. But this was a really hard problem because the SVG engine was one of those things that didn't change. Like you went WebKit to Blink, and it pretty much stayed the same. You know? Had the same architecture and everything.But that actually came from the '90s, and it was done by two guys who now work at Igalia, the original SVG engine. And that was done before CSS existed and got a bunch of investment. And so even though it contains similar concepts and there's a lot of alignment between them, they're just completely different engines. And so how do you solve all the problems? Well, probably, you need to begin by like aligning those and redoing the implementation of SVG. Which is like, oh, my God, the whole thing.So we did that. We said we were doing that, and here, too, suddenly, that really lit a fire. That was sponsored by Vorwerk, the company who makes the Thermomix cooking machine.
Eric Meyer: Right.
Brian Kardell: Because they have a WebKit touch screen in their... I don't know, actually, if it is a touch screen. But they have a WebKit display.
Eric Meyer: Yeah. Mm-hmm.
Brian Kardell: And they needed to hardware accelerate their SVG work, because SVGs and Canvases are really important on embedded devices.
Eric Meyer: Yeah.
Brian Kardell: They tend to look a lot less like HTML and a lot more like physical controls and stuff like that.
Eric Meyer: Mm.
Brian Kardell: A lot more visual.
Eric Meyer: And yeah, it's interesting that Vorwerk interest in getting SVG to be better is a very close parallel to Comcast wanting Canvas to be better.
Brian Kardell: Absolutely.
Eric Meyer: And I could easily see where, because of the work that was done for one of those companies, the other company might say, 'Oh, we could use more of that.' Like Comcast might decide that they wanted, if SVG is hardware accelerated, now they might decide that they want to do more of that and less Canvas.
Brian Kardell: Yeah.
Eric Meyer: Vorwerk might decide, 'Ooh, yeah. Hey, Canvas is much better. We could make use of that for these things.' Not necessarily a complete switch over, right?
Brian Kardell: Yeah.
Eric Meyer: But a lot more blending because... And again, that leaks out to everybody, right? [inaudible]-
Brian Kardell: Yeah. And Webauthors, I think that's-
Eric Meyer: Right.
Brian Kardell: ... rhe bigger thing, is like a rising tide lifts all boats here. Because this is the commons, right? And the more people working on the commons, the better, right? The more people we have enabled to help affect priority by doing some work-
Eric Meyer: Mm-hmm.
Brian Kardell: ... and saying like, 'I can understand this isn't important to you. But if you're not actively opposed to it, we'll do the work.' That's actually great for everybody, because not everybody can see from where they sit the relative benefit of this. And certainly, we'll all, as in the case of maps, enjoy the benefits. Like you will enjoy that web maps get a lot more fluid and speedy, and like everybody will appreciate that.
Eric Meyer: I feel like some work we've got in the pipeline is going to be similar, and I'll be interested to see how the work on MathML and MathML Core actually benefits from, and also informs, the stuff with SVG, and Canvas, and all that sort of thing.
Brian Kardell: Yeah.
Eric Meyer: Or if it does. But I mean, that's a thing that's coming. And I think that fits, that reminds me very much of what you were saying about most people might not see how it's relevant or beneficial to them, right? Because the vast majority of people probably do not think that Math markup is relevant to what they do, or what they consume. And yet, right?
Brian Kardell: Yeah, absolutely. Like I went my entire, let's not talk about how long it is because it's a little embarrassing at this point.
Eric Meyer: Mm.
Brian Kardell: That's not embarrassing, but I don't want to discuss how old I am.
Eric Meyer: There we go.
Brian Kardell: But it's a long career I've had now, and I've never had to render advanced Math.
Eric Meyer: Mm.
Brian Kardell: Like I have worked professionally on web applications and websites, and I have never had to really render much Math, right?
Eric Meyer: Yeah.
Brian Kardell: It's not what you're doing every day. And you think like, 'Well, it's maybe not that important.' But if you want to share information on the web, this is the way you do that with Math.
Eric Meyer: Mm.
Brian Kardell: Like in a way that treats it as text that doesn't require a JavaScript that-
Eric Meyer: Right.
Brian Kardell: ... works with all of the concepts of the web, like CSS, like copying and pasting, accessibility.
Eric Meyer: Yeah.
Brian Kardell: Like this is the thing that's received a lot of attention. And you know? I mean, I hate to use the same example all the time, but if, heaven forbid, there were a global pandemic, and we wanted researchers to be able to share information that involves Math and Chemistry and stuff like that, and we had to send our children to school to learn things on the web, Math is important to that one could argue.
Eric Meyer: I've been working on a side project with a colleague that actually involves quite a bit of Math. And we use MathJax, which is a JavaScript library, and it makes it really easy. Like I could express all of the Math in LaTeX, and then MathJax's library will show you the MathML version of that. And it makes it as accessible as it can, and it uses SVG to render some of this stuff.The library is 17 megabytes, like literally half the entire weight of the project. Well, so the MathJax library is more bytes than the actual text content. And this is an entire book we're talking about, and it's in the vicinity of the weight of all of the images. Which nothing against MathJax, MathJax does an incredible job at what it does, and it has to be 17 megabytes to do all of that stuff. But I would've been a happier if we could've not needed that, right? Because one of the things that I've been thinking about is how do we make this so that it's service worker-driven so that you can just install the whole book on your phone, or your computer, or whatever, and you can then have it completely offline, right? You can access it no matter where you are, should you want to. And that's more difficult because of the overall weight. And like I say, 17 megabytes of it is just this JavaScript library, which is necessary because equations are integral to the text. You can't understand what's going on without them.But yeah, that's unusual. Most people don't run into that sort of thing. But again, much like with OffscreenCanvas and SVG hardware acceleration, for these very specific things, like very few of us work on embedded... Well, maybe a lot of us work on embedded devices, but very few of us work on set top boxes for a cable company. But that work benefits everybody, whether or not they work in that kind of area.
Brian Kardell: Yeah, definitely. I think it's possible that you don't have the most optimal use of MathJax there.
Eric Meyer: We ended up needing a lot of it, so I don't know.
Brian Kardell: MathJax has a lot of things. Like they have basically an SVG rendering module-
Eric Meyer: Mm-hmm.
Brian Kardell: ... and an HTML instrumental rendering module, and a MathML rendering module.
Eric Meyer: Yeah.
Brian Kardell: They have TeX and LaTex both support, as well as AsciiMath and a bunch of other things.
Eric Meyer: Yeah.
Brian Kardell: But there's a lot of tree shaking that you can do to get that to be definitely not 17 megabyte. That seems really big.
Eric Meyer: Mm.
Brian Kardell: But yeah, probably there is a distill that's just like, 'This is everything.'
Eric Meyer: Right.
Brian Kardell: And I imagine that would be probably pretty large, and maybe it's also not minified, or something that contains a lot of documentation, I don't know. But yeah. I mean, either way you go, it's going to be a non-trivial amount of JavaScript. Like how big it has to be before it starts really impacting you is difficult to say, in part because you know? Math is text. Where else do we not render the text until the JavaScript loads? Like there's always going to be a problem, right? Because everything then has to reflow. And when we're executing JavaScript, again, and when we're touching [inaudible] it's like it's all single threaded. So yeah.
Eric Meyer: Yeah.
Brian Kardell: So you know? You'll see a lot of sites that use MathJax. Like once they render, they look actually really nice. Like they-
Eric Meyer: Oh, yeah.
Brian Kardell: No, definitely no knock on the people who made that. I'm thankful that they made it and kept us going for as long as we have.
Eric Meyer: Yeah.
Brian Kardell: But it isn't ideal in a whole bunch of ways. It's not text. You have to wait until the document loads, or you have to pull the thing, or use a mutation observer or something. And know when new Math enters the page so that you can as quickly as possible stop everything, turn that into Math, and do as minimal reflow as possible. And if you have something that has a lot of Math, it will take a long time to do all the Math.
Eric Meyer: Yeah. I've been having my version of the flash of un-fonted text, which people might remember from early days of web fonts. I mean, you can still get that these days. But I have the flash of un-Mathed LaTeX, or un-SVGed LaTeX, or whatever, where if you're most of the way through the page and you hit reload, like for a half second or a quarter second, you can see the raw LaTeX notation before it gets re rendered into beautiful equations with integral science and whatever.
Brian Kardell: And that's on your setup, too, right? Like that's not on a cheap phone.
Eric Meyer: Yeah. I mean, my laptop is, in fairness, almost a decade old now. But I mean, it's still capable of doing pretty much everything.
Brian Kardell: It's a Mac, right?
Eric Meyer: Yeah. It's a a 2013 MacBook Pro, and it was fairly top of the line when I got it. So it's still fully capable, and it's certainly more powerful than just about any embedded device. Yeah. But you run into that. And I think even if I went out and bought a machine today, I would probably still see some of this stuff.
Brian Kardell: Yeah.
Eric Meyer: Because at a certain point, it's less about which generation is your processor, and just how much does the browser have to do?
Brian Kardell: Fred Wang, by the way, has... I don't know if I showed you this, but he has a LaTex custom element-
Eric Meyer: Mm, mm-hmm.
Brian Kardell: ... that you put the LaTex in the element, and it will render it as MathML, like for the actual rendering.
Eric Meyer: I a hundred percent want this already.
Brian Kardell: Yeah, it's really interesting. But honestly, that is better done at a pre-process time. Because then you still have to-
Eric Meyer: Yeah, yeah.
Brian Kardell: ... know how to process LaTex, which is a big ask, right? Like it's still a pretty non-trivial. It's way more focused, and it is very fitting with everything else that works in the web, and you can plug into all the things that you would expect to plug into about controlling font sizes, and nothing is just weird. But-
Eric Meyer: Right.
Brian Kardell: You know? There are plenty of markdown elements, too. And I think there are cases where they make sense. Like I think if you had like the GitHub preview thing.
Eric Meyer: Right.
Brian Kardell: That seems like a fine use of a custom element that would render your mark down.
Eric Meyer: Yeah. Mm-hmm.
Brian Kardell: You know? For most cases, you would not want to send mark down to the browser. You would want to send the generated stuff.MathML, by the way, we are getting very, very close to sending the intent. I'm hoping that we do that somewhere around... Don't make any quotes just yet, but-
Eric Meyer: Okay.
Brian Kardell: ... I'm hoping that we do that somewhere around the Women's Hackfest, that we can announce an intent to ship. That would be awesome.
Eric Meyer: That would be. Yeah, a hundred percent.And there's one more that I want to want us to touch on because you know so much about it, which is spicy-sections. And who decided to call them spicy-sections and why? I just have to-
Brian Kardell: Okay. No, I can tell you the story of that. So I don't know if you know this. But back in 2015, Léonie Watson, Steve Faulkner, myself, and maybe Charles McAthy Neville were at a TPAC. I was describing some things and asking some questions, and I had this idea. We talked through it, and we came up with a proposal together called panel sets.
Eric Meyer: Okay.
Brian Kardell: And a panel set was a single construct through which you could offer some kind of API that would cover several of the ARIA patterns. Because a lot of them, like by here, I mean tabs, accordions, and a stack of progressive disclosures. Carousels don't have an accessible pattern, but we imagine that maybe some kinds of carousels could also. Like all of them are around showy-hidey things, right? Like they're just showy-hidey things with labels.And so we made this proposal together, it was called panel sets. And nobody was ready for that at that point. And it had some ideas in it that... Like we made a poly fill, we tested it, we got some use, and it had some issues. So we just decided to put it on the back burner. But it came back, and I had an idea for a new proposal, and I didn't want to call it panel set-
Eric Meyer: Okay.
Brian Kardell: ... because of confusion around that, and we had a lot of debate about what to call it. And I had this idea that maybe these are... I don't even know if they should be properly tabs and stuff. I think this is a pattern where the thing I'm focused on is when that is not the core to what it is. So there are applications in which the tab is fundamentally important. Your browser is an example, right? Like the-
Eric Meyer: Mm-hmm.
Brian Kardell: Like the tab is a very important, specific thing.But there are a number of things that are simpler tabs that are just about displaying content in a document. And we already have ways to do that, like headings and content, right?
Eric Meyer: Okay. Yeah.
Brian Kardell: And I noticed that we have this parallel that, for some reason we haven't latched onto at all, which is scroll panes.
Eric Meyer: Hmm.
Brian Kardell: So scroll panes exist in almost every UI toolkit. Like that's a thing, a scroll pane. And you create one, and that's what you put your text in, and you do that with code. But on the web, we don't have a scroll pane. We have the concept of overflow, and that's just it's a matter of display, right? Like you don't-
Eric Meyer: Mm.
Brian Kardell: You don't have a programmatic API that is exclusively... This is, and always will be a scroll pane. There's no scroll pane element.
Eric Meyer: [inaudible]-
Brian Kardell: And so I had this idea that, well, what we want to do in a lot of these cases is not fundamental. I think even summary details is broken because what if you want to print that thing? Like can you display it? Can you cause it to display as a heading in content?
Eric Meyer: Mm.
Brian Kardell: What if you're in reader mode? What if you do find in page? Like we have not answered a lot of these questions. And for a lot of websites, it's not the natural control that you would want it to be when it's about the text.
Eric Meyer: Mm.
Brian Kardell: Does that make sense or no?
Eric Meyer: Mm-hmm. Yeah.
Brian Kardell: So we batted around a whole bunch of ideas of what to call it. And Dave Rupert frequently says, 'Spicy divs.' We've had a bunch of talks about this. Like I was on their show, I don't know, two, three years ago, and we talked about how a lot of HTML elements are just spicy divs. Like they either don't have anything, like there's nothing programmatically special about them. They don't have any API surface. Maybe their whole entire implementation is like a CSS rule in the style sheet.
Eric Meyer: Mm.
Brian Kardell: And it's like okay, but it costs a lot of money and time to do that. And well, is it beneficial to spend that money working on more spicy divs, or do we want to work on things that can't easily be done with a single UA rule or something? You know?
Eric Meyer: Right.
Brian Kardell: And he called those things spicy divs. And in this discussion, Mia said, 'What I really want these to be is I don't know.' And I said, 'Well, I want them to be what the section element should have been, I think, right?'
Eric Meyer: Oh.
Brian Kardell: 'And I don't know what to propose it. And I don't know if I'm proposing it is a new element or that we can like mix it into some existing elements. I don't know.' So Mia said, 'et's just call them spicy-sections.'
Eric Meyer: All right.
Brian Kardell: And that is the very long story of the spicy-sections. But they are interestingly, we had a kind of a vote on what should we call them for real?
Eric Meyer: Mm-hmm.
Brian Kardell: And the answer that I picked was panel sets, so-
Eric Meyer: Oh.
Brian Kardell: ... I guess that's some vindication that was a good name. I was not trying to push that. It's just where we landed.
Eric Meyer: Time is a flat circle, apparently.
Brian Kardell: Yeah.
Eric Meyer: Like that's fine that it was a long-winded explanation of where the name came from, because it actually also explains what they are, right? Yeah, it's having messed around with them as web components a little bit. Yeah, really compelling. The ability to be able to say, 'Hey, in this context, it should be like this. And in this other context, it should act completely differently,' right?
Brian Kardell: Yeah.
Eric Meyer: Like not just look different, but actually be interactively different. We don't have a lot of that. Well, we don't have a lot of that that's not completely driven by JavaScript.
Brian Kardell: We don't. No, we don't. And that was the purpose of the article that I wrote in asking people to... Like I don't know if it's a good idea. Like it's certainly... You know? Like we shouldn't base a whole feature on an idea that I had when I wrote a particular blog post, but it feels worth exploring. You know? And we were exploring it.And definitely some interesting things have come out of that. So Tab Atkins had a proposal for CSS Toggles, which he claimed would allow us to do a lot of these things. They have since fleshed that out and revived that.
Eric Meyer: Mm-hmm.
Brian Kardell: And really, a huge part of the reason why is because we did the work on spicy-sections.
Eric Meyer: Right.
Brian Kardell: And I say we, but that actually was a community that involved Mia, and Dave Rupert, and John Neil.
Eric Meyer: Mm-hmm.
Brian Kardell: Matthew C. Phillips was involved a little bit at the beginning. So was Zach Letterman. Yeah, there were a bunch of people. I feel like that I'm probably leaving off somebody and I feel bad about it now.But yeah, I think that also then relates to focus group, which is an interesting proposal for Microsoft. And you know? Like all these things will fit together, but I think we will get some really exciting new UI constructs. I don't know if they'll be Toggles, I don't know if they'll be spicy-sections, I don't know if they'll be focus groups.
Eric Meyer: Mm-hmm.
Brian Kardell: But those discussions are going to very, very rapidly lead to actual experimentation in browsers, and concrete spec proposals, and poly fills that you can play with. And I think we are rapidly approaching bettering your ability to do those sorts of things that is currently like pretty snarly.
Eric Meyer: Yeah, pretty cool.Oh, I feel like we forgot stuff, but we've also been at this a while.
Brian Kardell: Yeah, no, no, no. We could probably go all day.
Eric Meyer: Yeah.
Brian Kardell: Our podcast listeners will know that Brian is a long talker.
Eric Meyer: Well, but even at that, just we didn't really dive into practically any of those things, so-
Brian Kardell: No, we didn't dive into any of them. We could maybe do a spin out on one or two of them. But you can see why people are really, really interested and excited. And-
Eric Meyer: Yeah.
Brian Kardell: ... I just want to point out that the common thread across almost all of these things saved cascade layers. I think literally everything else that we talked about, Igalia was involved in either directly, writing code, or doing their early advocacy that helped to get unblocked, or doing spec work, or-
Eric Meyer: A lot of it was you, my man.
Brian Kardell: Oh, well...
Eric Meyer: It was. Come on. At least with the spec work stuff.
Brian Kardell: Oh, maybe some of it.
Eric Meyer: Yeah. Okay.
Brian Kardell: It's I think super fun, and I'm excited.
Eric Meyer: Yeah.
Brian Kardell: I'm excited not just for that, but I'm excited that we are... You gave a really great talk last year at TPAC.
Eric Meyer: Mm, mm-hmm.
Brian Kardell: Definitely people should go watch that, but it was announcing a new open collective effort that we did.
Eric Meyer: Right.
Brian Kardell: But I think it just really explains it well. I mean, it just explains it well, is that the more people we can have, like not just individuals, but like companies-
Eric Meyer: Mm.
Brian Kardell: ... that can do work in the commons, we all benefit from it, so-
Eric Meyer: Right.
Brian Kardell: ... it's awesome.
Eric Meyer: And the talk was, I think, 17 minutes. So if anyone's interested, it's not a major time investment. It's not one of these, 'Oh, I have to set aside an hour,' kind of deals.
Brian Kardell: It's not an Igalia Chats podcast.
Eric Meyer: Oh, no comment. Guilty as charged.
Brian Kardell: Okay, we should wrap it up.
Eric Meyer: Yeah, probably should.
Brian Kardell: Thanks, Eric. It's always is fun to do these.
Brian Kardell
Eric Meyer