Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-rainos. You're listening to not a podcast, a fun-cast with Chris--boing [honk]--and Dave--[gong, whirl] awooga.

Chris Coyier: [Laughter]

Dave: Hey, Chris.

Chris: Yeah.

Dave: What's going on?

Chris: It's good, man! Welcome to morning radio!

Dave: All right! All right! [Laughter] I need a new name like The Squanch.

[Laughter]

Dave: It's Chris and The Squanch [squirt]. [Laughter] Chris and The Squanch [squirt]. What's up, Chris?

Chris: Oh, god. That's only if we wanted to make money because reality TV, boy, it makes it.

Dave: Oh, buddy. Yeah. I mean we could do a Real Developers of Bend, Oregon. [Laughter]

Chris: Good thing we don't have to go around looking for drama because it's so easy to find in this industry, which is surprising, in a way, you know, the browser….

We just had Eric on last week and, I guess at the time, I was just like, whoa, we're just talking about browsers only to find it to be a little cat nippy for the people who, you know, think about….

Dave: We got some hot browser DMs.

Chris: Yep.

Dave: We are talking with people to get them on the show, so that'll all work out. I think the idea was, you know, Chrome was redoing the engine, the Layout NG, I think, and then Jen Simmons called it Layout Not Good [laughter] was what she heard it was called, which is funny. I think it actually stands for Next Gen, Layout Net Gen. It sounds like that work has been going on. I don't know if you saw that Grid broke recently. Did you get hit by the Grid bug in Chrome?

Chris: You know the only reason I'm aware of it is because I saw some people making demo pens demonstrating the issues.

Dave: Yeah.

[Laughter]

Dave: Well, and I've had Grid break on me like that before but, apparently, something else -- like it used to kind of force content but now it was like content; instead of min with zero or whatever or min-content, it was max-content or, sorry, auto or something was the value, which caught people by surprise. It caught me by surprise, too. A lot of my sites were like, "Oh, that used to work. Now it's weird."

Apparently, that has been fixed. I wonder if that was all connected to this Layout NG. I don't know but it seems like some big layout fixes are happening under the hood.

Chris: That happens on Web apps all the time. I hate to say it, but I push bugs on the regular to production.

Dave: Yeah.

Chris: But browsers tend not to, in my experience.

Dave: Yeah.

Chris: Once in a while, of course, but it's a little more rare for an actual browser to just straight up break something. Obviously, they have to take it a little more seriously because they're not supporting one website; they're supporting millions or billions of websites.

Dave: Yeah, and people were upset. But maybe that's the thing is that it was such a surprise. You don't encounter browser breaking bugs that often; it was such a surprise to people. I found that interesting.

Chrome 80 came out. That was part of Chrome 80, that bug. Chrome 80 came out and it has a bunch of stuff in it. I didn't realize what was going on, but it has a bunch of stuff. It has a contact picker API. I think we were talking about stuff like that.

Chris: Yeah. For the first time in a while, I actually did dig into what the releases were in Chrome 80 and they're good. I guess what struck me about the release was that, yeah, contact picker API. Interesting. I didn't really know that it was coming. I don't have any horse in that race, but I like it because I feel like the point of it is, make it easier for users to fill out forms.

Dave: Mm-hmm.

Chris: If there's a form that has an address in it, you might as well be able to pick a contact. That's way quicker. I do that anyway because I have one password, but that's a good example of something that should make its way into the browser if it's obvious that people are augmenting their browser to do that.

Dave: Mm-hmm.

Chris: I like it but I'm just like, "Uh, wow. Crazy." Then there's a bunch of JavaScript stuff that lands. There's some CSS stuff that lands. There's service worker-y kind of cache stuff that lands. There was something about their new way of handling feature flags, which aren't just like ways -- you enable it from some website, so you're officially enabling this flag with their attention. It's not something you flip on locally.

Dave: Yeah, it's like you're part of an origin trial.

Chris: Trial, yeah.

Dave: You register your website or whatever with some key and that unlocks the feature. Maybe that's part of, you don't have to get every single user to open up -- [Laughter]

Chris: Feature flag with tracking.

Dave: A feature, yeah. Yeah.

Chris: [Laughter] Right.

Dave: Feature flag with tracking.

Chris: It seems fine. It seems like good stuff has come from it already, maybe even that contact picker thing. Maybe that was one of the graduates from that program. I can't remember.

Dave: Yeah, it sounds like a lot of this Fugu stuff is in origin trial. There's another one where you have access to the file system directly. You can file a read but you can't really file write to that operating system. I think there's an origin trial thing right to the operating system.

Chris: The first thing that should go through any developer's mind is, like, "What?! No!" But then you look and you better hope that the first paragraph explainer of that thing is talking about security because what the heck, you know.

Dave: Right. I mean could you imagine? Just whatever.

Chris: Yeah.

Dave: [Laughter] Like you open up a website and it's like, "Great. CNN just added an icon to your homepage or your desktop."

Chris: No--

Dave: It'd be like a solid no. [Laughter]

Chris: Yeah, that or like I have some tax documents sitting on my desktop right now and I just kind of assume that they're safe.

Dave: Yeah. Search.

Chris: Especially from a website.

Dave: Search the entire hard drive for taxes. [Laughter]

Chris: I have a weird level of trust about that stuff, though. I would assume that any browser coming anywhere near touching some functionality like that has thought about it to the point where I'm not digging into explainers because I just assume they're going to do a good job with it. That's probably stupid of me, but that's kind of where my brain goes.

Dave: Well, yeah. That goes back to the trust of browser stuff, right? You just trust, inherently trust that they know what they're doing. I think Sam Richard, @snugug on Twitter, he's a Google Chrome OS dev rel, I think is his new job title. He had a demo of -- it's an origin trial, but where Markdown app could write to a Markdown file on your hard drive and stuff like that. You sort of see maybe take some of the stuff that Electron does and make it more native to the platform.

Chris: Hmm. Hmm.

Dave: You know what I mean?

Chris: Yeah.

Dave: (Indiscernible)

Chris: I feel like we're still in this. Doesn't it feel like the vibe of a lot of this stuff is still, like, the Web needs the capabilities that other things have because we're still scrappy on the Web, like we still need to win. The enemy is anything that isn't the Web, as a way to build an app, which I don't hate that. I think that's probably a good position for the Web to be in.

Dave: Yeah. I'm in the Web can be unique. We don't need to -- you know. You look at notifications. "Oh, god. We've got to have notifications. Apps have notifications." Then low and behold, 99% of all--

Chris: Right.

Dave: --users say, "No thank you," to notifications. Chrome just released a little UX, Chrome UX report that showed 41% of people just say no right out of the gate on mobile. Even more say it on desktop, or they'll just ignore it. I think that's the UX on mobile is you have to -- it's such a limited screen, you have to dismiss or interact. You can't just ignore that little badge that pops up. Yeah, I don't know. There's stuff coming like badging API, a little icon on your progressive Web app. The contact picker is out. The install related apps, which is kind of weird, but I imagine if you had the Microsoft Word progressive Web app, you might want to be like, "Hey, also install PowerPoint and Excel." Native file system API, what we talked about. The shape detection API, which I think is sort of like for cameras and optical -- like basically AI or whatever inside the cameras and stuff like that, face detection, et cetera. Face barcode, all that, so that could unlock point of sale software.

Content indexing, oh, that's like maybe when something -- when you save a file. This is actually in beta or origin trial, I think, too, or flag. You save your content like a webpage from my progressive Web app. There's maybe like a UI where it can show up later, like, "Oh, you save this file or this is already downloaded on your device." Yeah.

Chris: Oh, the metadata one? Yeah, I get it. I get it. I think it's like even on DaveRupert.com, if you were like, "I'm going to save these eight articles offline in case people want to read them," which I think is fine and interesting. But I don't know. That's always held up as the number one use case is a little like, eh, who cares. You know?

Dave: Mm-hmm.

Chris: Anyway, I think there was no API in the past to just get the title of those eight documents iso that you could build a UI that says, "Which one of these eight articles would you like to read?" I think you kind of needed to request the entire file to get it, which isn't particularly efficient.

Dave: Right. No, and this would give you a way to get a title and a reference to the content, not just the….

Chris: Seems smart.

Dave: Yeah, but there's a whole bunch. There's the website. Updates Web or Google -- developers.google.com/web/update/capabilities. I can post a link in the show notes but there's Web share and all that. Those are launched, but they need to be updated and all that.

Chris: There's some stuff that surprises me. It wasn't unclear about the release. They're like, "Oh, we have SVG icons now." I feel like if you ever have a sentence like that or SVG favicons, you know the thing that go in tabs, that sentence should always be accompanied by, "It's a one-liner," so show me how. Show me how you expect that to happen. Don't announce the feature.

Anywhere that sentence is said, it should be accompanied by the one line of code that shows me how to do it. I feel like I had to dig around a little bit to figure out the expectation of it. It wasn't unexpected. It's just rel="icon" or whatever it is. I can't remember.

I'm not looking at the exact code right now, but it's the same one that you would use if it was an ICO file or a PNG file. It's the same thing. It's just now it takes SVG2. I feel like it's notable different because the only other browser -- well, I think Firefox is supporting it in that same way but Safari supports it only with a different rel attribute. They only support this mask icon way of doing it.

Dave: Right, and that can only be monochrome. It can only have one color because the browser will fill that color.

Chris: Right, so it's more dark mode friendly and stuff.

Dave: Yeah, I guess, but that's the neat thing about SVG icons is you can do dark mode with them.

Chris: Yeah, internally.

Dave: You can, inside your SVG.

Chris: Right.

Dave: Yeah, you can program to a color swap-y thing. That's pretty dang cool. I don't know, like, you know -- I'm curious what people are going to do with it, but these are also kind of--

Chris: The opportunity is so clear. Whoever coded that feature, you think they'd be highly incentivized to pair the marketing of that feature with a little snippet of best practices.

Dave: Yeah.

Chris: Why is that not ever done? Not ever, but--

Dave: No. I'm searching and I just get whatever. I don't get any links for it. Yeah, nothing in the first 20.

Chris: If I coded that feature, you'd better believe I'd want to tell people how to get the most out of it.

Dave: Yeah.

Chris: That feels weird. We're getting bogged into this again. The next episode is episode 400 and we have some browser people on to talk browser, so maybe we should just wait for that one to talk. It's talk browsers about, like, more like just like what are you actually working on.

You know it's funny about this list that we've been going down through. There might be a few more things, so I don't mean to cut you off. If you have some more interesting ones to talk about. Let's do it.

First, the type of developers who care about these particular features, it's all over the map, which I think is kind of cool. Maybe not that much for CSS people this time. A little bit of, like, overflow wrap stuff that's a little over my head, even though I've attempted to dig into that in my past. Text wrapping is the most complicated thing in CSS, I feel like some days.

Nothing ever for HTML. That's kind of the joke at this point. If you read a browser release notes, there is not going to be anything about HTML in there - never.

Dave: Nope.

Chris: We're curious about that. That conversation is heating up a little bit, like, why not? I don't think browsers are ignoring it. It's just the story is more complex and lower. It's perhaps our lowest level language on the Web, so it makes sense that it evolves a little slower, perhaps.

Dave: Yeah. Jeremy Keith has a great talk out right now about building and he showed this in previous talks, but just the concentric circles of velocity. I forget what the name of them are, but HTML moves slow. Then you go out a circle. CSS moves a little bit faster. Then you go out to the final circle and JavaScript is just squiggly-wiggly. It moves so fast that keeping up with it is exhausting and you'll burn out, in my experience.

Chris: [Laughter] Well, we'll get some stuff. Things are speeding up to some degree.

There was some hot news yesterday, as I record, and you're probably listening to this about five days after the news about the likely compromise-ridden future of element queries or container queries.

Dave: Yeah!

Chris: Yeah.

Dave: Very exciting. Brian Kardell wrote on his blog kind of a proposal or a softball word prototype, we'll say, about putting select inside CSS, almost like calc works. It would be a value sort of thing. You'd have Grid, select, and then this new thing called available inline size or something like that.

Chris: Yeah. The actual function was switch, right? They're like guards in Rails or something.

Dave: I said select. I meant switch. Yeah, switch. Yeah, yeah.

Chris: It means it's like if this, then this value - if this. It's literally a switch statement in JavaScript, right?

Dave: Mm-hmm.

Chris: If this condition matches, then the value is this or if this condition matches, the value is this. Then there's even a default at the bottom, so it really quite literally is like a switch statement in JavaScript or any other language that has switch statements.

Dave: I thought that was very cool because the progressive enhancement story is kind of there. You just write out the default.

Chris: Yeah.

Dave: You could have Autoprefixer spit the default out for you or whatever. Then your switch statement comes after it and the browser is just going to ignore it. That's awesome.

I think this solves -- the example he had was Grid, template, columns. Then you change the columns based on the available inline size, which was awesome. I think that solves the card sort of like when you make a card or a UI table view kind of thing where there's a--

Chris: Right.

Dave: You drag it out and it goes into a card.

Chris: Ninety-five percent of what you're doing is Grid, template, columns, changes.

Dave: Yeah.

Chris: Was your pushback right away that--? But sometimes I'm changing eight properties.

Dave: Yeah, so that's the thing I want to know more about and maybe we can have Brian on to ask about that. The other example, basic example, is where you'd have a calendar and it's just a timeline, vertical timeline on mobile. Then you stretch out. Then, boom, it's like a month calendar. How do you do that with a bunch of switch statements? That, I feel like, would just get way too gnarly to have 40 properties that just switch.

Again, I don't want to -- just because it doesn't do what I want right now, I think I would love the switch statement even just for layouts because, again, this is not based on the viewport. This is based on the element. That's huge, right?

Chris: Yeah.

Dave: That's huge.

Chris: You know what I bet, though? I bet this is so hot. It's the hottest thing in CSS. People want it so bad. There are all kinds of different CSS preprocessing languages. We have all the classics like Sass, Stylus, and Less and stuff. There's no reason in any of those languages you couldn't write a mix in that basically did this. Certainly, Post CSS is up for the job.

Imagine just writing an element query, like a syntax that we've been talking about all along that looked a lot more like a media query and, in that block, you change eight properties in it. I think CSS preprocessing is capable of digesting that block and turning it all into switch statements for all those properties.

Dave: Go sprinkle it through. Okay.

Chris: Just sprinkle it through.

Dave: Yeah.

Chris: Then it will compress really cleanly. It'll be really repetitive, but that's okay in CSS because it's Gzipped anyway kind of thing.

Dave: Mm-hmm. Oh, good point.

Chris: That's okay. It feels nice that -- somehow, in my mind, I'm like, what's the difference? Why can't you write a media query that uses available inline size then? What about the syntax of putting it at the property level makes it fast? But I totally trust everybody in this conversation. I have no idea. I have no idea how CSS parsing works and how browsers do and such.

It's just that the agreed-upon thing was, if there's a container query, that really turns on its head the way browser rendering works in that it turns the one-pass job into a multiple pass job and stuff that I just don't understand but do believe. They're like, "Okay, that's just too hard. Okay." Then all of a sudden, this syntax comes along, solves a good chunk of the use cases and, for some reason, doesn't have that same problem. Great!

Dave: Yeah. Yeah.

Chris: This is just Brian's post on it. He also says, "Hey, there's David Baron over at Mozilla. He's working on a totally different idea but with the same vibe," like the vibe of doability instead of not doability. [Laughter]

Dave: Right. Right. Right.

Chris: Who knows because this is years away from happening at all, so don't look at Brian's post and be like, "Well, that's the new syntax. Get used to it." Some other thing could still win - or whatever.

Dave: Well, and I think that having -- I think Brian's proposal has value even if it's not the ultimate container query solution. It does have value. Having a switch statement in CSS seems pretty darn cool.

Chris: Yeah, it does.

Dave: I don't know. If color black or background black, make my text white, or something like that.

Chris: Wow. Yeah, right.

Dave: Think about that. I'm not saying -- there's a lot of potential there and I think it would be cool if we had that sort of stuff. That said, browsers are very concerned with any sort of cyclical style calculation because rendering, like to build up to a render frame is kind of expensive, especially if you're looking at these 120-hertz iPads or I just saw 360 monitor gaming display. [Laughter] These things are coming out and so, if the Web wants to trail the hardware, we're going to have to speed up our rendering. And so, how do we do that?

Chris: Hmm.

Dave: It'll be very curious how we'll do all of our layout calc.

Chris: Yeah. It's kind of incredible how fast when you think about what happens in the one second a website is rendering. It's reading an extraordinary amount of plain text code, interpreting all of it, and getting it rendered to an interactive screen super-fast.

Dave: Have you ever turned on the show "Paint" or "Style"? What is it called in Chrome?

Chris: Yeah. There's some kind of like it teaches you what it's doing.

Dave: Rendering. Yeah, let's see. You go into your Chrome dev tools and then there's the little thing, the little hamburger shish kabob or shish kabob menu. You go to more tools, right? Then you go to rendering, right? Then you do show, paint, flashing. Right?

Chris: Mm-hmm.

Dave: That shows you when something on your site got repainted. I was doing this for the ShopTalk site that we're working on and should be out very soon, hopefully. Fingers crossed. We have the podcast player in there and I was updating the time every second, like whenever it updates or I get an event that says it updates. It was interesting because I was like, how performant is this? It has to update the scroll bar and the number, the progress. It has to update that every second. I turned it on and I just was watching it. It was just like, okay, yeah, so it only affects these two things. It doesn't re-render the whole entire fricken' Web component every second. It'll just render the time, text, and the progress bar. That was pretty efficient, I thought. I mean as efficient as I can get, maybe.

Chris: Yeah. We're having more and more influence over that, too. There was a good Rachel Andrew article on Smashing Magazine about the contain property, which gives authoring control over what we're even allowing the browser to repaint.

Dave: Mm-hmm.

Chris: It's not just painting. It's other steps of that rendering process as well, it sounds like, and very interesting, very low-level control over stuff like that. It's kind of like, should I ever have to bother with this? Well, no, I don't think you always do. But if you are interested in eking out higher performance or having performance problems that the tools are starting to be available to handle that, which is rad.

Dave: Yeah. Yeah. No, I mean I just went through a whole redesign of my site. Man, there are so many things you can do just to squeak out a little performance or not use something and use something else instead. I flipped a whole bunch to Grid and I probably halved my CSS. There's a lot that you can do to squeeze out some performance.

Yeah. Now we're getting into, oh, you can control the paint of your thing or use all the Houdini stuff. I'm sure we'll learn about that at some point. Yeah.

[Banjo music starts]

Chris Enns: This episode is brought to you by An Event Apart. If you're a regular ShopTalk Show listener, I'm sure you're familiar with An Event Apart. Dave and Chris talk about it a lot. In case you're not, it's one of the premier Web design conferences for UX and front-end experts like you. You get three days of design, code, and content for interaction designers and developers packed with tips, techniques, and insights into the future from industry shakes and shapers. I think Dave is a shaper and Chris is a shaker.

Dave: I stayed up for about two hours figuring out how I'd fight an alligator in real life.

Chris: Ooh, that's genius.

Chris Enns: But you'll come away inspired and raring to return to work, either way. Their next event is in Washington, D.C., in April and then they head to Seattle in May, Boston in June, Minneapolis in August, Orlando in October, and San Francisco in December. ShopTalk Show's own Dave Rupert is going to be speaking at the event in Seattle, so definitely check that one out if you're going to be in the area.

An Event Apart event is a great opportunity to learn what's next. They don't just present what's happening now. They also look ahead to what's around the corner. You'll have an opportunity to learn from your peers. The attendees and speakers are dedicated professionals with experience and know-how from years in the field. You also get immediate takeaways. They emphasize to their speakers that while inspiration and insights for the future are great, what every talk needs to have is tips and techniques you can take back to your desk right now.

If you need some help convincing your boss or your team to go to An Event Apart event, they've got a whole page full of tips and tricks to get your team out there and ways to convince your boss to say yes to going. Check out AnEventApart.com for details, pricing, tickets, and all the full schedule and availability for each event that they've got coming up in 2020. Our thanks to An Event Apart for sponsoring this episode of ShopTalk Show.

[Banjo music stops]

Chris: Yeah, well, while we're on the news stuff, it's been interesting. It's kind of where I was going with the drama stuff. I'd say this is light on drama but Dave and I have both been involved recently. I think it started with--

Well, backstory. There's a thing called CSS3. Even the last time I saw Dave, we were in San Francisco, maybe. I remember being at a bar and we were standing around in a circle. We were trying to remember what CSS3 even was. It's been so long ago that you're like, "Oh, were gradients -- was gradients one of them?"

Dave: And child.

Chris: Yep.

Dave: WebKit, linear, gradient, WebKit transition, and WebKit animation. I think those were all CSS3.

Chris: Yeah. Even border-radius, maybe, and box-shadow. I don't know. It's been a while, so it was funny just because it's like, well, that was the hottest thing in the world not so long ago and now we're just like, "What was that again?"

Dave: Mm-hmm.

Chris: And kind of the party line for a long time after that was, "Don't assume that the existence of CSS3 means that they're intrinsically in CSS4." People tried to be pretty clear about that while it was happening and after it was happening. Lots of people really trying to explain there is no CSS4. It doesn't make sense anymore. This was a one-time deal where we bumped up the version of all these specs. It was a very concerted effort to do this.

The reason there's no CSS4 is because, on purpose, we were breaking apart the spec so that they could evolve independently without needing a CSS4. The independent evolution of specs was the point, in a way.

Now, all these years later, with some look-behind, we're like, "Wow. You know what was so successful in CSS? Calling it CSS3."

Dave: [Laughter] Yeah, it had a logo and everything.

Chris: Fricken' huge! It had a logo. Everybody knew what it was. HTML5 even arguably more successful because HTML5 kind of encompasses CSS3.

Dave: Oh, yeah.

Chris: Yeah.

Dave: H5BP, man. HTML5 Boiler Plate. Yeah, so 2011, Hixie said not HTML6. Hixie is/was -- Does Hixie maintain--?

Chris: He's still pretty involved. Yeah.

Dave: HTML still? Okay. I know they spun down what they do in HTML.

Chris: I don't know.

Dave: Hixie said there will be no future snap or there'll be no HTML6. We'll have snapshots--these things we kind of talked about, I think, a couple of weeks ago--but there'll be no HTML6. Then 2013, Tab Atkins kind of broke the news that there will be no CSS4 and sort of trailing HTML. We don't want to do that again, so to each their own. That was probably the best call at that point. It was causing a lot of--

Chris: This is like circa 2012, too. This is ancient history to a lot of you listening to this.

Dave: I would be curious when people got into the industry here, the average listener. This is pretty old stuff, seven, eight, nine years ago.

Chris: Sure, and that's the history of it. Just recently, there's been a, let's think about how good CSS3 was for the Web. It wasn't just a successful marketing effort and that people knew what its name was. It had farther-reaching implications than that. It had universities being like, well, we should update our curriculum for that because clearly, that's important.

Dave: Mm-hmm.

Chris: It had website owners being like, "Oh, maybe it's time to get on board with this new stuff." It had a lot of people making money: conferences, books, online courses. It had that going on, which was helping education. There was a lot of good that came out of it.

Why not just give it another shot again? There's been mostly, I'd say, enthusiasm for it. To some degree, it started with PPK's post that said, "Here, why don't we just do it?" It was a very open-ended post, like, "Let's just think about it. What're the possibilities of it?"

I wrote a response to it saying, like, "I don't know. Maybe. I'm interested in at least thinking about it and thinking about it just as a thought exercise alone, even if it doesn't go anywhere. What would we put in that bucket?" because the bucket is almost too big because it's been so long since CSS4 that you've kind of got to pick some stuff and exclude some stuff.

Dave: Mm-hmm.

Chris: Then there's, can we actually pull this off? Who is spearheading it? Is the working group people involved or are they not involved - whatever? Of course, they're involved. Yeah. If it's going to work, it's got to involve those people.

They already do this kind of snapshot thing. Now I feel like I'm rambling a little bit, but JavaScript does this already with their versions. I think everybody is aware of that, right?

Dave: Yep, they have an annual publication and they have stages of features too. This is where CSS and JavaScript are pretty different. There's stage one through four or something in ECMAScript. Stage four is like don't do, basically, right?

Chris: Mm-hmm.

Dave: Or is it the other way? It's basically like, this is fresh, green technology -- just an idea. Stage two, three -- I could be flipping the order here but stage three would be like there's an implementation; proceed at your own risk. Stage two is like getting close. Stage one is like it's probably safe to put in your projects. Stage zero is ready for candidacy. It goes into the spec and it rolls up into that year.

Every year, you have features graduating into existence. I feel like, man, it would be great. That seems like a successful model. I wish CSS and HTML had it so we could kind of say, like, "Okay, this feature would be super cool if it existed, like if it graduates." We could kind of see, almost like a Kanban board, of features. [Laughter] Like, "Oh, okay, so this one is almost out. It's ready to go."

Chris: Yeah. There's been some pushback on this too. When I posted, Louis Lazaris responded with, like, "No, this is not going to work and it's not necessary anyway because of the breaking out of the specs was the point," and stuff. He had some points in there.

There is now a thread on the working group's GitHub thing kicked off, I think, by Jen, but it feels like anybody who is anybody has chimed in on this thing. Mostly positive, I'd say, but a notable voice of dissent was Rachel Andrew herself saying, "I don't think this is the right move for it," too.

It's not -- drama is not the right word, but it's not like unanimous consensual that this is a good idea, but I'd say there's a lot more positivity than anti- and not of like, "Okay, if we all agree, then what?" I hate to make this about me, but that was my first take is, like, let's say we agree on what it is and what the name is. Then what? How do you get anybody to care? I'd almost start with that. [Laughter]

Dave: No, I mean it's worth -- I think Rachel's thoughts there is sort of like maybe it builds FOMO, sort of like, "Ugh. It updated again? I just was learning the old thing and it updated."

Chris: Yeah.

Dave: Which is totally valid. That's how I feel about JavaScript. j

Chris: Well, and Jen -- Ugh. Not to make this more dramatic, but almost a stronger point in that, let's say you want to learn. You're really on your own without some kind of checklist or some kind of guidance of, this is the bucket of things in which, once you learn it, kind of feel satisfied that you're up to date on this stuff. How would you have any idea if you're up to date on CSS stuff now? I run a CSS blog. My life's work is trying to understand CSS and I don't know what I would tell you. I don't know how I would give you a ribbon saying that you're kind of caught up on knowing about CSS.

It's a wild west out there. There's a lot to learn. It's very random. I feel like that, "I don't know. Just keep up," style of learning, as Jen kind of put it, is a valid kind of concern about learning CSS. You don't know. Whereas, CSS3 was like, "Here's the list. That's the stuff that's in here. If you know all that stuff, I'd say you're boned up on CSS3."

[Banjo music starts]

Chris: Hey! This episode is sponsored by WordPress.com, another new feature to tell you about of WordPress.com that's pretty cool that will appeal to people trying to make money online is your WordPress.com site can make you money. It can do that in a number of ways.

For one thing, you can enable ads on them and make money through advertising. You can have the e-commerce plan, which has WooCommerce baked into it and you can sell stuff. That's kind of rad, you know, if you have something to sell in the world.

Here's another thing you can do. This is the new one. You can do recurring payments as well. If you wanted to have a subscription or anything that you want to have your customers pay you monthly or yearly for, annually, you can do that now. That's pretty cool.

You need to use Stripe, so you can just sign up for a Stripe account. It's kind of the nicest payment gateway thing out there anyway. You might already have a stripe account. Whatever. Then you connect WordPress.com to Stripe. Then you're all set up to do this.

As you're creating content on your WordPress.com site--pages, posts, all that stuff--you have the Calypso editor in there, like the Gutenberg-esque thing where you're making blocks and stuff. One of the buttons will just be a recurring payment button. You can just say, "This button signs my customers up for a $12 a month subscription to my site." This is good.

This is a good way if you have something valuable to offer to get a consistent base of customers to build your business from. If you have ideas for that and don't feel like coding it from scratch and building it and all that, you can just WordPress.com, which is a nice fit because that's kind of what it's for anyway. It's for people that don't necessarily want to code up their own site but still have all the power of a big, awesome CMS that they don't have to worry about. Now the same thing. You have e-commerce that you don't have to worry about and get wired up yourself. It's a pretty cool feature. Check it out.

[Banjo music stops]

Dave: I do want to correct my statement that tc39.es process document, zero is the straw person, no implementation of any kind. One is proposal and that's where there are polyfills or demos. Two is the draft, which is experimental. Three is--

Chris: Oh, it was reverse of what you said.

Dave: The reverse. Three is a candidate. It's like spec-compliant. The i's and t's are crossed and dotted.

Chris: Right.

Dave: Then four is finished and that's shipping in a browser.

Chris: Okay.

Dave: Or shipping in -- I guess I don't know if they have--

Chris: Well, this was very relevant to what Rachel was saying, too, is that you can't -- just because the specs are in a certain spot doesn't represent necessarily the usability of something and you can't speak broadly about the usability of something because everybody's project has different browser support requirements. She's just being like, it doesn't paint a picture very kindly of how and when to start using these things because you might just be like, "Oh, well, it's in CSS4," or, "It's in CSS 2020, so I'm using it." I don't know. It steamrolls the idea of, like, "Okay, now exactly what browsers is this in? How does that map to my project and what our support targets are?"

Dave: Right. Just because it's got a green checkmark on it doesn't mean it's good for you or your business.

Chris: Right. The danger being, if you reach for something a little too new and it's not part of your browser support chart thing that you feel like you could be misled by somebody that really shouldn't be misleading you, the working group. You know?

Dave: Yeah, because you're like, "Oh, Subgrid has a green checkmark on CSS 2020. It's 2020. I'm going to use Subgrid."

Chris: Yeah. I was playing with it yesterday. I thought I had a pretty good case of where I thought Subgrid could be useful to me. You know. Slap me on the wrist if you want but I like and use Firefox sometimes but it's not my full-time browser. I was using it yesterday because I had a Subgrid thing I wanted to work on. Then eventually I was like, "You know what? I'm not going to do this yet."

The way I was using it didn't have a particularly nice fallback. Subgrid can have really nice fallbacks, but I was using it primarily to do one thing. I was like, "You know what? I'm not going to do it."

Dave: Yeah.

Chris: Because it's not in Chrome.

Dave: I had it on my site because I just moved my projects up next to my posts and stuff like that. I was like, "Oh, maybe those could be in the same grid or maybe I could display content … in the grid or something. I didn't do that but I was like, "Oh, maybe this would be a perfect thing for Subgrid," but I just ended up faking a grid and emulating the parts of the grid I was using, I guess. Yeah, it was one of those situations where, "Oh, man. If I had Subgrid everywhere, this would be super, super sweet." Ah, well.

Chris: Yep. We'll see if this goes anywhere. The thread is really heating up. As we're talking today, that thread is popping with people's opinions.

Dave: I'm on two standards threads right now. It is so much stuff, man, like 19 comments in one and 31 comments in another. That one is about declarative Shadow DOM.

Chris: Yeah.

Dave: Oh, boy. You know? [Laughter] Which is cool but oh, boy.

Chris: I know. You stepped in it because somebody was like, "Well, what about this? This would solve -- because Dave's been hot on HTML imports for, what, forever?

Dave: A thousand years.

Chris: This is kind of like a little -- you know it's a compromise-y step towards it, just like these container queries is a compromise. What a week in Web development, though. My gosh.

Dave: Yeah.

Chris: We're kind of getting everything we want in one week but with little handcuffs on it. But you know, still, we're getting it.

Dave: No, it's just like we got all the -- at least some server-side rendering story for Web components, which is the declarative Shadow DOM, a possibility of CSS4. Oh, my gosh. Then this. I don't know, man. I think we're getting close.

Then I can give a follow-up as the accordion and all the stuff that I want in HTML. I wrote a blog post in December and punched the Web standards' bees nest.

There's a group called Open UI. It's kind of spearheaded by the folks at Microsoft. It's sort of just like they're trying to collect information about design systems openly and see what is in all these components that all have different names and blah-blah-blah, so they're basically trying to catalog design systems in the open. If you maintain the design system, it might be cool to add yours to that.

The goal, I think, is to try to make a blueprint for what an accordion component could look like. Then once we have a blueprint, we can make tests or whatever. Those tests can either inform your design system or it can inform a spec. It can inform a Web component. It can inform a new element. There are a lot of possibility there if we have these blueprints. You could at least say, "Oh, this accordion from this random library, is it open Web compatible to that spec or that pseudo spec?" That would be awesome to know - stuff like that. Worth checking out.

I don't think it solves my issue. I still think we need an accordion…. [Laughter] Just put it -- I don't know.

Chris: Yeah.

Dave: Every site has them, but whatever. Maybe we're getting close.

Chris: It sounds like even that stuff, though, is kind of -- at least it's not being forgotten. It's being talked about, researched, thought about, and stuff.

Dave: Yeah.

Chris: In a way, there are at least baby steps towards every one of our desires for the Web - pretty incredible.

Dave: Yeah. No, I think the question that I left last year and kind of want to explore this year through this podcast and through my own writing and whatever is sort of like, what's the future of HTML and CSS? What's going on?

Chris: Yeah.

Dave: There's also stuff like, I have a tweet bookmarked here from Alex Russell that's just like, [laughter] "HTML is dead," basically. I'm misrepresenting it, but it's basically just like, "HTML, it's very hard to get any movement there because there's so much consensus and stuff like that that's required." I think Alex's exact quote is, "HTML may be a dead language because those who claim to love it can't imagine it being better," and that's only to say, like, I think his argument there is new proposals get, "Whoa! Whoa! Whoa! Whoa!" every time. I think that's a really sort of harsh position, but I think the nugget of truth there is, it's hard to make HTML stuff because it requires so much consensus.

Chris: Yeah. You know it's all complicated by the idea that -- this just feels hoity-toity to say, but programming paradigms kind of have shifted to some degree. There's a post today, which of course I'll defend because it's on CSS-Tricks. I published it from a guest, Mike Turley, that has possibly an inflammatory title, too: "Why JavaScript is Eating HTML," which seems like you're going to, you know, not -- that some kind of HTML people are going to immediately be like, "Ahh!!"

Dave: I hate clicked it. I hate clicked it.

Chris: Yeah.

Dave: [Laughter] I'll be honest. I hate clicked it.

Chris: You can hate click it.

Dave: Yeah.

Chris: But I think it kind of spells out a pretty fair situation starting with what HTML is good at and what CSS is good at and the kind of established historical patterns of how we use these technologies to build things, layering on technology, which feels pretty fair to me.

Then as he goes down, he's like, "Well, let's just do the to-do list thing or the grocery shopping list thing and think about how we keep those, the HTML concerns, CSS concerns, and JavaScript concerns, separately as we build this thing out," and builds out a pretty fair MVP of what a shopping list is like. Then gets to the point of, just think about how complex it all is. Because we, on purpose, broke it apart into those three languages, it adds a bunch of complication that is just kind of a different programming paradigm. If you approached it a different way and kind of smashed a little bit more of it into JavaScript that some of the complexity falls away and becomes a different style of programming that at least appeals to different types of people and could arguably be "simpler" and "easier to manage."

I don't know. It's stuff to think about. I published it because I'm not going to say, "I agree with every word here," but as someone who does use modern JavaScript frameworks fairly often for these reasons, I kind of buy it.

Dave: Yeah, you know, I had my rebuttal written before I'd finished the first paragraph--

Chris: [Laughter]

Dave: --on why this is wrong. No, I think it spells it out very nicely. It sort of exemplifies the trend in Web development since HTML5, like 2011 with backbone and these. I think we sort of started putting pieces of our UIs to make them dynamic, refresh, and fetching from JSON, and stuff like that. We started pulling piece and piece and piece. Then, eventually, you have so many pieces in both places, the HTML and the JavaScript, it just is like, "Well, I'm just going to not do the HTML part because I know I need the JavaScript part. It tipped the scales, you know, so I think it was a pretty good article, overall. I'll say that.

Chris: If you're in the -- I forget. HTML is less important to evolve, it might be half because you're like, "Well, it's hard to evolve because of standards, it's a low-level language, there's not a lot of support, and we get blocked right and left." Of course, the thing that everybody holds up is the Toast thing. We tried. We tried to do really good on Toast and we got machinegunned on that thing. By we, I mean Chrome, essentially.

That doesn't bode well for anybody else trying anything else. Are we just going to get machinegunned again? Why bother, you know? Which is maybe not fair, but--

Dave: No, I mean I think that's fair and I think that was probably a negative experience for a lot of Chrome developers. I apologize if I piled on. I did make some jokes but, really, I am very curious about this model where Web components are delivered natively.

I think that was for me too. It wasn't just like, "Here's a Web component." It was like, "Here's a Web component and we're putting it in the browser natively and it's shipping next week." You know? It was intent to implement, which is now called intent to prototype, which is a much better name. They were like, "It's going out in the next version of Chrome," and in some form or fashion behind a flag or origin trial or something.

I think that was a lot of things happening all at once. People, Standardistas, we'll call them, or -istos, sort of pumped the breaks and just were like, "Hey, this is a lot of action. It looks like you're just going to ship things in whatever Amp wants in Chrome," or whatever. "You're just going to start putting things in the browser like HTML. What if Mozilla doesn't want to do this?" There wasn't exactly a plan committed for what happens then. All this to say--

Chris: It's hard to follow, even if you're trying to follow it.

Dave: --I would love a redo. I would love a redo and I'd love each piece to be talked about or discussed or each piece sort of identified. I think they fixed the intent to prototype thing. Intent to prototype is a great way to say, "Hey, don't worry. We are going to put this in the browser, but it is just for looking at purposes only." I think that solves so many problems. I think we should look at this native … Web component.

Chris: That's what an origin trial is, isn't it? Let's make it one of those thingies.

Dave: Yeah.

Chris: But I mean that's Chrome only, so it'd be nicer if there was some Firefox version of that. But I guess that's on Firefox to do.

Dave: Well, yeah. Yeah, but I think that's where the second part is that standard system of Web components like a native library of Web components. How cool would that be? Also, if it's just written in JavaScript, all Mozilla has to do is steal that JavaScript file and then spit out or build a mechanism to import Web components. That's easier said than done but, in theory, it can be done.

Then step three would be, does the UX and all this stuff match? What should it be named? And stuff like that. I just wish that was -- I don't know. I wish that was sort of better. I wish we could have a redo on it, but I don't know that we're going to have a redo. It sounds like Chrome has a fixed mindset about this and they're very close to even attempting that again. It would be very cool if they tried it again, but who knows, so--

Chris: Well, don't browsers have a way of forcing each other to do things?

This one was surprising to me today. I was so excited and continue to be excited about the presence of a loading attribute for images and iFrames. I don't know. I think it may be just those two at first, but perhaps there are other elements.

Dave: Yeah.

Chris: Video, maybe? I don't know. That are loading lazy. You put loading lazy on it and it does fancy heuristics and stuff and doesn't load the dang image until you're scrolled enough close to it.

Now, there's a lot of nuance here. I'm going to skip all that. The point is it works! It's native! It's easy! It has huge impact on the performance of the Web. Huge fan. Clap-clap-clap. Way to be. I did not realize that it was just this week where it was accepted into the HTML spec at all.

Dave: Oh, really? [Laughter]

Chris: Let's imagine a world in which that it wasn't accepted or there were problems with it. They were going to change the name or something. It's shipped! It's in stable Chrome now. Everybody is doing it. There's a WordPress plugin for it.

I've been using it forever. Now, all of a sudden, I have -- isn't that -- I always thought, and I could be wrong in my thinking about this. That's really worrisome. That's just browsers going rogue and shipping stuff. The danger is that if everybody starts doing that, it happens while we have this really busted up Web where you have to do all kinds of different crap for all kinds of different browsers and the extreme of that is very bad for the Web. Isn't this that? Is this that?

Dave: Well, yeah. I'd want to say there is maybe a bit more consensus building on that.

Chris: Yeah.

Dave: You know and it wasn't out of nowhere, I guess I should say. Addie is money. He's been giving talks and I think it was very much raised in open channels and stuff like that.

Chris: Okay. Okay, so it's not that. I just want to be careful. I don't really get it all.

Dave: No, you make a good point. It wasn't in the spec and it's used. I think it's something like 18 million times or something. Did you see that report on lazy load usage?

Chris: Oh, it's darn popular?

Dave: It's 18x growth since it came out or something like that or 1800x growth. Let's see. Let's see. Loading lazy--

You can't Google anything that somebody tweeted because it's like -- [loud exhale] anyway. [Laughter] Anyway, you can't. There's no way to Google it.

Chris: It's popular. I got it.

Dave: It's like in massive production and I'm using it on my site. Man, because the beauty of it is, like, it's no penalty. With Jen Simmons kind of idea to provide an aspect ratio using the height and width, now we use height and width again. That's an update. [Laughter]

Chris: Incredible. Incredible. Soak that in. If you missed that, rewind, people. Put height and width attributes on your images. It also has similarly very powerful perceived performance loading benefits for nothing.

Dave: Yeah. It draws the box and then loading lazy is like, "Go get it whenever you determine, browser."

Chris: Yeah.

Dave: Don't actually -- please don't load it right now. It's so fast. It just can -- I like it as an author because I can kind of describe what images I think are critical and what images can just be, like, load whenever. For my website, it's like, oh, my logo and my little dude, my news hammer dude, that's critical. That has to show up first.

Chris: Mm-hmm.

Dave: I know those show up first. But the side projects, whatever.

Chris: Yeah.

Dave: Just whenever you got free time, load those in. [Laughter] But I'll draw the little box. I want there to be a little box there so the browser doesn't hiccup and barf and stuff like that. You can test that. You can draw, like, do image background CCC or something so you'll see gray boxes get filled in or something. I don't think you ship that in production every time, but that would be a good way for you to know something is going to fill in this box. Pretty cool.

Chris: It is. It is, indeed.

Dave: Pretty cool world.

Chris: We've managed to make this the browser show this year. We have to because this is a show about front-end development, so no apologies, I guess. That's the stuff that matters to our jobs in a big way.

Dave: Well, and I think it just is sort of like -- I think it's the time and I think it's sort like there are some good things coming up, especially this week. But then I think figuring out what's going to happen for HTML and CSS is good.

Then right after that, there's going to be a whole thing for JavaScript frameworks. I think Vue 3 is coming out. A few new paradigms in Vue 3, TypeScript-y sort of stuff. Then you've got React with Suspense or what. No, Suspense is there. It's not in main? I forget. But React has a whole bunch of stuff coming out or going in and being built. There's a lot of stuff going on, so interesting times.

Chris: It really is.

Dave: I think we'll wrap.

Chris: Yeah.

Dave: Yeah, it's a good time to be a Web developer, darn it. [Laughter] All right. We should wrap it up, then. Thank you, dear listener, for listening to this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you, just like this company.

Chris: Hey, ShopTalk Show folks. There are always jobs available for you to check out at the ShopTalk Show job board just at our website /jobs. You know the link to it in the header, of course. Here's a special one I want to tell you about, though.

They're looking for a senior front-end developer at Scorpion. It's an Internet marketing and design company in Santa Clarita, California, which is an absolutely beautiful place kind of northwest of Los Angeles. Here are some quick facts about it, just because I happen to be looking at it. Santa Clarita is a California city north of Los Angeles, known for Six Flags Magic Mountain theme park. What else does it say? The prehistoric stone formations of Vasquez Rocks Natural Area Park have served as a backdrop for many films. I love that. the pictures of it are gorgeous here.

Don't you want to live in California and be a senior front-end developer at Scorpion? It sounds like a nice life, doesn't it? They're looking for -- you know, it's a senior job so, you know, four-plus years of JavaScript. They mention React and JSX. They also mention, in italic here, "Must be proficient in programming with Angular 2," so bone up on your Angular 2 stuff out there. Maybe you already know it. Apply for this job. Change your life. It could be good.

You know you're going to roll into a marketing agency kind of thing. You're going to be working on a team, working with project managers, product designers, and fellow engineers. You're making cool stuff for users. You should be organized. You should have an adaptable workflow. You should be detail-oriented, all that kind of stuff.

They're saying if you want some extra checkmarks on the application here, Jasmine is a good one to know, testing of course. It looks like they mention testing a couple of times here. They must take that seriously. The Ionic framework is a plus, you know that big deal framework that kind of makes app works on multiple platforms, which is pretty cool.

They even list the salary stuff. It's $130,000 to $180,000, so a pretty solid, yearly pay there. Pretty good, if you ask me. Of course, it's loaded with benefits and all that stuff. Again, it's Scorpion. They're looking for a senior front-end developer in Santa Clarita, California.

Dave: Chris, do you got anything else you'd like to say?

Chris: [Long inhale breath] ShopTalkShow.com.