I’ve spent a lot of time thinking about the rules of putting images on the web.
For such a flexible medium as the web, software development can feel like a painstaking, rules-oriented game—an errant comma might break a build, a missing semicolon might wipe out an entire page. For a long time, the laws of image rendering seemed similarly cut-and-dry: For example, if your markups contained an img element , the singular content of its src attribute would be foisted on the audience regardless of their browsing context, period.
Likewise, I’ve been mulling long and hard over the seemingly carved-in-stone rules of the web standards-process. I had to, thanks to my role as chairman of the Responsive Issues Community Group, the private radio web-standards body that brought you the picture element and srcset and sizes attributes. After all, we had to know all the rules to, well, find creative ways to work around bureaucratic constraints. For one thing, we weren’t allowed to publish a spec in the first place. We certainly weren’t allowed to change the HTML spec itself though we ended up doing that nonetheless.
We were, I’m proud to say, a chaotic good web-standards group.
A chaotic good character does what is necessary to bring about change for the better, disdains bureaucratic organizations that get in the way of social improvement, and places a high value on personal freedom, not only for oneself, but for others as well. — Alignment (Dungeons & Dragons), Wikipedia
The short version is that there’s the law—the process, the paperwork, the rules, the way we’re supposed to do things—and then there’s doing the right thing. In cases where the two align, all’s well with the world. If the law comes at the expense of doing the right thing, however, a chaotic good character or, say, a chaotic good web-standards group, would unhesitatingly deviate from the letter of the law.
We felt justified in this philosophy, considering “the closest thing web standards have to a golden rule”:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
- “Theoretical purity” at the bottom of the list is a warning against weighing what looks the most correct on paper over the realities of the way people build and experience the web.
- Specifiers are those who are responsible for writing the standards.
- Implementors are browser vendors who create the standards for use.
- Authors are you and me—the web developers who decide how and when to use the new standards.
- Users is a self-explanatory term: They’re the people who, for better or worse, must, day after day, live with the results of the new standards no matter how they were implemented and authored.
If you’re like me, you can see where the Responsive Issues Community Group (RICG) might’ve decided to play a little fast and loose with some of the day-to- day rules of web standards so as to better serve the Priority of Constituencies. The PoC is an inversion of the web-standards power structure—a reminder that those with the most control over how web standards are written, implemented, and used must always prioritize the wants and needs of those with less control. After all, web users pay the costs of the decisions made by the standards process, implementors, and authors alike, and we authors form the users’ first line of defense.
I say “costs” with good reason, especially with respect to image transfers. The median webpage’s total transfer size is huge: 1.7 MB as of May 2018. Images alone account for roughly half of that. According to Pew Research Center, one in five Americans owns a smartphone but without a home-broadband connection, up from 13 percent in 2015 and eight percent in 2013. A full 31 percent of adults making less than $30,000 a year have access to a smartphone but no broadband connections at home, up from 20 percent in 2015. They go online by way of connections with metered limits and overage charges. Even those fortunate enough to have an “unlimited” mobile data plan still have their connection speed throttled beyond a certain cap.
It would be easy, but not realistic, to say “just get rid of some images” to better serve users. I know all too well that you and I are often stuck working within constraints we can’t control: a “final, approved design,” a “business requirement,” or someone very important feeling very strongly that we post images a certain way despite our protests. In real-world development, rules abound.
So, in the spirit of the RICG, let’s be a little “chaotic good” about some of the image performance problems we face in everyday development work. Specifically, let’s be a little creative in interpreting the constraints with images—and maybe bend the rules a little—in favor of the audience. With a little sleight of hand, nobody will be any wiser.
Stay tuned for part 2 for the details.
