Re: Moving past last call for HTML5

Ian Hickson wrote:
> 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.

Equally unusual: "The HTML5 work isn’t using the traditional W3C 
approach, and will never use a consensus approach so long as I am editor"[1]

Frankly, we are in uncharted territory.  Without continuously assessing 
consensus (the traditional W3C approach) and without code to anchor us 
(like I see done elsewhere), frankly this spec is adrift.

There are still other processes that I'm aware of.  When I was the 
convener (roughly corresponds to W3C chair) of the ECMA CLI spec (better 
known as the spec for the foundation of the .Net CLR or Mono), we had a 
grueling schedule of meeting every six weeks or so face to face going 
over a chapter or so a meeting.

I'm flexible.  I'm quite willing to give you (or any other editor, for 
that matter) quite a bit of latitude.  But I will be equally straight up 
about my assessment of the prospects.  I believe I've been consistent on 
this matter.  I believe I was brought in to fix this issue.  And it is 
my belief that we can get through this, otherwise I wouldn't be here.

Your end date (2022) is clearly not an issue, but at this point in time 
I do strongly believe that some of the interim milestones need to be 
reexamined.

>> 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?

Regarding the question in the last paragraph: not to me.

Larry has simply asked that the section be removed.  Suggesting that his 
requests are not to be considered until he expresses any and all 
potentially unrelated objections is not, in my opinion, a particularly 
effective way to manage a queue of issues.  This looks like an easy 
issue to me, but if you want to defer it to 3Q that's you choice.  I'll 
just point out that the implications of such a cavalier approach to 
issue management are pretty clear to me.

As always, I'll be brutally honest here: if there are other specs that 
have editors that appear to manage their input queues of requests better 
and therefore show a greater chance of completing in a reasonable 
time-frame, I'll apportion my time accordingly.

For the record, I also don't believe that Rob's approach will be a 
cakewalk.  Just to give one example: I fully expect him to also run 
smack into an objection by the likes of Roy Fielding.  Roy is tough to 
work with because he invariably is right.  But I have worked with Roy 
before, and if we have dealt with or deferred all other issues, I'm 
confident that we can work through these issues too.

And if your choice is to focus further down the road, you will be 
amongst the beneficiaries of having these issues behind you.  Should you 
decide to switch directions and focus more near term for the moment, or 
to entertain the TAG-preferred approach of layered specifications, I'll 
help with that too.

>>>> 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.4.1.1.1
>>
>> 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.

Time out.  If I felt the "no consensus, no code" approach was viable in 
anything approximating a reasonable timeframe, we wouldn't be having 
this discussion.  We are exploring a potential "next step", not a "final 
destination".

If I wasn't clear on that, I apologize.

I'm not saying "never".  I'm saying that "not all at once" approaches 
look more viable at this point in time.  If you think that @summary is 
top of the list of issues that HTML4.next should address first and 
foremost, then by all means propose something else to defer until 
HTML4.next.next.

I do happen to have an opinion on the subject (I'd say that other 
battles are more important to me), but I'm not the one doing the work.

> 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.

Again "next step" vs "final destination".  A spec that is no worse than 
HTML 4 is in this one aspect might be a useful baby step given the other 
issues that we have to deal with.  And in the case of alt, the right 
baby step might very well be to continue to make it required 
unconditionally.

Pick your battles.

Just to be clear, I'm not telling you or Rob or Mike what order to do 
things, or what to work on.  But I will be by each of your sides and 
play an active role in assessing consensus throughout the process.

- Sam Ruby

[1] http://intertwingly.net/blog/2008/11/20/Half-Full#c1227317561

Received on Saturday, 21 February 2009 00:40:52 UTC