Re: AuthConfReq: Presentational Markup

On 03/27/2010 11:51 AM, Tab Atkins Jr. wrote:
> On Sat, Mar 27, 2010 at 5:17 AM, Sam Ruby<rubys@intertwingly.net>  wrote:
>>   <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?
>
> This is a relative rarity, a place where a very specific presentation
> is desired in a specific place, with no semantic meaning behind it.
> It was intended solely to mimic what the original Apple tshirt looked
> like.  I don't think optimizing for that case is important.  As well,
> in many cases like this more styling will be desired than what
> presentational markup can present anyway, and so going with the @style
> attribute the whole way through makes things a bit simpler.
>
> Note, though, that accessibility is not affected in this case (since
> it was a purely stylistic issue), maintenance costs are equal (I don't
> think<font color=red><b></b></font>  is any easier to maintain there),
> and document size is roughly equivalent.  So, in this rare case, it's
> roughly neutral with respect to the stated reasonings.  This is not
> the case with the much more common uses of presentational elements.
>
>> 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?
>
> As stated by Karl Dubost, that could have been done equally well with
> <del>, which *does* have better theoretical accessibility, is roughly
> equal in maintenance, and is very slightly shorter in pure code
> (though not enough to care about).
>
> There may be, theoretically, a reason to keep<strike>  even though it
> appears to just be a presentational form of<del>.  We found reason to
> keep<i>  and<b>, after all.  If you can find one, great.  But if not,
> then it's merely an irrelevant presentational copy of an existing
> element.  We specify how to handle it in legacy documents, but don't
> allow its use in new ones.

Or, what, I shall taunt you a second time?

What new mime type do you propose for this?

While it is a controversial premise, I agree with the notion that a 
number of people in this working group share, namely that the web is 
essentially unversioned.  Once something is permitted, it can't lightly 
be taken away.

The text/html MIME type has a specific meaning.  There have been tens of 
billions of documents authored that conform to that mime type.

Net: the goal to reduce presentational markup is a noble one that I 
enthusiastically support.  The means selected, namely mandatory author 
conformance criteria for the MIME type of text/html, is not something I 
can support.

> ~TJ

- Sam Ruby

Received on Saturday, 27 March 2010 17:22:02 UTC