Re: summary attribute compromise proposal

On Aug 4, 2009, at 6:04 PM, Roy T. Fielding wrote:

>
> The @summary attribute has a purpose which is not satisfied by
> any of the alternatives.  Case closed.

This doesn't convince me to withdraw my proposal or to think that  
wholeheartedly endorsing @summary is obviously the right thing. Your  
use case, though it seems reasonable to me, is an edge case. I haven't  
seen a real example of a site that has a requirement to faithfully  
reproduce written documents while at the same time improving their  
accessibility to the blind; it's possible, but hypothetical and likely  
rare. There is a saying in the legal profession: "hard cases make bad  
law".  In other words, we should be hesitant decide the whole rule  
based on an edge case. I think your example shows there are cases  
where @summary can be a good solution, but does not counter the  
proposition that for many other cases, there are better alternatives.

> I said "the appropriate action by the editor", not what is written
> into W3C process.  There are a lot of things in W3C process that
> are just assumed because they are inherent in the definition
> of "editor".
>
> If Ian wants to claim that he can change anything in HTML for
> which no WG consensus has been obtained, then I'd like to see
> him do so in writing to this list.

I'll do it for him. Our charter says:

"As explained in the Process Document (section 3.3), this group will  
seek to make decisions when there is consensus. We expect that  
typically, an editor makes an initial proposal, which is refined in  
discussion with Working Group members and other reviewers, and  
consensus emerges with little formal decision-making. However, if a  
decision is necessary for timely progress, but after due consideration  
of different opinions, consensus is not achieved, the Chair should put  
a question (allowing for remote, asynchronous participation using, for  
example, email and/or web-based survey techniques) and record a  
decision and any objections, and consider the matter resolved, at  
least until new information becomes available."

<http://www.w3.org/2007/03/HTML-WG-charter>

So, per our charter, it is not only Ian's right but his obligation as  
an editor to make an initial proposal in spec form, and iterate on it  
based on feedback. In the (hopefully) rare case where this doesn't  
achieve consensus, even after iterating, it's the responsibility of  
the Chairs to resolve the matter by putting the question and recording  
a decision. This may not be the best rule, but it is a workable rule,  
and I'd rather go with it than fight over the basic rules of  
engagement. Sorry to play rules lawyer, but we have a pretty clear  
path to resolving disputes, and I think following it will work better  
than citing unwritten rules.

If by calling something "the appropriate action" you're stating merely  
an opinion on what Ian should do, rather than a matter of process  
requirement or moral imperative, then fine, you are entitled to your  
opinion.

>> Further, even if you demonstrated that there are no alternatives in  
>> one particular use case, this would not demonstrate there are no  
>> alternatives for any use case, nor would it refute the case that  
>> the construct is error-prone.
>
> Why would I need to demonstrate that there are no alternatives for
> any use case?  What kind of logic is that?

If you want to refute a proposition of the form, "it's usually a  
better idea to do A rather than B", then a single example where B  
seems like a better choice is not a refutation. Let me express it in  
formal terms so the logic is unambiguous. Let's say A(x) is the  
predicate that "in case x, it's a better idea to do A", and B(x) is  
the predicate "in case, it's a better idea to do B". Proposition: let  
U = {x | A(x) }; let V = {x | B(x) }; |U| > |V|. If you show that ∃y  
y∈V (there exists a y such that y is a member of V, for those of you  
without math fonts), this does not refute the proposition. There is an  
obvious counterexample, namely the case where A has more than one  
distinct member. This kind of logic is first-order predicate calculus,  
for anyone who wants to look up the funny mathy bits. Sorry for  
getting all formal, but a claim of refutation is a very strong claim.  
I think you have added useful information to the conversation, but I  
think it's overselling it to say it's a refutation.

>>> It would therefore be an ERROR for a
>>> validator to warn that the author should seek out alternatives
>>> when those alternatives clearly do not exist.
>>
>> Is it an error to advise authors to use CSS layout instead of  
>> layout tables, even though CSS can't necessarily replicate every  
>> layout that is possible with tables?
>
> I don't follow what you mean here.  A table that has no substantive
> content could certainly be replaced by CSS, but CSS is not a  
> substitute
> for table in general.  I think such warnings have nothing to do with
> validation (style tools like lint do not belong in standards).

To be more clear: most people agree using a table for layout (and not  
to represent actual tabular data) is a poor practice which should be  
discouraged, with CSS layout as the alternative. CSS layout can't do  
every single thing table layout can, but it's still considered sound  
advice to do your layout with CSS instead of with tables, given the  
broader benefit of separating markup and style.

>> You're welcome to make such proposals separately. I'm not sure all  
>> of those specific examples would get consensus. (I do think  
>> <canvas> with no fallback should be a warning or error.)
>
> Why do my proposals require consensus but Ian's proposals do not?

Anyone's proposal requires consensus to become a decision of the  
Working Group (or if consensus is not achievable, a vote). Since Ian  
is an editor, he gets to make his proposals in spec draft form. See  
above. Sam has said he is open to letting anyone become an editor if  
they'd like to make proposals in the form of a spec draft too. Or you  
can just make an informal proposal, like I did.

I am hoping my proposal can find at least rough consensus, and I am  
pretty certain Ian will find it seriously distasteful. So you can't  
paint me as an apologist for doing anything Ian wants.

Regards,
Maciej