Re: Working Group Decision on ISSUE-91: Removing the aside Element

Sam Ruby wrote:
> On 06/01/2010 08:03 PM, Shelley Powers wrote:
>> Sam Ruby wrote:
>>> On 06/01/2010 06:45 PM, Shelley Powers wrote:
>>>>
>>>> Neither of the decisions addresses the other HTML audiences, such 
>>>> as web
>>>> developers, designers, tech writers, tool builders, and so on.
>>>
>>> I personally spent considerable time scanning the web to see if I
>>> could substantiate the claims that these elements were too complex for
>>> these audiences. What I found instead was plenty of instances where
>>> people were welcoming these changes, often eagerly.
>>
>> Most of the writings were either by folks representing one of the
>> browser companies, or sites that jump up and down for anything that's
>> remotely "HTML5" -- because it's so uber cool.
>>
>> The real point is: who asked for these elements either in the WhatWG
>> group, or in the W3C? That's where you should have looked, Sam. What
>> were the requirements for these elements? That's what I tried to
>> demonstrate in my change proposal. Which, from your recent decision, was
>> completely ignored, since you only addressed the objections to the
>> counter-proposal, not the change proposal itself. Unless you think
>> Henri's one line was sufficient to disregard what I wrote.
>
> A rationale was provided, in the form of a change proposal, for these 
> elements.  Both change proposals were presented in the context of the 
> W3C.  Both change proposals were carefully read.
>
>> People have also written positively about datagrid, and it's not in
>> HTML5. People have also written positively about HTML5's geolocation --
>> which just goes to show how random Google searches should never be
>> introduced as some form of justification.
>>
>> It is not the co-chairs responsibility to provide the proofs, only judge
>> based on the merits of the arguments provided. And a Google search link
>> is poor proof.
>>
>> You should addressed the proposals and the written objections. That you
>> did not, that you only addressed the objections, demonstrates you all
>> had made your decisions before the survey and were just going through
>> the motions.
>
> The chairs are attempting to follow the W3C process[1], and are 
> therefore seeking to favor proposals that create the weakest objections.
>
> The process loosely is: we coach people to write the strongest 
> proposals possible, then we seek amicable consensus where possible, 
> and when this is not possible, we seek objections to the proposals, 
> and then seek the proposal that creates the weakest objections.
>
>>> As an aside, I personally find claims made by a party that these
>>> elements may be too complex for a third party to be weaker than claims
>>> made by the persons affected. If such people were to step forward and
>>> detail actual impact that affects them personally then that could very
>>> well be treated as new information.
>>
>> As I wrote, the concepts are based on the print world, and I made the
>> argument that this doesn't translate well to the web world. For
>> instance, how to you "tangentially" relate a figure or aside to the web
>> content? Just using the aside element? You can, in the print world. You
>> can't in the web world. But you didn't address this because it was in
>> the change proposal -- which evidently, you didn't read. Or at least
>> didn't feel was worth addressing directly.
>
> I did read your proposal, and specifically was looking for objections.
>
> "Can't in the web world" could be read as an objection (and if so 
> would have needed to be substantiated), but isn't what you said.  What 
> you said was:
>
>   "There's a good reason for specialized figure handling in the print
>   world, but not for web pages. Because we don't have a good 
> understanding
>   of why we have figure, we can't determine what it should contain. We
>   only have to look at the discussions about what should be allowed 
> within
>   the figure element to discover that no one really has a clear idea of
>   what this element is for, or how it will be used. Well, other than
>   something with an optional caption, that is tangentially related to the
>   content of the page (as if "tangentially" has a great deal of 
> meaning in
>   a web context, considering that anything can be tangentially related to
>   anything else with the simple addition of a link)."
>
> To me that is not clearly an objection.  Rather I see that as a valid 
> reason to request that a rationale be provided for the figure element, 
> and as such we solicited a counter proposal.  And a the counter 
> proposal produced provided rationale.
>
Then you and I have to disagree. I was providing an argument for 
removing the element, and you, seemingly, were looking for an objection. 
I'm not sure what to, but I'm assuming to including the element.  Or to 
the editor's decision?

You'll need to provide additional information in your decision policy: 
don't make an argument for a change, provide objections to the editor's 
decision. Or at least, that's now my interpretation. So how does one 
object to the following:

" Rationale: I actually agree with Shelley on this, and that's what 
HTML5 used to say.
   However, it is one of the very few topics which got a _huge_ outcry 
from Web
   authors around the Web, demanding that <figure> be allowed to contain 
basically
   any flow content (including sections, headings, paragraphs, lists, etc).
   That's why the spec says what it does now. "

So, following Henri's example, I could have saved myself time, and just 
wrote:

Allowing everything in the figure element is going to make it so 
confusing, and so misused that enormous numbers of web developers and 
authors are going to have problems with it -- and we should never 
confuse web developers and authors. But not allowing everything will 
make some people mad, so let's get rid of it.



> Cycling back around to your (new?) point: "You can't in the web 
> world", do you have new evidence to present that substantiates this 
> assertion? I'll note that the existing counter proposal contains 
> specific examples where (it is asserted) this element can be applied 
> in the real world.
>
But that's to meet one definition of the element -- material that isn't 
relevant to the story and can be skipped over. That doesn't address the 
tangential relationship, which is also part of the element definition. 
How would the figure be associated with the main content, when it's in a 
separate page? And how does this differ from, say, a link?

You also didn't address the third argument: that we already have the 
means to do the exact same functionality now, which I did provide as 
example. Unless you see no problem with adding dozens, hundreds of new 
elements with every new version of HTML?

>> Something for people to keep in mind, now -- the chairs don't judge
>> based on the proposals or counter-proposals, only the objections raised
>> in the surveys for both. I don't believe this was clearly stated in the
>> decision process.
>
> As previously stated, the chairs are attempting to follow the W3C 
> process[1], and therefore after all attempts at amicable resolution 
> fail, seek to favor proposals that create the weakest objections.

Which explains why you didn't reference anything I wrote in your decision.

Well, you've done your duty and does no good to continue this discussion 
this in the group. I'm not even a member of the group anymore.

Shelley

Received on Wednesday, 2 June 2010 01:32:40 UTC