danburzo

Keep in mind this shows the “live most polluted major city ranking, 11:00–12:00” (EEST time), so rather short-term measurements.

Thanks! I’ve updated the introduction with some ‘now vs then’ pointers.

Updated the article with some information on the `Vary` and `No-Vary-Search` headers. I’ve left out the details of how revalidation works with `Vary` since I haven’t been able to reconcile yet what the spec seems to encourage vs what the tests on cache-tests.fyi suggest is conformant behavior.

As many have pointed out here, the nature of caching has changed in the current climate of ubiquitous HTTPS, and I want to add a paragraph or two about it. Is there a good summary somewhere that I could reference? What are the the usual, most prevalent uses of HTTP intermediaries involving caches, besides CDNs and origin-controlled caches (eg Varnish)?

Good call! Honestly I just wanted to wrap it up before the holidays, but you’re right that a small section on Vary would have been useful.

Things like non-conforming caching services made me punt actual suggestions to a later article, as I wasn’t sure how my sense of the RFC interacted with the real world. HTTP Caching Tests seems like a great resource for this, but only includes Fastly out of the big providers, and it seems to be doing okay with Vary. https://cache-tests.fyi/

I’m sorry you didn’t get anything out of it. I wasn’t operating at the edge of caching knowledge, just a person refreshing and clarifying for themselves how caching works. Some things were new to me, and after spending so much time with the RFC, I just thought others may benefit or, more selfishly, would point out errors or ways to make it better.

I mean, do those <meta> tags really suggest someone who’s into SEO? Call me stale but what I really want is validation :-)

You could probably just ask Sasha Shor:

“As one of the creative leads on the id software brand team at Pyro in Texas, I worked on the logo, font, packaging and advertising, as well as the global E3 launches, for Quake, Quake 2, 3 and 4, some of the most iconic video game launches in the history of gaming.” http://www.sashashor.com/new-page

This is exactly my jam!

May I suggest adding a distinct style for visited links, so it’s easier to keep track?

With the goal of showing nice, clear images to as many devices as possible, while optimizing the file size, I would:

1. decide if I want to use any of the newer image formats. If so, each needs its own `<source type=''>` in a `<picture>` element, front-loading the most efficient formats. 2. decide if I want to serve different densities for the image.

For specifying densities, width descriptors + `sizes` attribute will always compute to a more useful effective density than density descriptors, if you can get `sizes` in the ballpark of how the image is actually laid out.

For lazily-loaded images, `sizes=auto` will do that for you, when it becomes universally supported.

Thank you for the kind words! I have fun reading specs, but the HTML Standard is denser and organized more… cross-referentially than the average CSS spec, so there was a bit of putting-things-together.

Thank you for the kind words!

I haven’t explicitly mentioned it in the article, but `srcset` + `sizes` is a way to provide dynamic densities for one image format, then multiply that with one `<source>` for each image format:

    <picture>
      <source srcset='…' sizes='…' type='image/avif'>
      <source srcset='…' sizes='…' type='image/webp'>
      <img srcset='…' sizes='…'>
    </picture>

If this is what you mean, maybe it would be better to include in the article?

Oh yeah, definitely something I’ve witnessed and been frustrated by before. Some of it stems from improper use of CSS units [1], and the only real recommendation I have is for people to _test_ for basic things like zooming in and out of the page, while keeping close in mind _the reasons_ people might want to zoom in and out of the page.

[1] https://ashleemboyer.com/blog/why-you-should-use-px-units-fo...

Yes, a smart server (that does more than serve static image assets) can do the heavy lifting and alleviate some of the HTML markup complexity.

It has the `Accept` header as a guide to what image formats the client supports, and with Responsive Image Client Hints[1], it can opt into more info from the client (device pixel ratio, image layout width, viewport width).

Without relying on server features, `<picture>` with `<source type='…'>` is the way to serve images in newer formats without breaking in less capable browsers.

It’s interesting that `image-set()`, the CSS sort-of counterpart to `<picture>`, bakes in the media type along with the resolution in a single syntax [2]. Which you could potentially see happening in `srcset`, but it makes the descriptive/prescriptive boundary a bit blurry, so it would complicate things IMO.

[1]: https://wicg.github.io/responsive-image-client-hints/ [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image...

I haven’t followed Client Hints closely, but a change[1] in RFC 9842 internal drafts “removed specific features to be defined in other specifications”, and the `DPR` header ended up as `Sec-CH-DPR` in the nascent Responsive Images Client Hints spec[2].

[1] https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cli... [2] https://wicg.github.io/responsive-image-client-hints/#sec-ch...

Thank you! I must have picked up the idea from from Matthew Butterick’s “Practical Typography”, but with the symbol drawn rather than as the degrees character, to spare screen reader users from hearing that constantly.

https://practicaltypography.com/

I’ve recently re-started work on this library after a half-year hiatus — fixing a few bugs and adding more extensive documentation. I’m quite happy with most of the features, but I’m not convinced it’s ready for the first stable release. I have some concerns that the interpolation section is a bit overwrought, but I haven’t found a better way to combine the interpolation method (linear, basis spline, natural spline etc.) and how to interpret values (simple numeric values vs. hues vs. alpha values).

In either case, I’d love if you gave it a spin and let me know your thoughts on the functionality, API, and how the docs read in general. Another pair of eyes would be very helpful at this point!

Implemented in the latest version :)

I think they're already looking into something similar, either through Electron, or their own wrapper over Chromium. I understand from skimming the resources your linked to that they had reliability issues with Electron, and I can confirm from a separate project that Electron and Puppeteer can become a little slow / unwieldy for a large-scale project. So I'm not sure :/

very very cool! thanks for the pointer.

As @cronopios mentions, if you need a bit of flexibility in the output, you need to use a wrapper over Chromium — either Electron, or (the more recent) Puppeteer.

Other than that, it runs the article through Readability to extract just the main content and applies customizable CSS / HTML to it.

Hah, yes :) It's more that I haven't figured out what the HTML version should look like, and whether it should be self-contained (images, styles), how to handle web fonts, et cetera