Re: AuthConfReq: Presentational Markup

I think we can all agree on the following:

1) For most sites, it's better to use predominantly external
presentational markup, such as CSS in a separate file or at least a
<style>, rather than heavily using inline presentational markup.

2) But inline presentational markup is sometimes necessary, or at
least useful.  Sometimes you want to use a particular style only once,
so defining a class and everything is silly.  Sometimes you need to
worry about markup being copy-pasted without external styles, as in
syndication or WYSIWYG copy-paste.

3) Whether presentational markup is placed inline or out-of-band, the
HTML markup used should be semantic.  For instance, if you want to use
a bold red error message once in your entire site, <font
color=red><b>Error!</b></font> and <span style="color: red;
font-weight: bold">Error!</span> are both bad ideas: you should use
<strong> somewhere in addition to the semantics-free parts (still
needed to make it red, in this case).

What I don't see is why any of this (or any other points raised so
far) imply that style="" should raise neither an error nor a warning,
but all other inline presentational markup should raise an error.
This seems disproportionate.  Why is <strong
style="text-decoration:underline">Note:</strong> conforming (with not
even a warning), but <strong><u>Note:</u></strong> an error?

My current opinion is that most legacy (non-style="") inline
presentational markup should raise a warning.  In many cases, CSS is a
simpler way to do things.  <font color=red> is barely shorter than
<span style=color:red>, and removing an entire system of styling from
the recommended subset of the language is a big win for simplicity.  A
warning is all that's needed for pedagogy -- the instructor can just
say students should avoid all warnings as well as errors.  (I could
see a case for keeping legacy presentational markup not even raise a
warning if it's hard to replicate in inline CSS, like <table
cellpadding>.)

But such markup doesn't deserve to be classified as an error.  Errors
should be used primarily for things that authors will actually want to
know about, like markup with surprising behavior; and secondarily, for
things where we have strong reasons to pressure authors (e.g.,
requiring alt text).  That way, average authors will be encouraged to
actually use validators to ensure that their markup behaves as they
expect.  If we raise numerous errors on things that authors don't care
about at all, they won't bother using validators, and we get the
situation we have today -- only a few standards cognoscenti use
validators, along with some companies that want to bill themselves as
standards-compliant.

What we should be aiming for is having most top sites validate
(possibly with warnings).  Not because we've just removed requirements
until they validate, but because we've removed requirements that
authors don't care about to the point that it's actually practically
useful to validate your pages, even if you don't care about
conformance per se.

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.

Received on Monday, 29 March 2010 19:44:22 UTC