W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: [DRAFT] Heartbeat poll - update 2

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 3 Aug 2009 01:05:02 +0000 (UTC)
To: Sam Ruby <rubys@intertwingly.net>
Cc: HTML WG <public-html@w3.org>, "Michael(tm) Smith" <mike@w3.org>, John Foliot <jfoliot@stanford.edu>
Message-ID: <Pine.LNX.4.62.0908030037380.28566@hixie.dreamhostps.com>

The questions in this e-mail are not rhetorical. I really would like to 
understand exactly how what you are proposing is supposed to affect the 
working group and the HTML5 spec.

On Sun, 2 Aug 2009, Sam Ruby wrote:
> Ian Hickson wrote:
> > 
> > > Given this information, there should be absolutely no confusion over what
> > > the poll is about.
> > 
> > I would like to request that when the vote is actually put up,
> 
> It will be a poll not a vote.

What is the difference?


> > there be a clear statement about exactly what each option means in terms of
> > what edits I should make to the spec to match the resulting consensus.
> 
> I honestly don't know how much clearer John Foliot can be[1].

Which of the two options corresponds to what John is asking for and which, 
if any, corresponds to what the HTML5 spec already says? What parts of 
what HTML5 says would this poll set in stone, if any? If we have 
overwhelming support for an option that matches what HTML5 says, and then 
information comes up supporting John's position, would having had this 
poll preclude changing the spec to take into account that new information? 

If the poll goes the other way, does that mean we are intentionally 
ignoring the available research?


> 1) add @summary as a conformant attribute of the table element (4.9.2.1)

Surely the position within the spec is a purely editorial concern? Is the 
vote/poll in part about where the attribute should be included? What if 
there is later an editorial change that means that we don't have sections 
for each element but instead have a big table, or something?


> 2) add explanation of @summary

Is this a different explanation of summary than that already present in 
the spec? If so, in what material way is it different?


> 3) provide cautionary message that @summary is under review and may be
> made obsolete (aka class="XXX")

So this doesn't resolve the issue? How are we going to actually resolve 
the issue, if we're neither using reasoned arguments and research, nor a 
vote?


> 5) remove @summary from 12.1 Conforming but obsolete features

This appears to be in contradiction to both of the options you listed -- 
this would neither leave the attribute deprecated or obsoleted. This may 
be the source of my confusion.


> 4) add example of @summary usage

This change would be a natural result of change 5.


> My read of John's objections is that is was not his intent to produce a 
> fork, nor was it his intent to become an editor, but it was his intent 
> to get these specific changes into this specific Working Draft.

I've already told John how he can do that: provide compelling reasons for 
it. So far he has provided not a single unrefuted argument and zero 
research in favour of his request. If I agree to his request, and then 
somebody requests the opposite, how do I decide between them? That's not a 
rhetorical question; I really would like your advice here.


> Propose a draft that addresses John's concerns, and we can discuss that 
> instead, and possibly not even have a poll at all.

I don't understand John's concerns. He hasn't explained them. He has just 
made unsubstantiated demands.

I go into more detail on this here:

   http://lists.w3.org/Archives/Public/public-html/2009Aug/0056.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 3 August 2009 01:06:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:43 GMT