WTFWG

This morning, Ian Hickson emailed the WHATWG mailing list mentioning that a attribute that was currently being discussed on the list (srcset) is now added to the draft of the spec. To understand why this sucks, a little background is needed.

Responsive images are a difficult beast to tame: there really isn’t a good solution for them today. As a result, some discussion started on the WHATWG mailing list months ago about what to do. The WHATWG pointed out that the list was for standardizing and suggested it would be better if the discussion were moved into a community group.

I think an attribute is simpler to implement and thus likely to result in fewer bugs in browsers, which in turn benefits Web developers.

This morning, the attribute was added to the spec.

I’ve got my own opinion about the correct solution, but that’s not really what’s I think is most troubling here. Note what happened:

Developers got involved in trying to standardize a solution to a common and important problem.

The WHATWG told them to move the discussion to a community group.

The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element.

Another (partial) solution was proposed directly on the WHATWG list by an Apple employee.

A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute.

While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft.

What. The. Hell.

The developer community did everything asked of them. They followed procedure, they thoroughly discussed the options available. They were careful enough to consider what to do for browsers that wouldn’t support the element—a working polyfill is readily available. Their solution even emulates the existing standardized audio and video elements.

Meanwhile an Apple representative writes one email about a new attribute that only partially solves the problem and the 5 days later it’s in the spec. In case there is any doubt, I’m not blaming him at all for how this all played out. That blame falls on the WHATWG. Whatever their rationale was for putting this in the draft, the method in which it was added reeks of valuing the opinion of implementors over developers.

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.

Those levels of priority make a lot of sense to me and it’s discouraging (to say the least!) to see them dismissed in this case. This kind of thing simply cannot happen. It’s tough to get people to voice their opinions to begin with. To find that their opinion holds no weight won’t make it any easier going forward.

What message does it send when developers try to contribute their time, energy and effort to help solve a problem only to have it so casually dismissed?