- From: Larry Masinter <masinter@adobe.com>
- Date: Thu, 7 Jan 2010 07:56:18 -0800
- To: David Singer <singer@apple.com>, John Foliot <jfoliot@stanford.edu>
- CC: "'Jonas Sicking'" <jonas@sicking.cc>, "'Denis Boudreau'" <dboudreau@webconforme.com>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'HTML WG Public List'" <public-html@w3.org>
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