W3C home > Mailing lists > Public > www-archive@w3.org > February 2009

Re: Moving past last call for HTML5

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 20 Feb 2009 22:14:29 +0000 (UTC)
To: Sam Ruby <rubys@intertwingly.net>
Cc: www-archive@w3.org
Message-ID: <Pine.LNX.4.62.0902202151510.6186@hixie.dreamhostps.com>
On Fri, 20 Feb 2009, Sam Ruby wrote:
> Ian Hickson wrote:
> > On Thu, 19 Feb 2009, Sam Ruby wrote:
> > > For starters, there is an interesting gap between 100% and 50.000001%.
> > 
> > I wasn't specifically meaning 50%; there are as you say a number of 
> > ways of achieving "consensus" without achieving "unanimous consensus", 
> > ranging from 
> > everyone-except-people-who-disagree-with-everything-on-principle down 
> > all the ways past 50% to a mere plurality. If our goal is to aim for 
> > one of these levels, it would be helpful to know which level we are 
> > aiming for since it would affect the way one would approach the goal 
> > of publishing a last call draft.
> At the IETF, there is a mantra of "rough consensus and running code". As 
> I read your proposed milestones, I see Last Call first preceding running 
> code in a number of instances.  Am I misreading this?

No, that's correct. The W3C model is that running code is only expected 
after entering the CR phase. That we have any code at all at this very 
early stage (in W3C terms) is actually quite unusual.

> It would be helpful if we had a firm idea of how we want to approach the 
> problem of section 1.5.4 sooner rather than later, if we are to not slip 
> past October.  This is not an issue that where implementors "vote with 
> your feet". What bar are you looking for?

My understanding is that the status with that section is that Larry and 
Lachy were going to try to explain what was wrong with the section, so 
that it could be improved. Is this not the case?

If it turns out that this is one of only a few things that need to change 
to dramatically increase the level of consensus from certain quarters, 
then it's certainly an area that will change. On the other hand, if the 
people objecting to this section also object to most of the rest of the 
document, then changing it wouldn't gain us much. Does that make sense?

> > > For the near term the low hanging fruit is as follows: [...] for you 
> > > to consider Rob's approach to @summary, @profile, and @alt.
> > 
> > Could you elaborate on this? I'm not sure what approach you mean.
> Rob's statements on this matter:
> https://bugzilla.mozilla.org/show_bug.cgi?id=478665#c3
> http://lists.w3.org/Archives/Public/public-html/2009Feb/0128.html
> Related example from the same editor:
> http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.
> As a concrete example, let's explore "summary".  To the extent that I 
> understand it, your position is that the summary attribute is 
> non-conforming, and people who wish it to be so must provide a what 
> appears to be an unspecified amount of supporting data if they wish this 
> to be changed.
> My read is that Rob would simply say that summary is a part of the 
> grammar and would prepare an even-toned cautionary note directed at 
> consumers.  Others would be welcome to draft alternative wordings for 
> the cautionary note for consideration.

My approach is that I want to improve accessibility, and I think that the 
document conformance rules are one of several tools we have at our 
disposal to help people spend their time on the right things that improve 
accessibility. There has been new data recently collected that puts into 
question the current state of the spec regarding summary="", which I look 
forward to examining in detail, so this may not be a good example to 
study. Better examples might be axis="" or longdesc="", which are also 
absent in HTML5 yet present in HTML4 and which theoretically were supposed 
to improve accessibility. Including longdesc="" is demonstrably a waste of 
time, because so few pages use it correctly that users are almost 
certainly never going to try to use the feature. Thus, HTML5 makes it non- 
conforming, leading authors to spend more time worrying about other things 
(like alt=""), which actually do help accessibility.

The approach of just ducking controversy doesn't improve accessibility. It 
attempts to put an immediate spec-writing and working-group benefit 
(namely, being able to move forward without objections) ahead of the user. 
This, IMHO, is unacceptable (and is counter to our design principles). It 
also doesn't actually work, because it won't get any more consensus -- it 
will just move the objections from one group of people to another.

You also mentioned profile="" and alt="". I don't understand how the 
approach you describe would extend to those two attributes. In the case of 
profile="", just allowing it with the spec saying "here be dragons" misses 
the point entirely, which is that putting it in the spec leads other spec 
authors to think that the feature is something they can rely on, whereas 
in practice that isn't the case (virtually nobody actually uses it, even 
when they should). With alt="", as far as I can tell the spec is closer to 
taking the approach you describe than the people complaining want -- the 
controversy is actually that the spec doesn't take a stance that's tough 
_enough_, quite the opposite of the problem with the other two attributes.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 20 February 2009 22:15:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:34 UTC