Re: summary attribute compromise proposal

On Aug 4, 2009, at 7:24 PM, Maciej Stachowiak wrote:
>>> 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.

If I wanted to refute such a proposition.  I don't.

The proposition I refuted was that the HTML5 alternatives satisfy
all of the use cases for @summary.  That is refuted by a single
use case that is not satisfied: a simple existence proof.

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

Right, so your question is not relevant.  Proper use of @summary is
never poor practice.

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

Fine. So, when we take a vote on Ian's change to HTML table's @summary
and find that there is no consensus for that change in the WG, then
Ian's change to HTML will be removed from the draft prior to its
next publication.  Right?

....Roy

Received on Wednesday, 5 August 2009 07:25:47 UTC