Re: AuthConfReq: Presentational Markup

Maciej Stachowiak, Mon, 29 Mar 2010 21:14:00 -0700:
> On Mar 29, 2010, at 12:43 PM, Aryeh Gregor wrote:
>> On Sat, Mar 27, 2010 at 4:43 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> Banning <font> in general, rather than, say, only when used in a way that
>>> actually harms accessibility, is analogous to this reasoning. By having
>>> the blanket ban, we avoid the presumed negative externality, without
>>> having to closely inquire about the particular circumstances of each
>>> use. The latter requires too much judgment for a conformance checker.
>> 
>> Why does this not imply that style="" should be an error as well?  The
>> spec gives reasons for why not all inline presentational markup is
>> banned, but I see no reason given for why only style="" was kept, and
>> not other presentational markup as well.
> 
> It does try to give a reason; you could question whether it is a good 
> reason,

Or one could question whether it is well delivered/justified.

> but it's there. I assume from your wording that you 
> overlooked this rather than merely finding it inadequate:

I assume him to have said that the justification is inconsistent with 
what you said about <font>.

You said: <font> does not need to harm accessibility, it is only that 
to investigate whether it actually does, would be too much work, and so 
we cut the corner and say that <font> doesn't validate. The same 
reasoning could be used about @style: It could harm accessibility, but 
it is too much work to check whether it actually does.

I personally do not think @style in itself harms accessibility anymore 
than <style> or <link rel="stylesheet" * >. But I do think that @style 
could hide the accessibility issues more fundamentally than <element 
class="CSS Hook"> does. E.g. consider Sam's answer to you about feeds. 
[1] When we use a class as a CSS hook, then it is obvious to us that 
styling doesn't work if the external CSS doesn't work. And so we can 
take our measures, based on that. But when we use inline CSS, then we 
might fooled to think that "now we are safe".

(Tab too the opposite approach and justified @style by saying that it 
raises the awareness of using CSS and external stylesheets. [2])

If we forget about what it might cost a validator to provide useful 
validation, and instead concentrate on the *ideal* validation, then I 
would like to suggest that:

@style/CSS(!) should not in itself be treated as an error, unless it is 
used to convey presentational semantics which could just as well be 
delivered via HTML4 presentational attributes (such as @bgcolor and 
@border etc). The same could be said about @border, @cellpadding 
@cellspacing (bug 7468 [3]) and probably some other presentational 
attributes. In these cases, it should be considered a good costume to 
back up the CSS with HTML4 presentational attributes. 

So instead of simply dismissing or allowing @style and instead of 
simply dismissing or allowing HTML4 presentational attribute, one could 
consider if not the HTML4 presentational attributes are there for good 
presentation semantic reasons. And that they therefore ought to be 
permitted used. I think we can justify them based on the principle of 
progressive enhancements. E.g. a background color on a table cell could 
be an important feature which makes the table simpler to read. To rely 
purely on CSS to convey background color of table cells, could lead to 
poor fallback if the table is syndicated.

[1] http://lists.w3.org/Archives/Public/public-html/2010Mar/0792
[2] http://lists.w3.org/Archives/Public/public-html/2010Mar/0778
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7468
-- 
leif halvard silli

Received on Tuesday, 30 March 2010 15:20:08 UTC