A map to build by

The fifth and final Build has just wrapped up in Belfast. As always, it delivered an excellent day of thought-provoking talks.

It felt like some themes emerged, not just from this year, but from the arc of the last five years. More than one speaker tapped into a feeling that I’ve had for a while that the web has changed. The web has grown up. Unfortunately, it has grown up to be kind of a dickhead.

There were many times during the day’s talks at Build that I was reminded of Anil Dash’s The Web We Lost. Both Jason and Frank pointed to the imbalance of power on the web, where the bottom line has become more important than the user. It’s a landscape dominated by The Stacks—Google, Facebook, et al.—and by fly-by-night companies who have no interest in being good web citizens, and even less interest in the data that they’re sucking from their users.

Don’t get me wrong: I’m not saying that companies shouldn’t be interested in making money—that’s what companies do. But prioritising profit above all else is not going to result in a stable society. And the web is very much part of the fabric of society now. Still, the web is young enough to have escaped the kind of regulation that “real world” companies would be subjected to. Again, don’t get me wrong: I don’t want top-down regulation. What I want is some common standards of decency amongst web companies. If the web ends up getting regulated because of repeated acts of abuse, it will be a tragedy of the commons on an unprecedented scale.

I realise that sounds very gloomy and doomy, and I don’t want to give the impression that Build was a downer—it really wasn’t. As the last ever speaker at Build, Frank ended on a note of optimism. Sure, the way we think about the web now is filled with negative connotations: it appears money-grabbing, shallow, and locked down. But that doesn’t mean that the web is inherently like that.

Harking back to Ethan’s fantastic talk at last year’s Build, Frank made the point that our map of the web makes it seem a grim place, but the territory of the web isn’t necessarily a lost cause. What we need is a better map. A map of openness, civility, and—something that’s gone missing from the web’s younger days—a touch of wildness.

I take comfort from that. I take comfort from that because we are the map makers. The worst thing that could happen would be for us to fatalistically accept the negative turn that the web has taken as inevitable, as “just the way things are.” If the web has grown up to be a dickhead, it’s because we shaped it that way, either through our own actions or inactions. But the web hasn’t finished growing. We can still shape it. We can make it less of a dickhead. At the very least, we can acknowledge that things can and should be better.

I’m not sure exactly how we go about making a better map for the web. I have a vague feeling that it involves tapping into the kind of spirit that informs places like CERN—the kind of spirit that motivated the creation of the web itself. I have a feeling that making a better map for the web doesn’t involve forming startups and taking venture capital. Neither do I think that a map for a better web will emerge from working at Google, Facebook, Twitter, or any of the current incumbents.

So where do we start? How do we begin to attempt to make a better web without getting overwehlmed by the enormity of the task?

Perhaps the answer comes from one of the other speakers at this year’s Build. In a beautifully-delivered presentation, Paul Soulellis spoke about resistance:

How do we, as an industry of creative professionals, reconcile the fact that so much of what we make is used to perpetuate the demands of a bloated marketplace? A monoculture?

He spoke about resisting the intangible nature of digital work with “thingness”, and resisting the breakneck speed of the network with slowness. Perhaps we need our own acts of resistance if we want to change the map of the web.

I don’t know what those acts of resistance are. Perhaps publishing on your own website is an act of resistance—one that’s more threatening to the big players than they’d like to admit. Perhaps engaging in civil discourse online is an act of resistance.

Like I said, I don’t know. But I really appreciate the way that this year’s Build has pushed me into asking these uncomfortable questions. Like the web, Build has grown up over the years. Unlike the web, Build turned out just fine.

Have you published a response to this? :



I tried to resist writing this post. I really, really did. I’ve ranted once about the standards process as it related to responsive images. I had no interest in going there again. I’d prefer not to be known as “that ranty Wisconsin dude who sounds slightly Canadian when he talks”.

Besides, I hesitated to post a condemnation of the current state of affairs when I didn’t have a solution to offer up.

But then I read Jeremy Keith’s beautifully written post “A map to build by” discussing the web and our ability to impact what it becomes. In it, Jeremy said:

Perhaps we need our own acts of resistance if we want to change the map of the web. I don’t know what those acts of resistance are. Perhaps publishing on your own website is an act of resistance—one that’s more threatening to the big players than they’d like to admit. Perhaps engaging in civil discourse online is an act of resistance.

Jeremy was discussing other issues, but I think those words make sense in many contexts.

So let’s consider this my act of resistance.

If you’ve not been paying attention, the responsive image discussion has continued full-steam ahead, but without any conclusion. If you want to catch-up in full, I highly recommend Bruce Lawson’s excellent review of where we are and Mat Marquis’s gist of where things stand.

For anyone not willing to read the full thing, here’s a TL;DR version:

  • The picture element was never received with any sort of enthusiasm by implementors and, while not dead, is barely what you would call alive.
  • The srcset attribute was implemented by WebKit for resolution only, and by Blink (also for resolution only) behind an experimental features flag.
  • Tab Atkins proposed a new approach, src-N, that address the three primary use cases (art direction, resolution, screen size) for responsive images.

So that’s where we stand today. Just about everyone agrees that srcset is not extendable—hence why no one is implemented the extended syntax for the other use cases. Mozilla, in fact, has come right out and said they have zero interest in it at all—they closed the issue as WONTFIX.

On the other hand, just about everyone has some interest in src-N. It solves the use cases, has implementor support from Blink (the Client Hints proposal was even refactored to incorporate src-N) and Mozilla, and has the support of the RICG. Seems like a great situation to be in.

The one exception, however, is the WebKit gang who have labeled src-N “a grotesque perversion of the HTML language”. Guess you could say they’re not big fans of the syntax.

Coincidentally (or perhaps not so much) the same group that came up with srcset is the one implementor not willing to leave it behind. Unfortunately, because this particular implementor wields a big stick, Blink sounds like they’re willing to play follow-the-leader and do as WebKit does.

The fact that Blink is apparently calling src-N dead in the water because one implementor opposes (WebKit) and yet haven’t said the same about srcset which is also opposed by an implementor (Mozilla) speaks volumes to the rationale here: it’s not because there isn’t a consensus, it’s because of who is wielding the heavier stick. The fact that the RICG have thrown their support behind src-N appears to not really figure into the equation.

So here we are 21 months after the RICG was started. We finally have a solution that both the RICG and a majority of implementors are interested in, and it looks like it’s at risk of not happening because of one single implementor dissenting opinion. The fact that the currently discussed solution on the WHATWG list is a frankenstein combination of HTML and inline CSS doesn’t do much to elevate my spirits (thread starts here).

Here’s the thing: the existence of politics in this doesn’t surprise me, it’s an unfortunate reality. I’m also pragmatic enough to recognize why WebKit has such a large influence here. I get all that.

But I find it upsetting that one party can throw this much weight around, discount the opinions of developers and other browser implementors in one fell swoop, and then watch as everyone accepts their opinion as the ultimate conclusion.

Just as I did last May, I refer back to design principles of HTML once more. In terms of priority, the top three opinions go to three groups, in order:

  1. Users This is definitely good for users. They’ll benefit from src-N by getting less page weight and improved rendering times, among other things.
  2. Authors The RICG is the representative for the developers in this scenario and they are in support of src-N.
  3. Implementors Here again is almost a full consensus. Mozilla and Blink have shown interest, WebKit is stonewalling.

I’m no standards expert but when I can place checkboxes next to the top two priorities, and when more representatives of the third priority support something than do not, then it seems to me that thing has merit. If those principles can be thrown out the door when one implementor opposes a solution, then what exactly are they there for in the first place?

I openly admit I’m not sure how to solve the situation. Here’s what I do know.

  1. We can’t stick our heads in the sand and pretend an attribute that lets us give our fancy iPhones and iPads a big, fat, shiny image is a good enough solution.
  2. There is a very, very small likelihood of everyone agreeing on one perfect solution. As a result, concessions need to be made. For example, the RICG is supporting src-N because of the interest from implementors despite many members still preferring the picture syntax.

Given that no solution is likely to be agreed upon by everyone we need to find one that solves the use cases, can be responsibly polyfilled, has the approval of the authors and makes a majority of implementors happy. And then we need to ship it.

Maybe that solution is src-N, maybe it’s something else. But I’d prefer to work on a web where we didn’t have to wait for WebKit, or any other single party for that matter, to make up our minds for us.

# Saturday, November 16th, 2013 at 10:45am

1 Like

# Liked by Leban Hyde on Wednesday, December 3rd, 2014 at 5:35pm