Re: Moving past last call for HTML5

On Sat, 21 Feb 2009, Sam Ruby wrote:
> Ian Hickson wrote:
> > On Fri, 20 Feb 2009, Sam Ruby wrote:
> > >
> > > You must have some history with Larry that I'm unaware of
> > 
> > No history with Larry. History within the W3C with other people, 
> > though, yes (such as the sXBL debacle I described).
> 
> Larry is not other W3C people.

My apologies to Larry if there was any suggestion that I was painting him 
with the same brush as my past experiences. My point really had nothing to 
do with Larry specifically, but was a general point on the kinds of things 
that are worth keeping in mind as we move towards confirming consensus 
and addressing remaining areas that lack consensus.


> I see a lot of subjective content in the spec.  Not just a little, but a 
> lot. And a process set up whereby one individual party "wins" every 
> controversial argument.

I understand that certain people have this (incorrect) perception. I don't 
know what to do about it. Maybe I should keep sending complaints to the 
group about areas of the spec where logical argument and research (and 
thus the edits to the spec) disagreed with my opinion, in the same way 
that certain other working group members keep reraising the same issue 
over and over again without introducing new data?

(e.g. the allowance for the /> syntax in text/html, which I still think is 
a bad idea but which is in the spec against my desires because as editor I 
only took into account the arguments put forward and the data presented, 
and the arguments you and others put forward and the data that you and 
others presented were stronger than the arguments against the idea.)


> > Wow, if receiving thousands of pieces of separate feedback isn't what 
> > you consider "hearing about the real issues", I can't imagine how much 
> > feedback you're actually expecting!
> 
> Ye, you have thousands of pieces of feedback, much of it from a 
> relatively small and homogeneous group of people, namely browser 
> vendors.

I haven't been keeping track of volume of feedback from browser vendors vs 
others, but I think that if there is such a bias, it's actually only 
because the browser vendors keep hiring the most prolific reviewers. The 
acknowledgements section of HTML5 -- which only tracks feedback from 
people whe caused changes to the spec -- has literally hundreds of names, 
the vast majority of which have no browser affiliation.


> I'm also concerned about feedback that has "fallen through the cracks".  
> I've made a number of comments, one in particular multiple times, that 
> has never been so much as acknowledged.  If it happens to me, it is 
> likely happening to others.

I have 9 e-mails from you in the issues list pending replies. Seven are 
in the RDFa feedback folder. Two are regarding section 1.5.4.

If you sent feedback to the WHATWG about other topics, and you still 
haven't had a reply, then please let me know. This should not happen.

If you sent feedback to the HTMLWG on other topics and didn't receive a 
reply from me, then that is because the chairs of the group didn't report 
that feedback to me. I was informed that it was not my responsibility to 
acknowledge and respond to all feedback on the HTMLWG list, but that 
issues would be tracked by the chairs and specific bugs filed in Bugzilla 
for things I should respond to. While I do sometimes respond or track 
individual e-mails, I usually only do this for e-mails that report 
specific problems in the spec (i.e. directly actionable feedback).

What suggestions have you made but not received feedback for?


> Having one person own the issues list, and having the same person set up 
> to win every controversial argument, is not consistent with the W3C 
> notions of consensus.

I agree entirely, and we've never been in either of thoes positions in the 
HTML working group (and only the first of those positions in the WHATWG).


> Your take is different than how I read
> 
> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
> 
> First, my read of the Last Call itself:
> 
> * The announcement begins a review period that SHOULD last at least three
> weeks but MAY last longer
> * Ordinarily, reviewers SHOULD NOT raise substantive technical issues about a
> technical report after the end of a Last Call review period
> * Ideally, after a Last Call announcement, a Working Group receives only
> indications of support for the document
> 
> I read the above to mean that we should enter Last Call having done 
> everything we know possible possible to ensure that Candidate 
> Recommendation is only one month away, but be prepared for the 
> possibility that it is three months.  I realize that we might not even 
> make that, and I imagine that there are others that have done far worse, 
> but still: that's three months, not three years.

Ah, that does explain why we have been talking at cross-purposes.

Typically in the W3C any major specification (on the scale of HTML or CSS) 
will go through multiple "Last Call" steps, over a period of several 
years. What you describe above is what in practice is called the "last 
Last Call", which according to the timetable I'm working to would happen 
sometime in early 2012, before the CR transition.

I agree entirely with the sentiment that there's no way we will be able to 
reach _that_ point by October 2009 with the document I'm editing.


> How you proceed is up to you, but as you have asked for further advice, 
> here is how I would proceed if I were in your position.  I would work to 
> get the W3C issues list to near zero by the AC meeting, and by that I 
> mean all of the open issues and a substantial down payment on the raised 
> ones.

Looking at just the OPEN issues:

ISSUE-4   HTML Versioning and DOCTYPEs
ISSUE-13  Handling HTTP status 401 responses / User Agent Authentication Forms
ISSUE-31  What to do when a reasonable text equivalent is unknown/unavailable?
ISSUE-60  Reuse of 1999 XHTML namespace is potentially misleading/wrong

I'm not aware of any proposals that haven't been shot down or retracted 
for these. I wouldn't even know who to approach to get a ball moving.


ISSUE-32  how to provide a summary of a table, e.g. for unsighted navigation?

This is an issue I plan to look at in the coming month (there's new data 
on this).


ISSUE-35  Need to define processing requirements for aria states and properties when used in html

I plan to look at this in April. It's blocked on the ARIA work right now.


ISSUE-37  Integration of SVG and MathML into text/html

Blocked on the SVGWG.


ISSUE-55  head/@profile missing, but used in other specifications/formats

Short of ignoring research and just accepting the proposal to re-add 
profile="" despite the objections, I don't know what to do. There doesn't 
really seem to be a compromise position to be found here, since the 
proposal on one side is to have dedicated syntax to allow people to do 
something, and the proposal on the other side is to always allow people to 
do that thing. (One obvious idea, allowing the attribute to be used with 
no meaning, seems like it would sacrifice language coherence for political 
convenience, which would be a bad compromise. It would also probably not 
actually address the needs or desires of either "side".)


ISSUE-56  Assess whether "URLs" section/definition conflicts with Web architecture
ISSUE-63  Origin header: in scope? required for this release?

These issues are going to be moot since the relevant sections are being 
removed from the draft.


Other than issue 32, how can I make progress on these?


> And unlike you, one of the first actions I would take is to address that 
> obnoxious introduction.

I really can't prioritise editorial stuff over issues with actual 
normative requirements, sorry. People are implementing the spec, and 
shipping it, and if we don't fix the spec when they mention problems we 
might find ourselves forced into things we don't like.


> April through July we would do a linear scan, week by week, section by
> section, through the document allowing people to identify portions of the text
> which are subjective, controversial, or unproven.  At which point the chairs
> would work with the group to determine consensus, and you would keep on top of
> the input as we go.

I have enough input already to last until October (assuming the rate of 
new input stays constant), so I doubt I'd be able to deal with new 
feedback in real time, for what it's worth. But I'm certainly willing to 
try, so long as it is understood that feedback from implementors has to 
take priority.

I'm all for it, though, if you can get people interested in doing this. 
The group has tried this kind of thing before (once when the working group 
first adopted the spec, once at the last TPAC), but in both cases the 
effort fizzled out and people lost interest.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 22 February 2009 05:09:23 UTC