Bb's RealTech

But is the formal-standards-group route that much better? You often complain about lack of support for standards. Further, it's unclear that standards created by formal standards groups meet real needs. For instance, John Resig, developer of jQuery, actually dropped support for CSS3 selectors because they were rarely used and added weight to the package.

The thing I'll say for microformats is that they seem to have had better uptake than some longstanding standards like xhtml 1.1. I think I read that IE8 is going to support hAtom.

Maybe Sarah Bourne can go join the microformats community process and get herself heard. They're open to things like accessibility. That way, she could get solutions today vs. having to wait for a standards body.

Microsoft has taken hAtom and bastardized it to suit its own purpose. Which is why "standards" are important.

The lack of use of CSS3 selectors is understandable, as implementation is not widespread. This is not a recommended standard yet. I'm playing around with text-shadow and rgba and am not expecting implementation of either in all browsers.

As for the recommended standards, like XHTML and SVG, either we start respecting the standards effort, or we just let the corporations duke it out and sell ourselves out to the biggest bully.

The HTMLWG has 504 members, and the WHATWG's public mailing list has 867. Yet HTML5 has the backing of multiple browser vendors, and has made faster progress on a much bigger set of features than most W3C specs. The key, in my not so humble opinion, is building a solid community (something that can definitely be seen in the WHATWG space), and a benevolent dictator who is willing to take everyone's feedback into account and make decisions purely based on the merits of the arguments. In fact, I would say that the usual method, namely consensus building, is a terrible way to do language design. To start with, as you say, you can only have consensus when you have a small group, and secondly, committees simply don't design coherent languages.

The Web is a big place, it's not the place to have a tiny, usually self-selected, group of self-proclaimed experts making the decisions for everyone based on their personal (or corporate) biases.

Note that XHTML and SVG (and most W3C specs) are in fact exactly what you describe as the bad alternative: they're a bunch of corporations who are duking it out in committee meetings, and if we decide to follow the standards, then we have no choice than to sell ourselves out to the biggest bully.

Ian, you have got to be kidding. "Benevolent dictator"!?

You are kidding, right? Especially after the comments on this post, do you really think that everything is just ducky?

As for XHTML and SVG, both are released specifications, increasingly implemented in three main browsers, and glaring by their lack in the fourth. Both are precise, and extremely well documented. In fact, the SVG specification is one of the best, in my opinion, W3C documents.

It's easy to "make progress" when you don't listen to what people want, Ian, and can just make unilateral decisions. But then, a side effect of this type of organization is companies doing their own thing, and causing a great deal of havoc. As for corporate biases, what happens when the "benevolent dictator" brings a "corporate bias" of his own into the mix? There's nothing to balance this overwhelming power–no mechanism in place to make sure concerns are addressed, issues responded to effectively, or to override the dictator when the dictator's opinion sucks.

Making progress? You and I have different interpretations of what "making progress" truly means.

Actually the WHATWG is set up so that there is a committee that can override me and throw me out if I go off the rails. That's an important way to get accountability, otherwise, as you say, it would be very easy for the dictator to go off into the weeds.

I'm sorry if you think the comments on Sam's post were evidence of my ignoring feedback; on the contrary, I am really hoping that in due course people will realise that I am being quite honest and straightforward when I say that what we need is a careful study of the needs and use cases. I can't address people's requirements unless I know what they are. Unfortunately, Sam and others are so busy assuming that I'm against their ideas that they won't actually tell me what they are trying to solve.

As to the quality of the XHTML and SVG specs, I recommend speaking to some browser vendors and conformance checker implementors about them. They are both specs with a huge number of issues (though, ironically, for very different reasons — XHTML is far too vague and underdefined, and SVG is actually overspecified in parts, while leaving some key aspects intentionally undefined despite the group having been repeatedly asked about them). Having said that, SVG has certainly improved since the 1.0 days, though it has suffered somewhat from feature creep, and the language itself still isn't especially well designed. (Part of the problem there is that the SVG group got some bad advice from other W3C working groups, resulting in, e.g. its reliance on xml:id and XLink.)

Having said all that, you're probably right that the SVG spec is one of the best specs in the W3C space. The XForms spec is pretty good too, from a specification quality standpoint.

That doesn't affect my original point, which is that specs created by small closed groups of "experts" are not representative of the Web's desires as a whole. SVG in particular was for a long time heavily biased in favour of one vendor (Adobe), and that shows in the language's focus.

BTW, I sent you an e-mail about helping with the messaging, your help would be very welcome if you are still interested.

Aside from the main point of your post, just a correction: The post she attributes to Joe Clark is actually a post on my blog written by me.

Isofarro, I added a note about the Joe Clark link. I have to admit, I thought your site was Joe's once, too, from the badge.

Ian, what you're saying then is that there really is a smaller committee within the effort that resembles what happens in other standards efforts. Kind of. As for the comments at Sam's I thought both sides represent that there is a strong disconnect about the HTML5 effort, as well as some communication problems. It's not a matter of you listening to people like Sam. It's Sam having a mechanism in place to communicate issues with some formality, and then discussion on these issues being tracked, and accessible to others. And then once a decision is made by the working group, communicated in such a way so that Sam doesn't feel ignored AND, more importantly, the reason behind the decision is well documented so that there's no confusion.

There was obviously history between you all as regards to namespaces in HTML, but I couldn't find it. That kind of discussion should be recorded as an issue, and any discussion tracked as an issue.

You say it was not a high priority issue. Where is the list of all the issues? Where is the group's voting record on each? Where is the discussion tracked to each? I looked for it, and I found this and this. The latter is about what I was expecting, but seems like a very small number of issues. And I couldn't find anything on the HTML namespace discussion. Nor the need for SQL.

Instead, it ends up in weblog posts, comments, mailing lists, and probably on Twitter some where.

And it's not up to Sam to tell you, individually. It should be up to Sam to tell the working group, and the decisions should be up to the working group.

I'm not defending Sam. I am aware that he can be too cryptic with this communication. However, he's also pretty damn sharp. His point on the namespaces was good–Microsoft has implemented this in IE8 unilaterally, and this is now going to now cause problems. You might say this is Microsoft's problem, but when the company references the HTML5 effort as justification, and the effort is vague enough that they can do so, then the problem is also the HTML5 working group's.

You don't like the XHTML spec. That's great, but as far as I can see, it's the only spec that will work for me if I want to use SVG. Frankly, the only web page markup specification that will work for me that isn't bloated with stuff it shouldn't have (SQL), while stuff it should have is ignored.

PS Where is the discussion about putting SQL in or the vendors will implement it anyway? And where is the old HTML namespace discussion? I couldn't find either.

The scary thing in that spec is the following line:

"This specification is intended to replace (be the new version of) what was previously the HTML4, XHTML 1.x, and DOM2 HTML specifications."

Tell me then: how will I be able to use SVG inline in HTML5 if your spec replaces XHTML 1.x?

Shelly, in the XML serialization (XHTML5) that's already possible. In HTML5 it's not (yet) possible.

As for voting records, the whole point of having a "benevolent dictator" is that you don't need to vote on things and don't need comittee like processes. Everyone can provide arguments and the editors take all feedback into account when editing the specification and reply to the mailing list with decisions. Which don't have to be final decisions if you can provide arguments for why the decision was wrong, et cetera. It works pretty good so far. Given the amount of progress we make I'm not sure what would work better, even.

I had another comment but I decided that I'm not a player in this game.

Shelley, I see your comment in my aggregator. I'd recommend you restore it. It is a valid point.

Anne (and Ian), even with a benevolent dictator model, some formality is helpful, with explicit proposals and counter-proposals, unambiguous statements and public votes of support or opposition (even if they are advisory), and an unambiguous (even if non-final) decision. Python's PEPs are a good model (although Python's BDFL's decisions *are* usually final), and PEP numbers also serve as good unique strings to find related discussion on the web and mailing lists.

Michael, I don't even have it anymore.

Dang. And now it's gone from my aggregator too. Oh well.

Michael, we're using the mailing list for that currently. When Ian has gone through a pile of feedback he posts a summary of the changes on the list along with rationale for and against the change provided by excerpts from the feedback e-mails.

I agree that how Python does things is quite nice and the HTML WG was planning on following a similar model using wiki pages to summarize arguments, etc. So far, however, that model hasn't been practiced much.

I don't think the WHATWG committee really resembles most other standards committees, in that they rarely meet, they have never made any technical decisions, and their names don't appear on the specs (they're on the whatwg.org/charter page, if you're curious). But ok.

The mechanism to send feedback has been in place since the start, it's the mailing list. (The W3C has added several of their own mailing lists to this too, now.) Sam has used this mechanism in the past with no problems (e.g. with the "/>" idea).

Discussions for issues are archived on the mailing list archives, and feedback that hasn't yet been formally considered by the editor (me) is tracked on the issues page. I guarantee that any feedback sent to the WHATWG list will get a reply in due course, someone even set up a blog to track all those replies: http://hixietracker.blogspot.com/

The reason you couldn't find me in the history of the namespace issue is that I haven't considered that feedback yet. I've sent private e-mail to Sam (he never replied) and commented on his blog (Henri sent useful feedback in response, Sam didn't), but the issue hasn't yet been one that I have considered in my editor role.

The SQL thing landed May 23rd of last year, according to the (public) Subversion logs. The pressure for it was mostly offline (vendors tend to not like to let their competitors know what they are planning to implement, and I do accept feedback privately, though I try to discourage it), but this e-mail is one example (sent after it was checked in) of pressure to add stuff like it: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011560.html

The issue tracking page is at: http://www.whatwg.org/issues/

Where did you look? I would like to add links to the resources I'm mentioning here to all the places where you looked.