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