17 May 2012 7 am eastern

The Unbearable Lightness of HTML5 – or, the priority of constituencies versus the great dictator

LET’S DIG A BIT DEEPER into the latest conflict between web developers who are passionate about the future of HTML, and the WHATWG. (See Mat Marquis in Tuesday’s A List Apart, Responsive Images and Web Standards at the Turning Point, for context, and Jeremy Keith, Secret Src in Wednesday’s adactio.com, for additional clarification.)

The WHATWG was created to serve browser makers, while its product, HTML5, was designed to serve users first, designers (authors) next, browser makers (implementors) last according to the priority of constituencies, which is one of its founding design principles.

There is a tension between this principle of HTML5 (to serve users above designers above browser makers) and the reality of who is the master: namely, browser makers – especially Google, which pays Hixie, the editor of HTML5, his salary. That’s not a knock on Hixie (or Google), it’s just the reality.

One way the tension between principle and reality plays out is in not uncommon incidents like the one we’re reacting to now. According to the priority of constituencies, designer/developer feedback should be welcomed, if not outright solicited. In principle, if there is conflict between what designer/developers advise and what browser makers advise, priority should be given to the advice of designer/developers. After all, their needs matter more according to the priority of constituencies — and designer/developers are closer to the end-user (whose needs matter most) than are browser makers.

Solicitiation of and respect for the ideas of people who actually make websites for a living is what would happen if the HTML5-making activity had been organized according to its own priority of constituencies principle; but that kind of organization (committee organization) echoes the structure of the W3C, and the WHATWG arose largely because browser makers had grown unhappy with some aspects of working within the W3C. In reality, there is one “decider” — the editor of HTML5, Ian Hickson. His decisions are final, he is under no obligation to explain his rationales, and he need not prioritize developer recommendations above a browser maker’s — nor above a sandwich maker’s, if it comes to that. By design, Hixie is a free agent according to the structure he himself created, and his browser maker end-users (masters?) like it that way.

They like it that way because stuff gets done. In a way, browser makers are not unlike web developers, eager to implement a list of requirements. We designer/developers don’t like waiting around while an indecisive client endlessly ponders project requirements, right? Well, neither do browser makers. Just like us, they have people on payroll, ready to implement what the client requires. They can’t afford to sit around twiddling their digits any more than we can. In 2007, the entire world economy nearly collapsed. It is still recovering. Don’t expect any surviving business to emulate a country club soon.

So, has this latest friction brought us to a tipping point? Will anything change?

In theory, if we are frustrated with Mr Hickson’s arbitrary dictates or feel that they are wrong, we can take our ideas and our grievances to the W3C, who work on HTML5 in parallel with the WHATWG. We should probably try that, although I tend to think things will continue to work as they do now. The only other way things could change is if Hixie wakes up one morning and decides benevolent dictator is no longer a role he wishes to play. If I were in charge of the future of the web’s markup language, with not just final cut but every cut, I’m not sure I’d have the courage to rethink my role or give some of my power away. But perhaps I underestimate myself. And perhaps Hixie will consider the experiment.

Filed under: democracy, HTML, HTML5, State of the Web, The Profession, Web Design, Web Design History, Web Standards

28 Responses to “The Unbearable Lightness of HTML5 – or, the priority of constituencies versus the great dictator”

  1. Jeremy Keith said on

    This may seem like a nit-picky point but we’re not actually talking about HTML5, we’re talking about HTML: The Living Standard (the document that the WHATWG are working on).

    That may seem pedantic but I think it’s important to remember the difference: the WHATWG are working on an ever-changing, always-evolving spec with no version numbers. The W3C are working on nailing down specific snapshots of that spec e.g. HTML5.

    The reason I mention this is because I don’t think we should be worried when the two specs go out of sync: they’re supposed to go out of sync.

    For example, I don’t mind if the srcset attribute is in the WHATWG HTML spec but not in the W3C HTML5 spec. If it works, it’ll end up in a future W3C version number.

    As for Hixie giving up the reins of power: he has up ’till now been editor of both the WHATWG document and the W3C’s HTML5 spec, but he has announced that he wishes to relinquish editorial control at the W3C and the search is now on to find his replacement (which will probably be a committee).

    I take this as further evidence that the evolving WHATWG “Living Standard” spec will further deviate from the W3C “snapshot” spec. And that’s okay.

  2. Jeffrey Zeldman said on

    Good points, as always, Sir Jeremy.

    So in theory, sticking just with the current dispute and assuming that no third proposal comes along — all huge assumptions, but this is just a hypothetical discussion to envision how things might play out — if the WHATWG “living” HTML temporarily contains img src set, but a future crystallized HTML5.3 W3C recommendation offers picture instead, individual browser makers would implement picture. Browser makers wouldn’t implement img src set unless and until it found its way into a final HTML5.x W3C recommendation. (Again, deliberately limiting ourselves to just these terms.)

    Is that how it’s supposed to work, as far as you know? Or are browser makers free to implement experimental features that are part of the living HTML but not part of a W3C candidate recommendation — as they are free to implement experimental CSS modules?

  3. Bijan Parsia said on

    Obviously, browser makers are always free to implement (or not implement) anything at any time. There’s good reason to implement pre-standardized things both experimentally and pseudo-experimentally. (Once implemented, it’s hard to keep useful stuff out of the field even if somewhat broken.)

    We can’t usefully require no implementation in advance (or we can’t really validate the features). We can’t effectively prevent leakage (because field use is the ultimate test). No matter what regime is in place, these things are certainly true.

    (This is why the formal arrangement of the WHATWG is really a secondary matter. In the end, implementation happens according to an internal resource allocation model. “Conforming to a standard” has a weight in that, but for browser vendors a comparatively low weight, all things considered.)

    Routes to influence: The user base has three major vectors of influence: 1) standards and standards orgs, 2) direct lobbying/working with browser makers, and 3) Javascript based extensions/polyfills.

    1 is only one mechanism, and not necessarily as powerful as people think it is. (I certainly tend to overestimate its effect.) For prospective features, everything boils down to lobbying the implementors since nothing happens without implementation, whether baked in or Javascript based. Once functionality is widely deployed, retrospective standardization tends to follow practice.

    So, the picture vs. srcset way forward is reasonably straightforward, I think. Picture is already implemented via polyfills, so start using and championing it. If it catches on, then I think the standards (and native implementations) will follow and the people who were behind it will build some cred for the next thing they propose.

  4. steve faulkner said on

    hi jeffrey, you wrote:
    “In theory, if we are frustrated with Mr Hickson’s arbitrary dictates or feel that they are wrong, we can take our ideas and our grievances to the W3C, who work on HTML5 in parallel with the WHATWG.”
    This is not just a theory, people and groups disenfranchised by the WHATWG have been working through the W3C for years. The majority of improvements in the accessibility aspects of HTML standardization have and continue to occur at the W3C. The W3C is where non-browser stakeholders (as well as all browser vendors including Microsoft) are represented.
    The WHATWG works fine for initial rapid development, but falls short when it comes to standardization. In particular the specification of author conformance requirements and advice, these are not things that need to change on a whim, or be decided by one person alone, but they are and do in the HTML living standard. It is unfortunate but now we don’t have a standard that is a canonical source for such information, developers and authors have two sources and no way to discern which to follow.

  5. steve faulkner said on

    Jeremy Keith wrote:
    “I take this as further evidence that the evolving WHATWG “Living Standard” spec will further deviate from the W3C “snapshot” spec. And that’s okay.”

    I agree that it’s OK for the specs to differ on implementation details, but I don’t think its OK to differ on author conformance requirements and advice, that is just confusing and the antithesis of standardization.

  6. Marcos Caceres said on

    Generally, implementers work off the WHATWG version – so, putting things in the W3C version is just for patent protection (notably from Microsoft and the other companies like IBM, RIM, etc., as there is already an informal agreement around patents relating to HTML with the WHATWG members – Apple, Opera, Google). As Tab Atkins Jr. demonstrates on his blog, both solutions are flawed (but specially the one using CSS media queries): http://www.xanthir.com/blog/b4Hv0

    I don’t think attacking Ian is helpful, either. If we want Editor independence, then maybe we should create a Kickstarter project for a “Web Foundation” (or directly through the W3C): that way, the Editor can work independently of their employer while retaining their salary.

  7. steve faulkner said on

    Zeldman wrote:
    “are browser makers free to implement experimental features that are part of the living HTML but not part of a W3C candidate recommendation”

    They are free to do so and do and will continue to do so. And that seems to work OK most of the time.

  8. John Bertucci said on

    I just wanted to chime in and say that I appreciated Jeremy Keith’s journal entry explaining this whole thing is much finer detail with points from both sides.

    I started by reading the ALA article and then following to see other blogs ripping on “Hixie” without really knowing much behind the story.

    I feel like the community of web developers/designers are clearly bitter about something and from the reading of feeling that the ‘picture’ idea is completely and unreasonably being ignored, I can understand.

    However, there appeared to be more to the story and I think Jeremy Keith cleared that up nicely. In comparison, I do feel this article by Mr Zeldman and the ALA article by Mr Marquis come across a bit more one sided despite a disclaimer of objectivity (which reminds me of the “with all due respect” joke that you can say whatever you want as long as you preface it with that phrase).

    While I was excited when I learned of the ‘picture’ solution the community group created (I feel it’s a clear and usable idea to a problem), after reading Mr Keith’s explanation of ‘srcset’, I also feel excite to have this too (with the need to clarify the min/max size ambiguity).

    At the end of the day, the passion is clear but I hope it doesn’t stop or delay the development of a solution we all need.

  9. Jeffrey Zeldman said on

    I do feel this article by Mr Zeldman and the ALA article by Mr Marquis come across a bit more one sided despite a disclaimer of objectivity

    I hope I don’t pretend to be objective! :D I am trying to be fair – to acknowledge Hixie’s achievements and the work that has been done under his leadership — but I make no effort to hide my bias toward the web design and development community in general, and the recent work done by my friend and colleague (and A List Apart contributor) Mat Marquis in particular.

    The fact that both solutions are flawed in different ways — and that “picture” was chosen based on a mistaken notion about “img” — makes me think we might not to force through a solution at this time (if that were even possible, given the WHATWG’s set-up). It looks to me like a bit more work and thinking might be needed. This doesn’t change my opinion that Hixie’s inclusion of “img src set” was a premature and rather arbitrary exercise of power, and that that arbitrariness is a problem. We are, after all, talking about the future of a most important medium in which we toil. For people who create the medium to have little to no say in how that medium develops feels wrong to me. That is my bias. I hope I was clear about that.

  10. Jeffrey Zeldman said on

    Steve Faulkner wrote:

    It is unfortunate but now we don’t have a standard that is a canonical source for such information, developers and authors have two sources and no way to discern which to follow.

    I think it is more a problem for browser makers than for developers. As a front-end developer, I’ll continue to write markup against a particular W3C specification, just as I’ve done for years — just as we’ve all done since the web standards revolution, when we figured out the rational way to develop websites and persuaded browser makers to support us. The problem is, it’s not clear what standard the *browser makers* should implement, and the HTML5 DOCTYPE, which is version-less by design, does nothing to correct that problem. I might develop against a canonical W3C freeze-frame of a particular flavor of HTML(5) but the browser has no way of knowing that, and the browser maker may or may not support certain features. A certain anarchy has been reintroduced, I agree — and after all our years of hard work getting to standards. From that point of view, the Balkanization of HTML5 doesn’t feel like progress.

  11. Brad Bice said on

    Has Hixie ever said *why* he put src set into the spec? I’ve perused the IRC logs over the past few days but haven’t seen him specifically recall why he did or the process in which he decided to do so. That might shed a little light onto the entire situation.

    And it’s definitely bad form for the browsers to implement features from 2 sets of “standards” since duality seems to nullify the definition of a standard. It’s great and fun to have access to bleeding edge features but can those please be relegated to software similar to Chrome’s Canary? This way developers can have access for testing but the stable versions of browsers will adhere strictly to recommended standards.

  12. Hugh Guiney said on

    I think this issue has been blown way out of proportion… While I certainly understand and empathize with the frustration that comes from toiling away on an idea for months only to see the work tossed out, when it comes down to it @srcset is still designed to address the very use cases that picture was. It was created despite that proposal, not in spite of it; Hixie took the work of the Responsive Images Community Group specifically into account when creating it, and without that work it’s likely @srcset wouldn’t even have made it into the spec. If anything this is a success story, as it’s proof that developer needs are indeed being listened to; while Hixie has admitted to favoring implementors (a purely pragmatic stance), the fact that an Apple employee came up with the initial syntax is coincidental in this case and hardly evidence of conspiracy.

    Design Is A Job, right? Language design is Hixie’s job. As uncomfortable as it may be for us designers and developers who are used to calling the shots, in reality we are the clients in this scenario (to take a different spin on your analogy, Jeffrey). As the clients, we may have a ton of really cool ideas, some of which could even work, and although design is absolutely a collaborative process, at the end of the day it’s our responsibility to outline the business objectives, and Hixie’s to decide how best to address them. We can’t fall in love with any one idea, because it may not actually suit the design as much as we think, and ultimately the product needs to serve the users, not egos.

    Granted it’s not all that clear-cut, as developers are, in a sense, users of HTML—but if the goal of design is to solve problems, and @srcset solves the responsive images problem, what, then, is the problem with it? I’ve seen arguments that it doesn’t, that it lacks a polyfill, that it doesn’t have good fallback behavior… none of which are actually true. While Jeremy’s post certainly elucidates the issue, Tab Atkins also wrote a very informative post on the WHATWG mailing list clearing up a lot of the misconceptions people have about this, which is definitely worth a read.

    The bigger issue here is the W3C and WHATWG need better cooperation. Solving problems in silos fractures the Web moreso than benevolent dictatorship. Case-in-point: although I am free to post to the WHATWG mailing list or IRC, I had to not only sign a contract to join the Community Group, but also needed approval from as administrator, who in my case asked if my employer at the time could join as an organization, rather than myself as an individual. I didn’t understand the relevance (I suspect it has something to do with the W3C subsisting on membership dues although I was also told CG participation was free) and was otherwise busy so I didn’t bother completing the application process. And I’m someone who cares about the Web a great deal, who’s itching to contribute to its growth. So imagine how many other developers must’ve been left out of that conversation.

    None of this is to suggest that the WHATWG process is perfect by any means, or even entirely fair. But when the community draws so much inspiration from Apple, a company founded in antithesis to design-by-committee; Jobs having final say in all product decisions to ensure quality and coherence—it is somewhat perplexing that there would be so much backlash to that very system in a slightly different context.

  13. John Foliot said on

    Picture is already implemented via polyfills, so start using and championing it. If it catches on, then I think the standards (and native implementations) will follow

    To my mind, one of the biggest problems is that developers have ceded “control” to the WHAT WG as the arbitrators of the specification process, which we are seeing here is not such a smart thing after all. There is an advantage to the browser vendors who fund the WHAT WG process in using that process to move specs forward, but content developers need to remember that not every browser vendor has a place at the table inside the WHAT WG – namely Micorosoft. Scoff, giggle, chastise Microsoft all you want for their past sins (like once releasing 2 of the most standards compliant browsers of the day – yes IE6 and IE 5.5 [Mac] – thank you Chris and Tantek) – the reality is though that if you really do develop for your clients and their users, you must still consider IE – and if any indications are to be taken seriously, IE 10 will be a contender. So point 1 to remember is that just because WHAT WG specs out something, there is no guarantee that it will see universal adoption across all browsers.

    Point 2 is an echoing of what Bijan Parsia stated: if developers really don’t like the srcset ‘solution’, don’t use it. That might seem simplistic, but it is also a truism. Even Lord Hixie has said that without “implementation” it’s just fiction, so voting with your feet is certainly a powerful lever of change. If no authors implement the srcset solution, then it will wither and die. It really is that simple.

    If *you* believe that the picture solution is better (and are happy to use the existing pollyfill), then for you gentle author the problem has been solved – and without the WHAT WG having a say. If enough of you start to do *that*, then guess what? The browsers will move toward supporting that. Why? Because on the mobile platform (in particular), running JavaScript is “expensive”, which impacts performance and battery life. Conversely, if the function is handled internally by the browser there is an efficiency found. Supply and demand economics in your hands!

    Finally, don’t blindly accept what the WHAT WG tells you – yes, they have clout, but so do you. Don’t be afraid to exercise that clout, and don’t be afraid to tell the WHAT WG “no way!”. Remember, they are the vendors, and we are the consumers.

  14. steve faulkner said on

    Jeremy Keith wrote:

    This may seem like a nit-picky point but we’re not actually talking about HTML5, we’re talking about HTML: The Living Standard (the document that the WHATWG are working on)

    You should bring this with the WHATWG as they use the term HTML5 to refer to the living standard “www.whatwg.org/html5″

    1.2 Is this HTML5?
    In short: Yes.

    Meanwhile the HTML living standard developer edition is titled “WHATWG HTML5 A technical specification for Web developers”

    How is the general development community supposed to understand the difference between the W3C HTML5 specification and the HTML living standard when the WHATWG merrily conflate the two.

  15. David Goss said on

    @Brad Bice

    Hixie wrote a long email to the WHATWG public mailing list explaining what he’d specced and why:
    http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035855.html

    @Zeldman

    I don’t know if I’d say “arbitrary” – Hixie clearly believes srcset is the right solution (I still don’t agree). It just seems needlessly hasty, after a mere 5 days of looking at the two options (far as I know, picture wasn’t on his radar until the srcset proposal brought the whole thing to a head). On the other hand, how would we feel if, after his 5 days, he’d specced picture instead?

  16. Don ulrich said on

    Bluntly, what a freaking mess. Something simple and atomic has been turned like so much web code these days into a “MY Private Frankenstein” On the one side developers who wish to capitalize on what ever tech o the day rolls out of the box and browser folks that well are browser folks. Last check they have not implemented the last spec. fully. Please. Just please quit it.

  17. Luke Stevens said on

    Imaging alternative scenarios where Hickson does share power, or does play a role as facilitator and not just decider, or does encourage some kind of meaningful process (oh that the WHATWG FAQ section on adding features was anything but fiction: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F ) really does serve to highlight how much friendlier, more collaborative, and more productive the WHATWG could be.

    Sometimes it seems like the web design/standards community (and browsers) have run from one bad relationship (the W3C) into the arms of a just plain weird one. We were happy for a while — look, things are actually happening again! — and at least they weren’t dating someone else at the same time (XML) but now we’re starting to wonder if we can’t actually do better than someone who just occasionally acknowledges our existence, and maybe there’s someone out there who will actually listen to us; someone who we can have a not just a barely-functional, but actually productive and exciting relationship with… *looks misty-eyed into the distance*

    *ahem* … To be fair, Hickson has done a lot of good work (reverse-engineering canvas; actually getting the HTML spec into shape) but has a long history of making very strange decisions very quickly.

    HTML5 structural markup is a mess, and was seemingly invented by Hickson on a whiteboard in 2004 (and is absolutely not based on research, as is often claimed, and Hickson admits, as I write in my *plug!* almost-out book The Truth About HTML5: http://itsninja.com/html5book/ :); microdata was invented by Hickson because he didn’t like microformats or rdfa; the whole time saga; and so on. (Even the recent “all content on the web is an article” clarification/proclamation was just plain weird.) It’s the same as it ever was in that regard.

    The odds of Hickson going back on a decision he has made are slim. After all, in Hickson’s view, as he stated with regard to srcset “at the end of the day though it’s better to have something mediocre than nothing at all” (http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2940 — the tone-deafness of WHATWG participants to issues of process in that chat log is pretty face-palimingly breathtaking), and unless new information comes to light, the deal is done. The idea of holding off on making a decision; or spurring the interested parties on to come up with a better solution to srcset *or* picture; or flagging his intent to add to the spec didn’t seem to be of much interest to Hickson. To whit: “there was a clear (imho) statement of a problem that needed resolving, there had already been a broad investigation of the solution space, and the discussion was no longer progressing”.

    So, to Hickson, job done. The process worked. There wasn’t a solution and now there is. For him to come around to the idea that maybe there is a problem and maybe the process didn’t work and maybe he should do things differently and maybe he shouldn’t be editor anymore is, let’s say, quite an ideal, but hey, we can dream :)

    I think there is one potential new avenue to explore though, and that’s with Mozilla. They are doing a whole heap of standards work on APIs at the moment with their WebAPI initiative . (Not quite apples to apples with APIs and HTML, but not apples to fish either.) They intend to experiment themselves, then take the standards to the W3C to, well, standardise. (Can you imagine them trying to get any of these ideas through Hixie?) This seems like the biggest post-WHATWG development in web standards going on at the moment. If Mozilla doesn’t have to deal with the WHATWG, or attempt to innovate with the W3C for that matter, why do we?

    To me, our options are:
    – Put forward an editor to replace Hickson, and petition the WHATWG members (see the WHATWG charter page) to replace Hickson, which seems unlikely.
    – Ask Hickson to step down, which seems unlikely.
    – Come up with a strategy to route-around the WHATWG, given they are now the obstacle to innovation and participation we need, and work with Mozilla (for e.g.) to implement first, and take specs to the W3C. This also seems… unlikely, but there’s a crack of light there.

    It seems like something has to give sooner or later but maybe, as the WHATWG’s initial formation demonstrated, things have to get pretty bad first. The WHATWG is dysfunctional, which is a step up from the W3C’s previous complete non-functioning. But surely it’s time where we can say the WHATWG with Hickson as dictator is too hot, the W3C is too cold, and there’s a third way that actually lives up to its own claims and serves the interests of those it professes to put first, and works with us, rather than merely acknowledging our existence from time to time.

    Then again, maybe Hickson is right. Maybe, as far as the WHATWG goes, “at the end of the day though it’s better to have something mediocre than nothing at all”. But I hope not.

  18. Bridget Stewart said on

    @Luke Stevens

    “…the tone-deafness of WHATWG participants to issues of process in that chat log is pretty face-palimingly breathtaking)…”

    I haven’t been through the chat log, but I was working my way through the WHATWG mailing list threads. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035907.html, in particular has a very different vibe to it than what you describe. I see members of the WHATWG admitting their shortcomings while suggesting improvements to what we can do as developers to

  19. Bridget Stewart said on

    Ugh, dog posted for me before it was time! :) Trying again:

    @Luke Stevens

    “…the tone-deafness of WHATWG participants to issues of process in that chat log is pretty face-palimingly breathtaking)…”

    I haven’t been through the chat log, but I was working my way through the WHATWG mailing list threads. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035907.html, in particular has a very different vibe to it than what you describe. I see members of the WHATWG admitting their shortcomings while suggesting improvements to what we can do as developers to shed light on spec implementations we feel need to be addressed.

    I wrote a post on my blog (http://shallowthoughts.org/2012/05/17/img-srcset-vs-picture/) sharing my thoughts about what I’ve read so far, so I won’t repeat them all here. Personally, I’m not ready to view the WHATWG as a pack of villians bent on our destruction. I’m trying to take everything into account and give everyone the benefit of the doubt right now.

  20. Luke Stevens said on

    @Bridget, you should definitely go through the chat log, as it was Tab Atkins’ behaviour that exemplified the tone deafness I was speaking of. He had plenty to offer technically that I’m sure was very helpful (I have no horse in the race and no opinion one way or another), but reading @necolas try and patiently explain over and over that there was, in fact, a problem (http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-1043, http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-1406 ) only to have his concerns dismissed as ego or hurt feelings or simply unrecognisable was particularly frustrating to read. It exemplified the good-at-technical-stuff-but-not-good-at-people-stuff that turns people off. His tone throughout has been pretty condescending.

    The WHATWG’s disdain for process was also quite illustrative of the broader problem:

    # [17:56] necolas: The bottom line is, if you don’t like the solution, say so. Complaining about process is *very rarely* productive, however.

    # [23:25] adactio: referring to me as a dictator doesn’t automatically mean you’re a troll, but it does mean you’re talking about process and not the technical stuff, which usually isn’t helpful

    I find this interesting. It’s almost as though they’re allergic to process in reaction to the W3C’s process-fest at the other extreme. But that’s what we have — two extremes, with a highly idiosyncratic benevolent-dictator-for-life in charge of HTML on the one hand, and ye olde W3C on the other. The utopian ideal the WHATWG seems to believe in — focus only on the technical, never mention the p-word, and everything will be fine — is a nice idea, especially while it’s you and your pals kicking around ideas and celebrating Ian’s conclusions, but it doesn’t exactly scale when others want to get involved.

    Is really the future we want for HTML? Are we prepared to go through this “there goes Hixie again!” routine time and again for HTML[6/7/8]? If not, we need to start thinking pretty hard about alternatives.

  21. Jeremy Keith said on

    Steve Faulkner wrote:

    “How is the general development community supposed to understand the difference between the W3C HTML5 specification and the HTML living standard when the WHATWG merrily conflate the two.”

    I concur. The lack of consistency in the way the WHATWG label their own documents is very confusing.

  22. Jeffrey Zeldman said on

    A Readability view of the chat log in question makes it easier to read, if not always easier to stomach. There are a number of quietly patient heroes on that list; I salute them. I also know what they are up against.

    Winter is coming.

  23. Jeffrey Zeldman said on

    Off-topic, linking to a Readability view was so much better (so much more effective) before a misguided online bully intimidated Readability’s creators into diminishing the app’s benefits and functionality.

    I used to be able to link directly to a readable view of a piece of web content. Now my link redirects to the same, lousy, unreadable original view, with a tiny, easy-to-miss note at the top inviting the reader to click through to a better reading experience. Many readers following my link will miss the tiny note at the top and have a bad reading experience — or quit reading.

    It’s amazing how our whole bloody web gets bullied and bought into all kinds of weird shapes that have nothing to do with the joy of self-expression and seamless, honest transactions that attracted us all here in the first place.

    So, maybe not off-topic after all.

  24. Bridget Stewart said on

    Thanks, Jeffrey. I’ll go through the chat log to get a better overall picture.

    Just for the sake of clarity, I was fortunate enough to be around the discussion when the picture element emerged as a candidate. So, I am intimately aware that the RICG toiled on that solution based on initial impressions (brought to light as misunderstandings later) that the img tag was off limits for improvement/enhancement. I also know that they were seeking guidance from browser makers even in that very early stage. It’s a shame this blew up the way it did. It is not for the IRCG’s lack of trying, that’s for certain.

    https://etherpad.mozilla.org/responsive-assets (If you look in the chat block on the right, you’ll see my name there.)

  25. Jeffrey Zeldman said on

    Thanks, Bridget. And thanks, everyone who has contributed so far.

  26. Will said on

    Thanks, indeed. Great comments on this post.

    And hearty out loud laughter @ ‘web bully’.

  27. Abe said on

    Individuals become dictators because they had influential supporters. In the case of current web standards, the HTML5 Super Friends helped in their own way create this golem.

    Jeffrey, I hope you will accept some responsibility for this mess.

  28. 3 Types Of Solutions To Work With Responsive Images | Van SEO Design said on

    [...] I’ll stay clear of the controversy, except to say each syntax has valid reasoning for why it should be the standard. If you want to [...]

Comments off.