The CSS OG Eric Meyer. 1994 CSS, JS in Fridges, Tailwind, and Web Standards

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax, the podcast with the tastiest web development treats out there. Today, we have a guest on, which I am very amazed that We we get to have on. We have Eric Meyer on who is extremely prominent figure in CSS world. He's been Responsible for a lot of the stuff that has come to CSS over the the many decades and is author of of many books. I'm pretty sure you wrote the original CSS Node, what, testing pnpm? What was that called? Yeah. The CSS one test suite.

Like, the browsers would point towards that to make sure they have implemented CSS correct? Yeah. That was the idea anyway. Yeah. Unreal. So I'm sure I'm missing a a lot of the stuff out here, but I'm sure most people already know who who Eric Meyer is. Welcome to the show. Thanks so much for coming on. Yeah. Thanks for having me. It's great to be here. Yeah. So why don't you give give the audience a a quick rundown of, who you are, what you do, and and maybe some of the Large things you've been involved in over your career. Gosh. There's been a lot.

So I I started out as a burger flipper, way back in the day.

1st job, McDonald's, like everybody.

Yeah. More more, specifically, I was working at Keyes Western Reserve University in Cleveland, Ohio, which is where I still live, and that's where I graduated from. And I, as soon as I graduated, I managed a job on a theory that I would try to make back all of the money I had given them intuition, which I actually did. It took Yarn, but I managed. Anyway and, I was a hardware jockey for the libraries, you know, installing computers and stuff and, making sure that they worked and, you know, replacing the RAM when students Stole it, which happened at least once. Holy smokes. Round about that time, there was a A colleague, who's also a friend, was telling us that we really had to check out this new thing called Mosaic.

And I was like, yeah. Whatever.

Right? It's another one of his full enthusiasms. But then I actually got to try it It was immediately taken. So I quickly became the webmaster there at, a case back when we were called webmasters.

We're talking this is 1993, 1994 JS what I'm talking about here. Yeah. In fact, 5th December, I think It was 30 years ago today I marked up my 1st HTML document. Really? Wow. Wait. 3rd 30 years ago? Because Yesterday, December 4th, was the 28th

birthday of JavaScript. So this was 2 years before JavaScript was even a thong. Indeed. This was Wow. A at least a year before there were tables

on web pages. Like, table markup did not exist. But, anyway, while I was there, I I I got to, help the university get stuff online, and then I also managed to get The university just sent me to some conferences to present some papers.

And at one of them, there was a presentation about this newfangled technology called CSS. The browsers didn't support yet, but they were about to. And, really blew that blew me away. So I got really interested.

In the course of trying to learn CSS, things kept not working the way that I thought they should from reading the pnpm. And so I started setting up these simple test pages to just figure out, like, do I understand what margin means? Right? Or do I, like is this browser browser just not recognizing what padding is? And that evolved into the CSS one test suite, that I shared with a working group. They were super interested. They shared it with browser makers, and it eventually became the 1st official w three c test suite.

Yeah. I mean, I I and I got some help. Let let me be clear. This is not like a solo, you know, hermit genius kind of whatever.

Like, Tim Boland at the National Institute of Standards and Technology helped out, Chris Lilly's, from the CSS working group. Other CSS working group members contributed in some cases contributed What we would now call bug reports, but in those days Wes sending me email saying, oh, this one's wrong. Like, you did not understand how that particular thing worked, So I would fix it, and then Todd Farner created the acid test, which was made part of the test suite. Around about that same time, I started writing the 1st edition of CSS, the definitive guide for O'Reilly, and it has now recently, had a 5th edition.

So And here, let me show you a visual difference for for those. So here's the 1st edition.

Right? Here's the 5th edition.

You could just tell by the lift.

That's

yeah. The 5th edition is at least 3 of the 1st edition.

This this was, like, 400 pages. This is

1100 and some. Yeah. And back then, you it was so as Mosaic, which eventually became Netscape Navigator, but, like, IE wasn't a thing back then. Wes that The only browser at the time? At the point where I encountered CSS,

which is 1996 Yes. 1990 like, summer of 90 spring of 96 is was I was at this conference. And, actually, the only browser that at the time was supposed to Support of the CSS was IE 3, but then the guys at Netscape heard about it. And so Netscape Navigator 4, they started to implement stuff, some of it incorrectly.

I still recall with fondness the time that I explained to an engineer who shall remain nameless At Netscape, that, picas did not mean 1 100 and 40 4th of an inch. They were actually, like, Twelve points. They they had misread it. They thought a pika was a 12th of a point instead of 12 points.

Not that anybody uses pikas or points, but whatever. That in some ways, that that makes it more sort of dear to my heart because it was completely, like, nobody's ever gonna use this, but we're still, Damn it. We're gonna get it right. Yeah. As part of trying to figure out, like, what browsers did what correctly or didn't support at all or whatever.

I started to create these charts, these tables For the for anyone who like, the easy way to visualize this is imagine if you had caniuse.com Except as a single table that listed everything.

Now at the time, I was only listing the properties in CSS one, which is, like, 70 properties or something. It wasn't that huge, but it was still still a big old, like, yes, Node, partial Buggy is how I coded things, and it was YMPB.

I color coded them. And I just started publishing this for free because I was like, I have this test Scott, So I know what browsers are doing. Why don't I just put it up there for people? So I did. That led to, Dale Doherty at web Webreview contacting you and saying Wes would love to publish these at Webreview.

Would that be okay? And I said that would be awesome. And if you ever need anyone to write anything about CSS, let me know. And he said, actually, we would love to, and here's what we pay per article. And I remember reading that email and thinking, wait.

They're they're gonna pay me for this? Yeah. Not that it was a lot. I mean, but it Sure. Still, they were gonna pay me to write these articles. So that Then that's what led to me actually ending up writing the O'Reilly book was it turned out that Webreview had their cubicles right next to the O'Reilly cubicles. And so one day, the O'Reilly people were having lunch with the web review people and said, do you know anybody who knows anything about the CSS thing? Because we think that maybe we should Write a book, publish a book or something.

They said, yes. Wow. It's wild how that stuff kinda snowballs. Right? That opportunity snowballed into the other one. Back So at at that time, when you're picking up CSS, is the only way to learn it via the spec itself, Or was was that it? Yeah. Yep. Pretty much. Certainly, in 96,

people did start to write, you know, tutorials and articles relatively Soon and, I mean, I say that being one of the people who's writing the articles, but, Yeah. It was pretty much reading the spec, but the spec was, like, 70 pages or something. It was not huge.

Yeah. It Wes it wasn't densely technical the way w three c pnpm are now.

And Scott that I think that The way they are now is a bad thing. It's actually a good thing. It does technicality of the specs.

There's so much detail that when someone goes to implement Something it's all spelled out like this is what it should do. And if there's a particular algorithm to figure it out, this is what that is, You know, so for, like, grid layout. But at the time, the specs were, here's what margin is, and here's a property for it. Like, not Describing in detail, like, how you should run the calculations to do margin collapsing, it was much more conceptual. So it was all I mean, they were much more human readable, but that, I think, is also why so many browsers at the time implemented things, so incompatibility Because each engineer you know, if an engineer JS implementing margin collapsing, they're gonna bring in assumptions.

Right? They're and it's gonna be up to the way they interpret how these particular sentences are put together.

And so, like, different browsers, would do things differently.

And so, yeah, I think I think that's the thing that was learned was don't leave things so Ambiguous.

Yeah.

The test suite today is every now and then when a new thing comes to the browser or to CSS.

And if there is nothing but the spec and you want to see, like, what does this code actually look like? Sometimes it it makes sense to just go into the test Scott. You should if if you want to have a fun time, go take a look at the modern test Sanity because, The Flexbox and Grid test suite alone is just every single possible edge case that they could think of. And then they implement it and find Discrepancies.

So they write more. It's the same thing with with test driven development. Right? You just write a test that figures out, oh, that was a little edge case and you try to to go at it. It's it's absolutely massive today, isn't it? Yeah.

The web platform tests, which is where most of this lives, is just Staggeringly huge.

There's so much there.

We we were looking at that recently.

I think there's literally over a 1000000 tests in total in web platform tests.

Not just for grid, for everything. Uh-huh. Yeah.

But, yeah, there are like you say, there are, tests are constructed, And then implementations are Deno, and sometimes the implementers discover, Oh, hey. This interacted in this weird way or Wes, like, we made this assumption, and we're We're we're not the same as the other implementation by, like, this little bit.

What should it be that comes back to the working group? The working group makes a decision. Usually, then a test Case is written to cover that thing, whatever that decision was. And then, yes, it keeps sort of Snowballing, as you said, in a good way, though, especially because then if you're the 3rd or 4th implementer to implement the technology After it's sort of been through that whole process, you have all these tests. Not only do you have the detailed specification, but you have all these tests to test against. And you might, For that matter, be the person who goes through all of the tasks and goes to the specification and and then comes to the working group and says, so I found another situation that It's not been covered, but, like, it's created weirdness. So, yeah, it it keeps going like that.

But, yeah, there are there are there are so many tests, and it's it's interesting. There's a there's sort of a dichotomy in within web platform tests. Some of them are very JavaScript driven.

Like, you just you just create these JavaScript based assertions, and either they pass or fail.

And then there are visual tests where there's not only a test, but there's a reference rendering image that is supposed to be compared to, and they're supposed to be a pixel for pixel match. And you have to be careful which you use and which kind you use. And Some of the older like, the JavaScript tests are more recent, and then sometimes you can't use the JavaScript because it's purely a visual effect, Etcetera, etcetera, etcetera. It gets very complicated, but this is part of the reason why browsers are so much more consistent, Like, interoperable

than they used to be. Yeah. Just like weird little edge cases Wes, like, imagine you have an image with an auto width Inside of a container query, which is inside of a grid that has a flexible with, you know, like, there's all this. I do not envy The person that has to go through this, like, who came up with this edge case and try to figure out how to duplicate it and to to put it in? It's it's while to

think about all the possible edge cases. And then you have to go into the, like, low level language that the browser rendering engine is written in And figure out how to catch those specific use cases. It's funny because Wes and I were going in a very similar spot. I was just thinking about the conversation around container queries long before they arrived. And how we talked about them existing and potentially existing and then, you know, just kind of disappeared for a little while, and then, It it just makes me think, like, it's it's kind of a a miracle that anything is able like, that complex is able to get Add it to the platform, and all this stuff just works. It it's pretty incredible.

Yeah. And a lot of that is this this Wes, Implement, test, implement, test, implement, discuss, implement, churn in a sense that that we were just talking about, Because then by the time things come out from behind the the developer flags, the the, like, the experimental web features flag in Chrome, the the similar flags in in Firefox or, the Safari technology preview builds.

By the time stuff has come out from there, it's already been through this process of sort of iterative testing and Implementation and refinement.

So I feel like the 1st major recipient of that process was CSS Grid, which shipped in 3 major engines in the space of a month in 2017 and was in The 4th major engine at that time by the end of that same year because at the time, we had 4 engines.

And, That was because there had been this this sort of churn of, okay, we decided this.

The 2 browser team you know, 2 or 3 brow however many browser teams went off and implemented what we decided, but they came to different conclusions or, like, The, you know, the the way grid track sizing interacts with the regular box model sizing has, like, these bizarre, situations, and so we gotta we gotta clarify that and etcetera, etcetera, etcetera. But it's not the last of those. And sort of the the last major technology I can think of that didn't, benefit from that was Flexbox, Which Yeah. Most many of us remember as, oh, Flexbox, that technology that, like, didn't work for half a decade.

And, yeah, a lot of us still sort of reflexively avoid it because it was so sort of buggy between, implementations, but it didn't have this process at the time that it started to, ship or as Grid did and a lot like, container queries is another example of a of a major technology, that has benefited from that process so that by the time it comes out, it's pretty stable. It's not nothing's perfect. It's not perfect.

There will still be bugs. There will still be refinements.

But, like, it comes out from behind the flags, and you can kinda if you're in a situation where you like, you're Working on a Internet project and you know what the browser base is gonna be and you know that that browser base is gonna have that container query support, you can just do it.

And if you are not in that situation, you still have, you know, support ad supports feature queries To do the, hey. If you support container queries, here's a whole bunch of stuff for you. And if you don't, then, You know, you get a non container query version in it. It's okay,

but it's not as, like, awesome as it could be. Is is this the reason why it seems like things are coming a lot faster nowadays? I mean, you know, we it it does feel like container queries Popped up, and now we can use them, and we ship them on on our site. You know what I mean? It it it just seems like stuff just is just dropping really fast nowadays. Yeah. I think part of it is this. Part of it is that there are

some really committed drivers of things so container queries owe a lot to Miriam Suzanne who drove that process, You Node, and kept shepherding it through the Scott of the iterative loop. And Yeah. All the ideas and feedback cycles. Right. And it had a good design to start with. Right? Like, had this proposal that was a pretty good design. It's, you know, not necessarily exactly what came out the other side, But, you know, Scott it with a good design because Miriam is super smart and knows a ton about CSS.

And so, there have been other things like that. The, the has pseudo class, which has, just come out. Like, that's an idea that's been around Almost since CSS was CSS.

And the problem was always performance, but eventually, sort of somebody understood, hey. Here's how we could fix This performance problem or how we could deal with this so that you, you know, you don't grind the browsers to a halt Trying to select ancestors.

But, yes, I think I think that's part of it.

And a lot of it is just there's a lot of interest in, from the various stakeholders in pushing CSS forward. There are A number of people, from various, engine makers on the CSS Working Group who participate in That conversation, who, you know, sort of carry major parts of CSS in their heads. And so In the discussions, someone if someone says, yeah. I'm concerned about how this will interact with that. They're, you know, they're able to say, Oh, good point. Or that's not going to be a problem because of this other thing. Right? I was I was just gonna ask you that. Like,

How many of the people on CSS working group are also people that write the code to implement it? Because it's one thing to think of A design. And that's a very hard thing to do JS how do you design a language? And then the other part is how do you actually implement it so that it paints to the page? So There it's good to know there's several people on there that I I would say a fair portion. It's not Okay. Probably not a majority.

I could be wrong about that, but it's a fair number of people. With CSS, I'm also gonna give, credit to preprocessors, Like SaaS and Wes because in many cases, things that have been done through preprocessors and through extensions or mix ins or whatever the hell they're called. I don't actually use preprocessors myself, not because I think that they're terrible. I just don't.

But People, you know, will create mix ins or or the language itself will have something like nesting of Selectors.

Right? So SAS has you can nest your selectors so that instead of having to write out the whole Chain of whatever. You just put your inside the section block, you also put h one.

Right? And then The preprocessor spits out the section blah blah blah, section h Node blah blah blah. Right? That kind of stuff. That's coming to native CSS Because it was shown to be so incredibly popular and powerful in preprocessors that the working group Wes able to say, well, here like, clearly, there's a use case. There's a demand for this. We can make it native, and we also have, Like, a path has already been blazed.

Right? The the trail has been marked. We may not be able to follow that trail exactly for technical reasons, but, Like, there's already a reference implementation there that we could look to and say, do we do exactly that? Or do we do something Very, very similar to that, but it's changed in this one way because of, you know, the CSS one parsing rules are still in effect. And when they were written 30 year you know, 28 years ago, whatever, nobody thought about ESLint selectors.

Yeah. Or do we have to go a completely separate direction? It'll be this completely different syntax that'll have the same result, But it doesn't look anything like the same.

As it turns out, the working group in the case of So that selector nesting has essentially followed what preprocessors have done, I think, with a with a tweak here or there, but they So it's so close.

Like, it's amazing like that.

We saw the iterations over the Yarn, and we had a few episodes of, like, oh, yeah, you have to put an ampersand in front, and There's these little gotchas, and all of those gotchas went away to a point where SAS dev can just sit down and start With maybe, like, a 5 minute little pep talk can start writing nested CSS. That was, I will say,

a long and contentious Debate JS to whether or not it was advisable or even, like, possible to get exactly the same syntax.

And there were very strong opinions on, I I would say, both sides, except I don't think there were just 2 sides.

And there were real concerns from the SAS community.

You Node, one of the voices was if you do your syntax exactly like SAS does It's syntax.

Like, that could cause breakage in or I don't remember exactly, but, like, the SAS community, the actual core programming team of SAS Yeah. Had very strong opinions on, you know, how to do the syntax in native CSS in order to avoid problems with actual SaaS websites or SaaS driven websites.

And, also, within the working group, leaving that aside, there were people who said, you know, There should always be an ampersand or everything has to be in an at nest block, you know, in order to not create future problems or in order to not Create problems for past browsers or both. And then there were other people who said, no. That it should be As simple as possible, it really used to be a very straightforward syntax, and that was a that was a long debate. And like you say, if you just watch sort of the Each version of the editor's draft to the specification, you you would see that syntax changing, which is a reflection of that debate.

Yeah. But, yeah, there were, I mean, there were, like, entire hour long working group calls that ended up even though there was an agenda that had many, items on it basically ended up just being we're just we're gonna argue about nested selectors. And it's it's it's sometimes, it just it goes on for a really long time because There is that Node. There's sort of that here's here's a concern, and everyone else says, yeah. That that's a real concern.

We all need Node have to go away and think about that and see if we can figure out a way forward that will not create problems for

authors. Right? Because Yeah. I I appreciate those people doing that, though, because The alternative is you ship this thing and everybody goes, oh, why didn't they do X, Y, and Z? And And then people go, like, I'm not actually gonna use the real CSS version because it's not it it doesn't cover these use cases. And I I feel like CSS Nesting nailed it. Like,

Some people had some really long conversations about it, but Fingers crossed that they nailed it because one of the concerns was If we ship it so it looks exactly like SaaS, in 5 years, will we regret that decision? Yeah. Well, Here's another question I have on the same vein is like in JavaScript, we got

essentially got jQuery, right? Like Wes query selector, all of that stuff. And Now we have Sass ish in in CSS.

And one of the big things that's incredibly popular right now that I don't think JS just a fad JS the fact that people like to write Tailwind, and they like to write their CSS In line. And I think aside from you don't like the classes and it's too much to muddy up your HTML, the the thing that people like about it is that you can write it in line Wes you're actually doing your templating.

So my question is 2 part to you. A, what do you think about that? And b, do you think we're ever gonna see an Extension of ESLint CSS to do all that Tailwind has?

I'm going to defer on the second question because I don't know that I could Say what all tailwind has.

Okay.

But on the first part, what do I think about that? The spicy topic.

Yeah.

And my spicy take is that a bunch of us ESLint a lot of years learning why inlining all of your style is a terrible idea And that the cascade is actually your friend and not your Sanity.

And because there there was a there was a fad for a while, This is many years ago where everything would be element style equals blah blah blah blah blah blah blah. And, like, the main style sheet would have almost nothing in it.

That turned out to be really fragile and unmaintainable and, terrible performance wise, at least at the time. Mhmm. And so for me, instinctively, if you're trying to ESLint everything, whether it's with class names or or not, if you're just if everything ESLint to me is Not it's not efficient, and it's not I don't think it's maintainable. Now I know that there are people who use Tailwind and say it's the most maintainable my CSS has ever been. And if that's the case, like, I guess, thumbs up. The little that I've done with Tailwind, it just does not work for me. But Jeremy Keith had a really good post a month or 2 ago about you Node, for some people, thing x, tailwind, react, whatever it is, is going to really mesh with how they approach things.

And so that's probably a good tool for them. And for other people, it's gonna be Like Kryptonite, basically, to their way of doing things, and so don't use that tool. I mean, You certainly, you can have debates about, you you know, does this tool make this site too heavy? Does it make it nonperformant? Like, does it slow everything down for whatever reason? Those are absolutely Sort of objective measures you can look at and say, is this tool good or bad in in a given situation? But Sort of at a at a assuming if you if you make for the sake of argument the assumption that They all have the same performance and weight outcomes, which, of course, they don't, but for the sake of argument. Yeah. Then it really comes down to, like, what works for you? Like, what makes sense to you? What lets you, realize what you're envisioning,

you know, more quickly and more completely? Yeah. And I I think JavaScript is at that point where there's parts of JavaScript you might never use because you prefer not to use it. But I don't think CSS is there. Right? Like, there's most of CSS. Oh, maybe I would like to hear your opinion on that. But, Like, most stuff that gets added to CSS, I go, ah, yeah. I can I can use this? I think certainly,

recently, that's been

Largely the case. Yeah. Maybe not print CSS.

Ouch.

Oh. Oh, actually

I I actually wrote a book once, and I did the whole thing in print CSS. So I have a encyclopedic knowledge of all of the print CSS.

Yeah. He's a lot of pretzies. That's where receipts lies. Nice. Yeah. There are I mean, there are sort of some odd corners.

And I can see someone saying, yeah. I'm never gonna use animations. Maybe I'll use transitions, but I'm never gonna use animations or at least not without, You know, being dragged to it. There's a there's a renewed effort to get, styles basically, CSS for speech.

So if you have a speaking browser or screen reader or whatever, you would be able to provide styling information to, like, raise the volume on strong elements or headings.

Right? Or Tolinski of raising the volume, deepen the pitch or you know? And Please nobody take anything I just said as, oh, CSS is gonna let you change volume and and pitch because maybe that doesn't happen. Clip that. Right. No. You can keep it in because there there was, long ago, CSS for exactly that, And almost nothing ever supported it. Like, emacs w three is the only implementation I'm aware of that supported oral CSS, as it was called, but that idea JS coming back around Node.

And it probably I they're not gonna just revive RLCSS, which is, which is what I was referred to there, but there is definitely renewed interest in Being able to provide styling cues for spoken content or for audio content, really. So, you know, another thing that the The audio CSS used to be able to do, was you could in the same way that you could you can have before and after Generate a content? You could put audio cues before and after something so you could put little dings before and after your hyperlinks, Let's say. Or you could put a little fanfare trumpet before in each one or whatever.

And so maybe that comes back because there are a lot like, the amount of content that's consumed in that manner of being read Allowed by a, a machine is growing. And, as Wes, you know, if Apple's bet pays off In VisionOS, that sort of thing becomes a major deal.

Yeah. I agree. Be even more spoken content because You probably if you're in an environment, you wanna be able to hear content. You don't wanna be you know, have the monitor strapped to your face Just to read documents, most likely.

So, you know, I would I would want Wikipedia pages read to me rather than Me having to sit there in a chair completely unaware of anything around

me reading a document. I I I found the the link, by the way, to the oral CSS press release from 1998. I'll link up in the episode so people can give that a a a read. Yeah. There we go. I I wanna keep going on that theme of,

just like alternative spaces where CSS may run.

So you work for Agalia.

JS that how you say it? ESLint Often, the reason why I first came it was many years ago on the podcast, we were talking about, where else does WebKit run? And Brian, he's like, hey. Like, we've actually implemented like, often browser vendors We'll hire or or companies will hire Igalia to implement features in the different, engines because they need it for their product.

So I'm curious, like, do you have any interesting examples of where the web is running Other than just, like, you sit down in front of your computer or open up a browser on your phone? So many.

The Sony PlayStation Runs on WebKit. Really? As an example. Like, what part of it? The browser or the whole thing? I I I don't wanna get into too much details, but, Like, it's WebKit. There are kitchen appliances that run on embedded WebKit.

There are set top boxes that, like cable set top boxes Wes the interface is SVG, Not necessarily ESLint. Really? But it's, yeah, it's it's SVG.

And so good. You're paging down through the channels, and you get that, like, old That's SVG.

It at least for some of them. I'm not gonna say for all of them, but some of the work that Igalia did at one point was improving the, performance of SVG rendering for that use case. Wow.

Most, automotive Entertainment displays are some form of embedded computer, often Linux, but not always, And usually using web technology to render the interface.

The SpaceX's Dragon capsule, The the big panels with the interfaces, it's Chrome.

That's Chrome and JavaScript.

The view, I remember. I remember Evan Evan Yu was like, my Node is running on a spaceship.

Yeah. On a spaceship. The James Webb Space Telescope Uses a 2 uses a 20 year old version of JavaScript to manage its tasks. Seriously? Yep.

100%.

100%, yes.

Yeah.

The real question is where is web technology not? Yeah. And it's mostly in buggies.

And, and I and I think, maybe kitchen knives, Probably not using web technology.

I don't think at least. Yeah. Yeah. There's probably probably somebody who shipped, like, Auto sharpening knife block with a little LED screen, and it's probably running Wes kit or chrome or whatever,

right, in the in the in the embedded flavor. Yeah. I I had talked to somebody at a conference once, and he worked for an elevator company. And, you know, sometimes you visit these fancy The elevators and tells you there's a little screen. Mhmm. And you can select what floor you want to go to. And it tells you which elevator to go to? Yep. Running embedded chrome. Pretty sure.

It's amazing all of the spots that it goes to, and I always love seeing that. Like, I used to collect photos of Blue screens of death in hilarious places. I still because I always thought that was really fascinating. But now I'm starting to see it's not blue screens of death.

It's chrome pop ups or the bookmark bar popped down by accident and Death tools bar or something. Yeah. You're at, like, a fast food restaurant, And all of a sudden, you see, like, a little chrome warning on it. There's it just pops up absolutely everywhere. And, So a Galio will be hired to implement some of those features. And I'm always curious about that. Like Apple has been killing it in the CSS realm a lot lately, and, they seem to be sort of erratic with, like, being the 1st to implement a lot of stuff. And I often wonder, and I'm curious if you know anything about that. Is that because they're like, oh, we need the new CSS color profiles for something So they they throw it in there so that they can use it. Is that why, or it's just because they're being a good steward of the web?

You know, it can be both.

I I would say the same about the Karum team or the Gecko team for that matter. You know? And, you know, being first is often It's often a matter of what do we have a business case for and an engineer who's available and willing to do the thing.

Right? So, like, with HAZ, the initial, Some of the initial implementations were actually done by Igalia in Chrome.

Well, Chromium, technically, because it wasn't shipping in Chrome. But that's, Like, the the prototype implementation, Gaia was hired to do that by the company that, that, Create adblock, adblock plus. So IO, it's e y e o, but IO.

So they hired Egalia because they wanted, Basically, they wanted a parent selector, an ancestor selector, and Byungwoo Lee, who's a a Gaia employee, Did that initial sort of prototype implementation of Chrome.

But at the WebKit team, there was an engineer who was really interested Apparently, in doing it, and so implemented it, and WebKit actually shipped has first Just because of where things fell Node development cycles and yada yada yada. Doesn't you know? But Just because there was someone available and they were able to I I'm sure they were able to justify it to their management.

Right? Yeah. And the same thing happens at Chrome.

On the Chrome team, they see a technology that there's a there's a demand for, And they can justify it to management. So, you know, they're out in front on view transitions because view transitions there's a there's a case to be made for implementing that. Yeah. You Node? Here's how we could use that at Google. You know? We can have better view transitions in Google Docs or Google Maps or whatever.

So, you know, I mean, the WebKit team has certainly been revitalized of late, I think. They've got a lot better Vercel thanks to Jen Simmons.

We've been trying to trying to get her on the on the show. Maybe you can, get us an in. I mean,

she works for Apple, so good luck. Yeah. It's Yeah. Yeah. Right. Yeah. I I it's Which is very similar if, you know, trying to get someone from Google on. That can be a challenge depending on who you're trying to get and what they wanna talk about. But anyway, And both companies actually, all companies, but since we're talking about Google and Apple, they both hire Firms like Igalia to implement stuff sometimes.

Mhmm. Because maybe they have the business case for it. They really do want it implemented quickly, But they don't have the engineering resources. Like, they don't have an engineer who's knowledgeable enough to do the thing and is also available and isn't already committed to other stuff.

Yeah. So, you know, Agalia, we did off screen Canvas implementation in WebKit.

Not, I think, because Apple Didn't think off screen Canvas was useful. They just didn't have someone available, and so they were Willing to hire outside. You know, in Chromium, we did the house, and we've done other things as well.

And that's It's kind of an underappreciated part of the ecosystem, I think, that it's not just The WebKit and Chromium and Gecko teams doing this stuff, they don't have infinite resources.

And, you know, people look at Google and Apple, and they're like, there's no excuse. They have the money to implement anything they want. Yeah. And that's not how it works. Right? Apple is not the WebKit team. Apple is way more than the WebKit team. Google is not the Chromium team. They're so you know, the the browser Engine teams are tiny parts of those companies that still like, they draw a goodly amount of resources, But they don't have the full resources of the company. Google does not give all of their revenue to the Chromium team. They probably love it. But Yeah. They would absolutely love it. Node it because they could hire a, you know, a kajillion programmers and and implement all kinds of, of web standard stuff that that's waiting because there's there's always an infinite number of things that could be added to the platform. We've been seeing that with the, The interop 2024, discussions and the interop effort in general, where This year, there were, I think just over a 100 proposed things to tackle ESLint Interop.

You gotta remember the 1st year of interop, there were 5 areas of implementation.

Right? And then the next year, there were more, and the next year, there were more. We there were over 100 proposals.

That was quickly cut down to just over 70 because some of the proposals were, This would be a really cool technology to implement.

No specification.

No working group. Just it would be awesome if browsers did this. It's like, You're right.

Yeah.

But this is not where you figure that out. Right? This is not the proof for that. So it was cut down to 71, and then it's been getting winnowed down further because there's no way that any browser team Could handle all 71 of those topic areas in the space of a Yarn. It's just not feasible.

So that has to just keep getting it has to be winnowed down, and there are gonna be proposals the in Interop 2024 the Same way they were in Interop 2023 that are just they're not accepted for the sole reason of Wes already have these other things.

Yeah. And that's we're not even you know, like, we're not a 100% confident we can even do all of those in the space of a year.

We just don't have room for anymore.

And, you know, topic a just has more Buy in from the various browser vendors, then topic tea

or whatever. Well, I I don't think anyone's complaining about, the rate at which stuff is dropping in the browser these days, it's it seems like every single day Wes get something new. So Well, there's a few people complaining it's coming too fast, which I always Oh, yeah. I kind of appreciate because

it was a it was it was a very long time where I was I will never complain about Any technology I get.

And then yeah.

You know, one of the conversations we've been having recently is how do you get the word out about new technologies? Right? If a if a new thing is dropping, how do you you like, how do you keep up? Because there's no way nobody can keep up with everything. Except for Scott and I. Yeah. But even at that, you I do you know everything that the HTML working group has been discussing about HTML in the last year? Do you know? No. Often, we find ourselves pawing through meeting notes just to give updates on things. Yeah. Right. Yeah. So that and that's one way to do it, certainly, is to figure out where the various meeting notes are published, which ones are worth following.

And then, yeah, like, every you gotta set aside an hour every week or 2 hours or whatever it is to go through those meeting notes. Like the CSS working group, after every call on the blog, they publish the resolutions from that from that meeting, which is a really nice way, to sort of be able to keep up. It's like, oh, this week, the working group had 4 resolutions, and they were about these things. And There's there's a link to each of the, issues. So if you wanna go, like, read the more detailed conversation, you certainly can do that.

But, you know, what is t c 39 up to? What is coming in JavaScript? What you know? And there are a lot of places you can go to find this information.

But just trying to keep up with just that, All of all of the things you could possibly try to keep up with, that's nearly a full time job. Yeah. And nobody's paying for that. That's It turns out you can't really make a salary on that unless, you know, I suppose somebody could set up a Patreon and maybe make that work.

But yeah. Yeah. That's the struggle. And, you know, people listen to podcasts like Syntax to and, hopefully, A thing that you are interested you that you would be interested in, somebody talks about.

But, yeah, it's really it's so hard to keep up. And, that's a that's a challenge Brian Brian Cardell, my colleague, who you referred to earlier. The this challenge Brian and I think about, like, how do we just make people aware that thing exists? Bruce Lawson As a colleague and friend, he occasionally does these, link basically reading. He calls them reading notes. They're just Sort of the here are things that caught my eye in the last however long it's been.

And recently, I think his most recent one, one One of the things he had in the middle of it was a link to an article about the isolation CSS property, and he said, I didn't even know that existed.

Right? Isolation's been there a long time, and it's not Bruce's fault that he didn't know. It's just one of those when I see that, I think, oh, yeah. Isolation.

Dude, clearly, you didn't read my book, which I get because it's 1100 pages, but it's in there.

You could find it if you looked, yeah, far enough in there. But how How would you even know Node to look? You don't know how to look. And container queries, there are people probably, who Maybe someone comes across this podcast, and they they're like,

container I have Node what's container queries? I need to go look that up. Right? And even if they've heard of it, that there's no You know, there's no guarantee they're going to go any further or even use it. We hear all the time from people who I learned Flexbox. I don't have enough time to learn Grid now. Even though Grid is, like, you Node game changing layout technology for CSS, so even Node simply hearing about it or knowing about it isn't Even a barrier to knowing how to use it. But that's it. Like, okay. We we've been gifted all of these amazing new Features in CSS. Right? Kind of like dream dream features from container queries to the you know, has selector, those types of things.

Is there a particular dream feature of CSS that you have that does not exist, or was it one that has been added?

Most of them have been added.

So there's there's one that I actually I've wanted for a really long time. This is gonna seem to fly completely in the face of something I said earlier in this very podcast.

But Style equals, right, in HTML, style equals blah blah blah blah blah.

Wes Node than 20 years ago, Danielle Glassman and I proposed Style equals at import URL blah.

And then you would import that style sheet, and it would only apply to that subtree.

Scott Styles? Essentially, Wes,

which are coming back. Now we have at Scott.

That's the that's a proposal which could let you do a very similar thing, but, that's a that's a thing that I I would like to see mostly for the same reasons that styles are scoped in Shadow DOM. I just I wanna be able to say this snippet applied to this subtree. And, yes, AtScope hopefully is coming. It's still being discussed.

Another one is and this goes way back.

Text align and then a string.

So in a table column, for example, if you have a table column that has a bunch of numbers and some of them have decimals and some don't, you say text align, And then in quotes, you put the period, and then everything is lined up on the decimal. Mhmm.

I had to come up with an entire, like, hack around using transforms in order to approach this capability When I was putting a book ESLint, year and a half ago, and, yeah, I would just like to be able to do that. I'm I'm sure there's I'm sure there's something that I'm thinking. Oh, hanging punctuation. Chris Collier just wrote about that recently. But for years, I've been saying, can we please just have hanging punctuation in more than a Wes kit because it's really nice, especially if you're trying to create your, presentation slides using HTML and CSS. Hanging punctuation is super useful because then you can put stuff in quotes and the sides of your text block lineup, and the quotes can hang out into the Margin or padding or whatever. Yeah. And I think I think the the the other one that I think we sort of haven't sort of done is marker styling. So list bullets and and counters and stuff like that.

We there's some ability to style markers, but it's not as Nearly as complete as it should be. But, I mean, you could tell I'm kind of grasping for the sort of these, like, these little Quality of life improvements as opposed to, like, fundamental features.

Yeah.

Oh, okay. Sorry. Here here's the one that I think is more than a quality of life improvement.

Color mixing like you can do in Sass, Which again, that's being prototyped in CSS. So ideally, it's coming natively where you can where you can do a You know, I have a color, and then for this other, in this other place, I I want the color to be 40% darker Or 3rd Wes% lighter, or I wanna mix that color with opacity so that I don't actually have to say, You know, RGBA, whatever, and specify the opacity. I can just say, give me that color that I had before They're already defined. Yeah. But mix, like, mix it to be a little, you know, a bit translucent, like, 50% translucent.

But that that's another situation where the working group looked at things people were doing in less than SaaS and said, That's a thing people really like to do, and it's clear how that is actually convenient for authors.

Like, it makes their CSS Sort of more robust and less sort of weird.

Yeah. And wouldn't that be great if we could get that with CSS variables, Right?

Dynamically updating, right, compared to the on build time. Yeah. Like, I've seen people do the thing where they have Node variable