Re: AuthConfReq: Presentational Markup

On 03/27/2010 04:43 PM, Maciej Stachowiak wrote:
>
> On Mar 27, 2010, at 5:17 AM, Sam Ruby wrote:
>
>> The reasons given for disallowing presentational markup given are:
>> - The use of presentational elements leads to poorer accessibility
>> - Higher cost of maintenance
>> - Higher document sizes
>>
>> To explore this, I offer this nearly perfect specimen of markup:
>>
>> http://diveintomark.org/archives/2007/06/30/irony
>>
>> And draw attention to two parts:
>>
>> <b style="background:transparent;color:red">1984</b>
>> <strike>the</strike>
>>
>> The former conforms to the author conformance requirements present in
>> the document. How does this lead to greater accessibility than the
>> alternative? How does it reduce maintenance costs? How does it reduce
>> document sizes?
>>
>> The latter does not conform to the author conformance requirements
>> present in the document. How is this less accessible than the
>> alternative? How does it increase maintenance costs? How does it
>> increase document sizes?
>
> It should be noted that the rationale for author conformance
> requirements explicitly calls out the style attribute as a piece of
> presentational markup that is allowed notwithstanding the general
> reasons for the ban:
>
> <http://dev.w3.org/html5/spec/Overview.html#presentational-markup>
>
> "The only remaining presentational markup features in HTML are the style
> attribute and the style element. Use of the style attribute is somewhat
> discouraged in production environments, but it can be useful for rapid
> prototyping (where its rules can be directly moved into a separate style
> sheet later) and for providing specific styles in unusual cases where a
> separate style sheet would be inconvenient. Similarly, the style element
> can be useful in syndication or for page-specific styles, but in general
> an external style sheet is likely to be more convenient when the styles
> apply to multiple pages."
>
> So you could argue that this exception is not well justified (and style
> should be banned too), or that the rationale for any presentational
> markup to be banned is not well justified, or that the style attribute
> and stye element are the wrong place to draw the line. However, I am not
> sure it is instructive to compare these two pieces of markup against the
> criteria for presentational markup in general. The spec explicitly
> acknowledges that the style attribute may suffer all the problems of
> presentational markup, but gives specific reasons for granting it an
> exception.

The rationale provided listed a bunch of reasons why the presentational 
markup (e.g., the <font> tag) was disallowed, and I cited an example why 
not a single one of those reasons applied.  In response to Anne[1], I 
suggested that either the rationale was incomplete, or that the 
rationale needs to be challenged.

I feel that is a fair thing to do.

> Second, I am not sure examining an individual case in isolation is the
> best way to investigate the validity of this item of rationale. The
> rationale in Section 1.9.1 does not say that every single use of
> presentational markup leads to poor accessibility. In fact, it
> explicitly acknowledges that in some cases, use of presentational markup
> may lead to acceptable accessibility outcomes. What it argues is that
> use of presentational markup, particularly habitual use to the exclusion
> of semantically appropriate elements and CSS, *tends* to result in worse
> accessibility outcomes. The argument, as I understand it, is that free
> use of presentational markup creates negative externalities, therefore
> it should be disallowed except in cases where there is a good reason to
> allow a particular construct.
>
> Since we've had a few religion-themed analogies on this thread already,
> perhaps the one to cite here is "building a wall around the Torah". This
> term refers to the Jewish religious rulemaking tradition where the
> original proscription is quite narrow, but Rabbis have over the years
> created a broader rule that is perhaps more restrictive than necessary,
> but where it is much easier to tell if you are actually following it,
> and harder to violate it by itself. For example, the biblical
> commandment, "thou dost not boil a kid in its mother's milk" is expanded
> to a rule where no meat may be eaten with any dairy product, or even
> from the same plate.

I think that perfectly sums up the situation here.

I have two children.  While I have been tempted on a number of 
occasions, I can honestly say that I have yet to boil either.  I 
routinely combine meat and dairy products.  Mmmm, cheeseburger.

I personally know of others that follow the broader rule that you 
describe, but I have no wish that such rules apply to me.

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

My central thesis is that banning is not the appropriate mechanism for 
markup that works interoperably and is widely and willfully used.  You 
are free to campaign against cheeseburgers, but are not free to outright 
ban their sale.

Banning should have a rather high bar.  Any markup that is banned must 
have significant negative consequences and we need to be confident that 
any such use is not intentional.

I (continue to) offer as an alternative the notion of identifying 
separately those notions that are felt to be Best Current Practices from 
those that are Author Conformance Criteria.

> Note: I am not sure if I personally accept the argument against
> presentational markup in full. I am still mulling it over. In
> particular, I think there may be presentational constructs where the
> accessibility argument almost never applies, and where benefits to the
> author are highly dependent on specific circumstances, to the point that
> a blanket ban does not help authors on the whole. Also, I am not sure we
> have necessarily identified all cases where the potential benefit to
> using a particular construct exceeds the negative externality. However,
> I think it is important to fairly present the argument made in the spec,
> and to address it on its own terms.
>
> Regards,
> Maciej

- Sam Ruby

[1] http://lists.w3.org/Archives/Public/public-html/2010Mar/0712.html

Received on Sunday, 28 March 2010 12:25:06 UTC