obsoleting and the text/html MIME type (re Taking another round at @summary)

David,

I disagree that:
"If a facility is so rarely used that it's unlikely
 that, if looked for, it will be found"

is, by itself, a reason for removing a HTML4
feature. The same condition holds for any new
proposed feature. Frequency of use is not
a deciding factor, as long as there is _some_
legitimate use. 

I do agree that:

" when used it is used incorrectly or 
 unhelpfully"

is a reason for *changing the definition* of
a feature, and only when impossible to fix,
obsoleting or deprecating the feature.

I think there needs to be clear evidence 
and consensus that misuse is the norm; that
is, the default should be to retain HTML 4
features.

My reasons come from the rules for updating a MIME
type registration combined with the resolution
of ISSUE-53.

The requirements for changing a MIME type
registration:
http://tools.ietf.org/html/rfc4288#section-9

 Changes should be requested only when there
 are serious omissions or errors in the published
 specification.  When review is required, a
 change request may be denied if it renders 
 entities that were valid under the previous 
 definition invalid under the new definition.

Review is required because

 The same procedure that would be appropriate
 for the original registration request is used 
 to process a change request.

and the registration of text/html requires
(IETF) community review.

The resolution of ISSUE-53 was made with the 
commitment that the HTML5 document intended
to adequately describe and allow conforming
HTML4 content such that previously conforming
HTML4 content would remain conforming, and that
any cases where that wasn't true would be
treated as bugs and fixed.

If HTML5 makes previously conforming HTML4
content non-conforming in order to remove
features that are rarely used, then we should
re-open ISSUE-53 to revise the MIME type
registration to explicitly allow documents
that conform to HTML4. 

Larry
--
http://larry.masinter.net


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of David Singer
Sent: Wednesday, January 06, 2010 10:46 AM
To: John Foliot
Cc: 'Jonas Sicking'; 'Denis Boudreau'; 'HTML Accessibility Task Force'; 'HTML WG Public List'
Subject: Re: Taking another round at @summary


On Jan 5, 2010, at 17:06 , John Foliot wrote:
> 
> How does the rarity of @summary's usage today, or instances when the
> author has done things wrong, negate @summary's usefulness?  All that your
> data proves is that currently this useful attribute is not being used to
> its full advantage - nothing more, nothing less.
> 



I think that this has been discussed as a general point related to summary, alt, and a number of other designs.  I'll try to re-create the argument very briefly, to avoid repetition.

If a facility is so rarely used that it's unlikely that, if looked for, it will be found, and/or when used it is used incorrectly or unhelpfully, so that on the rare occasions it is found, it's useless, then those needing it will give up looking for it, and UAs will give it relying on it as a way to help users needing accessibility provisions.  At that point, it's getting useless.

I don't *know* that this has happened with summary, though some have argued that it has.  Note that experiments that show that when it is used correctly, it's helpful, do not negate the rarity/pollution problems above.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 7 January 2010 15:57:04 UTC