The end of responsive images - Piccalilli
Hallelujah! Support for sizes="auto" is finally landing in Firefox and Safari! Praise be!
Hallelujah! Support for sizes="auto" is finally landing in Firefox and Safari! Praise be!
I don’t normally link to articles on Medium—I respect you too much—and I do wish this were written on Mike Hall’s own site, but this is just too good not to share.
And don’t dismiss this as a nostalgiac case study from the past:
At no point did the constraints make the product feel compromised. Users on modern devices got a smooth experience and instant feedback, while those on older devices got fast, reliable functionality. Users on feature phones got the same core experience without the bells and whistles.
The constraints forced us to solve problems in ways we wouldn’t have considered otherwise. Without those constraints, we could have just thrown bytes at the problem, but with them every feature had to justify itself. Core functionality had to work everywhere, and without JavaScript crutches proper markup became essential.
This experience changed how I approach design problems. Constraints aren’t a straitjacket, keeping us from doing our best work; they are the foundation that makes innovation possible. When you have to work within severe limitations, you find elegant solutions that scale beyond those limitations.
This is a wonderfully in-depth interactive explainer on touch target sizes, with plenty of examples.
Huh! I did not know this. Good to know!
Remember when I wrote about sizes="auto"? Well, it’s coming to Chrome! Hallelujah!
Some lovely scroll-driven animations illustrate this great little microsite.
There’s something very pleasy about the chunky design that harkens back to the Zeldmanesque early web.
This is a terrific walkthrough from Andy showing how smart fundamentals in your CSS can give you a beautiful readable document without much work.
Container queries can’t be used in the sizes attribute for responsive images. Here, Jason breaks down why that is (spoiler: it’s the lookahead pre-parser) and segues into a truly long term solution: a “magical” image format.
If you’ve ever thought it felt weird to put media conditions inside the HTML for responsive images, this will resonate.
Reminder:
emandremwork with the user’s font size;pxcompletely overrides it.
Prompted by Utopia, Piper shares her methodology for fluid type in Sass.
Removing
mediasupport from HTML video was a mistake.
Damn right! It was basically Hixie throwing a strop, trying to sabotage responsive images. Considering how hard it is usually to remove a shipped feature from browsers, it’s bizarre that a good working feature was pulled out of production.
Find out how much smaller your JavaScript could be.
There’s no browser support yet but that doesn’t mean we can’t start adding prefers-reduced-data to our media queries today. I like the idea of switching between web fonts and system fonts.
Did you know there’s an imagesrcset attribute you can put on link rel="preload" as="image" (along with an imagesizes attribute)?
I didn’t. (Until Amber pointed this out.)
Chris has put together one of his indispensable deep dives, this time into responsive images. I can see myself referring back to this when I need to be reminded of the syntax of srcset and sizes.
A nice succint explanation of using the srcset and sizes attributes on the img element—remember, you probably don’t need picture and source elements if your use case is swapping out different sized versions of the same image.
One caveat thought: you do need to know the dimensions of the images. If you’re dealing with unknown or user-generated photos, that can be an issue.
How and when did I get to the point where I would consider a page weight of 4 MB on a large page and 500 KB on a small page normal?
This isn’t just a well-earned rant from Manuel. I mean, it *is that, but it’s also packed with practical performance advice.
Celestial objects ordered by size, covering a scale from one astronaut to the observable universe.
Here’s a nice little test for the file size of your web pages—could they fit on a floppy disk?
The Session fits comfortably and adactio.com just about scrapes by.
It’s time for a look at the state of the web when it comes to JavaScript usage. Here’s the report powered by data from HTTP Archive:
JavaScript is the most costly resource we send to browsers; having to be downloaded, parsed, compiled, and finally executed. Although browsers have significantly decreased the time it takes to parse and compile scripts, download and execution have become the most expensive stages when JavaScript is processed by a web page.
Sending smaller JavaScript bundles to the browser is the best way to reduce download times, and in turn improve page performance. But how much JavaScript do we really use?
When it comes to frameworks and UI libraries, there are some interesting numbers. Given the volume of chatter in the dev world, you’d be forgiven for thinking that React is used on the majority of websites today. The real number? 4.6% of websites. That’s less than the number of websites using CSS custom properties.
This is reminding me of what I wrote about dev perception.