This is a cute and cool dive into taking backwards compatibility to absurd extremes. There’s one bit I might take overly-serious issue with (I hope the author will take this as non-serious criticism and an amused engagement with the thought process):
> That said, browsers that predate CSS do not know what to do with <style> tags, and as a result simply print the styles out at the top of the page. It's pretty ugly and, depending on how much CSS you have, borderline unusable.
> […]
> Forgotten Link Tags
I know external vs inline CSS is pretty much never going to be an answered question, but I feel like there’s a missed opportunity here. In particular because
- External CSS by link element addresses this much better for the backwards-compatible extremes: why even serve the contents of the CSS at all if the browser will just treat it as a comment? That’s just precious bandwidth wasted.
- Taken to extremes, external CSS relaxes the use CSS sparingly principle if you strategically break up the link tags to align well with likelihood of support/value ratio. Using media attributes to split CSS payloads can improve UX for old/underpowered mobile devices and even desktops/laptops with lower resolution screens. Detecting support for (ahem) @supports can open all kinds of CSS minimization doors for newer but lower power devices. Segmenting stylesheets by capabilities and preferences allows compatibility improvements regardless of point in time!
And a minor nit: if you’re dithering images for file size it’s worth comparing against a non-dithered version with a small color palette. The latter might actually be better for everyone!
Oof and that prompted a larger one: you can improve UX for ~every real visitor with <picture> tag and more efficient formats, and you could also sorta skirt the no-JS rule and upgrade pre-picture browsers to PNG with a simple inline onerror.
> That said, browsers that predate CSS do not know what to do with <style> tags, and as a result simply print the styles out at the top of the page. It's pretty ugly and, depending on how much CSS you have, borderline unusable.
> […]
> Forgotten Link Tags
I know external vs inline CSS is pretty much never going to be an answered question, but I feel like there’s a missed opportunity here. In particular because
- External CSS by link element addresses this much better for the backwards-compatible extremes: why even serve the contents of the CSS at all if the browser will just treat it as a comment? That’s just precious bandwidth wasted.
- Taken to extremes, external CSS relaxes the use CSS sparingly principle if you strategically break up the link tags to align well with likelihood of support/value ratio. Using media attributes to split CSS payloads can improve UX for old/underpowered mobile devices and even desktops/laptops with lower resolution screens. Detecting support for (ahem) @supports can open all kinds of CSS minimization doors for newer but lower power devices. Segmenting stylesheets by capabilities and preferences allows compatibility improvements regardless of point in time!
And a minor nit: if you’re dithering images for file size it’s worth comparing against a non-dithered version with a small color palette. The latter might actually be better for everyone!
Oof and that prompted a larger one: you can improve UX for ~every real visitor with <picture> tag and more efficient formats, and you could also sorta skirt the no-JS rule and upgrade pre-picture browsers to PNG with a simple inline onerror.