> The site design and content are great; the execution, not so much.
As I mentioned, I think it would be helpful to link an example (even just one) of a website you think is executed correctly and does similar things but much better.
> the multiple CSS files creates a total blocking time [1] of 5266 ms according to WebPageTest...The page is blocked from rendering for over 5 seconds due to all of the crap he's downloading and the way he's doing it.
I don't think that is what total blocking time means... You can see that just loading the page, or looking at the Pagespeed strips. To quote your own reference: "The Total Blocking Time (TBT) metric measures the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness." It is not blocked 'from rendering for over 5 seconds'. I would agree that not rendering for 5 seconds would be a bad thing. But it is not what that number means, because it is defined as after first rendering, and about something else entirely (user input).
> He has dozens and dozens of media queries; how about let's not download the crap I don't need on mobile? If I'm on smartphone, I don't want the drop caps and the other flourishes that only make sense on desktop/laptop sized displays.
Uh, no? There are reasons that user-agent sniffing is highly deprecated. Because if you snoop the user-agent (I'm not sure how else you propose that that crap not be downloaded), that is crack and aids, and extremely bad and fragile: even if you somehow mapped all user-agents to date to their full sets of undocumented unstandardized media-query equivalents, it will break with the next user-agent or browser decision to spoof user-agents for privacy etc and stop exactly this sort of snooping... It also means that you've broken responsiveness: if the user resizes the page, now everything breaks because they don't have the newly-matching media-queries.
This also underrates the difficulty of getting mobile/smartphone right. We have had problem after problem with iPads and iPhones, and that's with using media-queries which are supposedly supported & standardized; some sort of server snooping would be even worse. (Leaving aside the issue that it would be hard to implement this to begin with on a static website.)
> Ironically, after all that, he didn't pick a font that supported true small caps; he's using synthetic small caps, which don't look as good. There are plenty of high-quality free fonts with true small caps. It doesn't make sense.
Huh? We do use a high-quality free font with true smallcaps, Source Serif Pro and Sans. That in fact was a major reason we picked the Source family: because Frank did true smallcaps for it.
I am also not sure we actually need the new variable fonts for Sans, since we don't use much Sans.
> Like the fake small caps, the typography doesn't look great on a smaller, high resolution screen.
How so? I'm wondering if you broke the site with a plugin or something, if you think we are using 'fake smallcaps' and that it looks bad on high resolution screens...
> The experience isn't good on mobile; it's not cool to have those previews keep popping up that I didn't ask for
Obviously, I very strongly disagree that the previews are useless for reading my site, and I'm puzzled by the idea that there are people who are tapping away at links on smartphones and want them to open up the full link when smartphones barely even support tabbed browsing, but are frustrated by seeing excerpts or summaries instead and getting access to cleaned compressed archived snapshots etc.
However, for those who dislike them, they can be disabled by a single tap of the only icon attached to a preview (besides the 'X' to close it), the struck-eye icon, which is widely understood to indicate hiding/disabling things.
> and that icon bar is inappropriate for small screens.
I'm not sure what you mean by 'icon bar'. If you mean the theme toggle in the right-hand corner, which provides controls like 'disable previews', then it is not inappropriate; we started with a smaller toggle bar, but I and other users found that anything smaller is hard to interact with because the tap targets are too small.
> Among other things, it's so specific, making it very fragile; it also explains why his CSS is so bloated because there are hundreds of lines just like this.
Sometimes you need to be specific. You don't establish that that CSS is unnecessary to achieve the goal. (This is where a comparable site would be especially helpful in critique.)
> As you can see from the Lighthouse report, he doesn't bother to minify his CSS or JavaScript.
Whatever Pagespeed or Lighthouse might say, we haven't found minification to be a big benefit when we turn it on. And we have found it to make debugging harder and also sometimes break the site. (Cloudflare choked on, IIRC, inlined SVG at one point, completely breaking the site. That was fun to figure out.)
> Whatever Pagespeed or Lighthouse might say, we haven't found minification to be a big benefit when we turn it on.
Minify CSS Potential savings of 20 KiB
Minify JavaScript Potential savings of 82 KiB
The benefit is less data going over the wire. I get it--100 KiB doesn't sound like much these days, especially given the page weight of almost 800 KiB. But it's still an extra 100 KiB that doesn't need to be transferred and it adds up over time.
If you minimized your code and did a few more optimizations, you're talking about a more significant amount of data you could be saving your viewers.
> Sometimes you need to be specific. You don't establish that that CSS is unnecessary to achieve the goal.
That selector and the many others like it is a sign of poor CSS architecture. If your design results in you having to be that specific, it means you're doing something wrong.
It's a classic case of fighting the cascade instead of having it work for you. If there was an architecture (like ITCSS or OOCSS for example) [1], you wouldn't need to write such a deeply nested selector in the first place and the dozens more just like it.
Creating reusable components in CSS would reduce the amount of code dramatically and make it much easier to maintain.
> The benefit is less data going over the wire. I get it--100 KiB doesn't sound like much these days, especially given the page weight of almost 800 KiB. But it's still an extra 100 KiB that doesn't need to be transferred and it adds up over time.
How much does that save, after the Brotli compression, and how much does it contribute to your supposed TTB? And why would it affect the page performance once loaded? And how does your alternate of CSS grids change that? If it is responsive, it is still going to have to define a bunch of CSS to explain what the layout is and how it changes.
> If your design results in you having to be that specific, it means you're doing something wrong.
Does it really? You keep making these assertions like 'you're using fake smallcaps' and then not backing them or explaining them, or giving any examples whatsoever of a site doing it right.
> Uh, no? There are reasons that user-agent sniffing is highly deprecated.
I never mentioned user-agent sniffing nor would I ever recommend this outdated technique.
Using media queries for responsive design became a thing in 2010 with Ethan Marcotte's seminal article "Responsive Web Design" [1].
In the intervening 14 years, we have much better ways of adapting to different screen sizes. In fact, using CSS Grid for layout as it was intended results in responsive layouts without media queries and breakpoints.
Watch Jen Simmons' videos on intrinsic design [2] for the full run-down.
This seems to be a bait-and-switch argument. I can't see how any grid feature can handle all of the media-query things you highlighted as wasteful bloat like "the drop caps and the other flourishes". How does that handle dropcaps, sidenotes & margin-notes, popups vs popovers, utility classes like disabling on mobile vs desktop, the different styling of the header, plus all of the small adjusts like fonts or line-heights or justification...?
Nothing in your first link addresses that, and this grid approach sounds limited to just moving a few blocks around to be a rectangle instead of a square or something. (Like, I am looking at random moments in these 5 hours of videos, and it all seems to be like that, like "What do CSS features like CSS Grid, Flexbox, Multicolumn, Flow layout and Writing Modes mean for our design medium"? Well, for Gwern.net - they mean little. Most of the media queries have nothing to do with putting something into various kinds of grids...)
How is this is a general replacement for media-queries - as opposed to a minor technique good for rearranging some carousels or some columns?
Again, I think you would benefit from being specific. How, exactly, does CSS Grid free us from media queries and breakpoints for the things we use media queries & breakpoints for, like dropcaps or switching between popups & popovers? And what is an example of a site which uses just CSS Grid for all this and avoids downloading all that crap as you desire?
As I mentioned, I think it would be helpful to link an example (even just one) of a website you think is executed correctly and does similar things but much better.
> the multiple CSS files creates a total blocking time [1] of 5266 ms according to WebPageTest...The page is blocked from rendering for over 5 seconds due to all of the crap he's downloading and the way he's doing it.
I don't think that is what total blocking time means... You can see that just loading the page, or looking at the Pagespeed strips. To quote your own reference: "The Total Blocking Time (TBT) metric measures the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness." It is not blocked 'from rendering for over 5 seconds'. I would agree that not rendering for 5 seconds would be a bad thing. But it is not what that number means, because it is defined as after first rendering, and about something else entirely (user input).
> He has dozens and dozens of media queries; how about let's not download the crap I don't need on mobile? If I'm on smartphone, I don't want the drop caps and the other flourishes that only make sense on desktop/laptop sized displays.
Uh, no? There are reasons that user-agent sniffing is highly deprecated. Because if you snoop the user-agent (I'm not sure how else you propose that that crap not be downloaded), that is crack and aids, and extremely bad and fragile: even if you somehow mapped all user-agents to date to their full sets of undocumented unstandardized media-query equivalents, it will break with the next user-agent or browser decision to spoof user-agents for privacy etc and stop exactly this sort of snooping... It also means that you've broken responsiveness: if the user resizes the page, now everything breaks because they don't have the newly-matching media-queries.
This also underrates the difficulty of getting mobile/smartphone right. We have had problem after problem with iPads and iPhones, and that's with using media-queries which are supposedly supported & standardized; some sort of server snooping would be even worse. (Leaving aside the issue that it would be hard to implement this to begin with on a static website.)
> Ironically, after all that, he didn't pick a font that supported true small caps; he's using synthetic small caps, which don't look as good. There are plenty of high-quality free fonts with true small caps. It doesn't make sense.
Huh? We do use a high-quality free font with true smallcaps, Source Serif Pro and Sans. That in fact was a major reason we picked the Source family: because Frank did true smallcaps for it.
I am also not sure we actually need the new variable fonts for Sans, since we don't use much Sans.
> Like the fake small caps, the typography doesn't look great on a smaller, high resolution screen.
How so? I'm wondering if you broke the site with a plugin or something, if you think we are using 'fake smallcaps' and that it looks bad on high resolution screens...
> The experience isn't good on mobile; it's not cool to have those previews keep popping up that I didn't ask for
Obviously, I very strongly disagree that the previews are useless for reading my site, and I'm puzzled by the idea that there are people who are tapping away at links on smartphones and want them to open up the full link when smartphones barely even support tabbed browsing, but are frustrated by seeing excerpts or summaries instead and getting access to cleaned compressed archived snapshots etc.
However, for those who dislike them, they can be disabled by a single tap of the only icon attached to a preview (besides the 'X' to close it), the struck-eye icon, which is widely understood to indicate hiding/disabling things.
> and that icon bar is inappropriate for small screens.
I'm not sure what you mean by 'icon bar'. If you mean the theme toggle in the right-hand corner, which provides controls like 'disable previews', then it is not inappropriate; we started with a smaller toggle bar, but I and other users found that anything smaller is hard to interact with because the tap targets are too small.
> Among other things, it's so specific, making it very fragile; it also explains why his CSS is so bloated because there are hundreds of lines just like this.
Sometimes you need to be specific. You don't establish that that CSS is unnecessary to achieve the goal. (This is where a comparable site would be especially helpful in critique.)
> As you can see from the Lighthouse report, he doesn't bother to minify his CSS or JavaScript.
Whatever Pagespeed or Lighthouse might say, we haven't found minification to be a big benefit when we turn it on. And we have found it to make debugging harder and also sometimes break the site. (Cloudflare choked on, IIRC, inlined SVG at one point, completely breaking the site. That was fun to figure out.)