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

Thank you!

Roger that! I'll be adding examples to the README. The main enhancement right now is running the article through Readability, the others are just trying to fetch the best-quality image, and removing some things from Wikipedia articles — so, more of a placeholder for future enhancements :)

You're totally right. I will add some examples to the README so it's clearer what it does (passing the article through Readability, et cetera)

You're right, the default page size (A5) and font size are things that need to be easily customizable. I resisted adding many options to the CLI, but I think this is a good way to solve it? https://github.com/danburzo/percollate/issues/27

I’ve been sporadically working on this over the last couple of weeks, and I think it’s now stable enough to get other people’s feedback on it. I got the idea while perusing Simon Wardley’s mapping book-in-progress (https://medium.com/wardleymaps), and I wondered whether I can bundle all the chapters into a decent-looking PDF. (It works pretty well for that purpose). I also wanted it to be a sample app for gluing things together for the purpose of producing books in the browser.

I’d love it if you gave it a spin; please let me know if you find anything nasty!

I may be wrong, but I think up to GDPR compliance, you'd only get a meager HTML file that was not machine-readable, and some (but not all) of the images?

I quit Facebook before GDPR came into effect, so it's heartening to see FB now has better export tools. At the beginning of the year I had to write my own: https://github.com/danburzo/fb-export

A little vacation experiment based on Ben Fry's project "All Streets":

http://3rdfloor.fathom.info/products/all-streets

I tried my hand at drawing every street in the OpenStreetMap dataset for Romania using Node.js for data processing and SVG for drawing the map. I'm pretty happy with the results, and with a bit of optimization I was able to draw similar maps larger datasets like France or Germany.

The code is also on Github: https://github.com/danburzo/every-street