Hixie at 03:10, 16 June 2011

2011-06-16T03:10:12Z

← Older revision		Revision as of 03:10, 16 June 2011
Line 34:		Line 34:
	Argument against redundant requirements: This section contains requirements that are redundant with the [...] specification. Having specifications state redundant requirements is very poor form for specification writing, as it leads to unintended ambiguities (where different specifications unintentionally state things slightly differently), and thus interoperability failures. Implementors and advocates who are not fully engaged with the standards process are likely to try to find meaning in the unintended differences, with often quite unexpected conclusions (just look at the folklore that has sprung up around the spelling of the specification's name — is there a space between the "HTML" and the "5" or not? Entire yarns of pseudo-history have been spun around this question). These problems can be especially pernicious because to advocate that an implementor who follows one spec should instead follow the other requires more than the usual standards-compliance advocacy (and indeed, can be at odds with that advocacy, since it requires violating one spec to follow the other).		Argument against redundant requirements: This section contains requirements that are redundant with the [...] specification. Having specifications state redundant requirements is very poor form for specification writing, as it leads to unintended ambiguities (where different specifications unintentionally state things slightly differently), and thus interoperability failures. Implementors and advocates who are not fully engaged with the standards process are likely to try to find meaning in the unintended differences, with often quite unexpected conclusions (just look at the folklore that has sprung up around the spelling of the specification's name — is there a space between the "HTML" and the "5" or not? Entire yarns of pseudo-history have been spun around this question). These problems can be especially pernicious because to advocate that an implementor who follows one spec should instead follow the other requires more than the usual standards-compliance advocacy (and indeed, can be at odds with that advocacy, since it requires violating one spec to follow the other).

	[[Category:W3C Issue]		[[Category:W3C Issue]]

Hixie: Created page with '=== Notes for future change proposals === * e-mails relating to ISSUE-32 (summary=""): [http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0158.html] [http://lists.w3....'

2011-06-16T03:09:58Z

Created page with '=== Notes for future change proposals === * e-mails relating to ISSUE-32 (summary=""): [http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0158.html] [http://lists.w3....'

New page

=== Notes for future change proposals ===

* e-mails relating to ISSUE-32 (summary=""): [http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0158.html] [http://lists.w3.org/Archives/Public/public-html-a11y/2010May/0055.html]
* e-mails relating to ISSUE-103 (srcdoc="" in XML): [http://lists.w3.org/Archives/Public/public-html/2010Mar/0612.html]
* e-mails relating to ISSUE-110 (IANA registrations): [http://krijnhoetmer.nl/irc-logs/whatwg/20100730#l-875]
* e-mails relating to text editors using canvas: [http://www.w3.org/mid/4702261C-9874-4B2D-9A5C-3FBFCE4C75B6@googlemail.com]

==== ISSUE-31 (alt="") ====

* e-mails: [http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0321.html] [http://lists.w3.org/Archives/Public/public-html/2008Aug/0759.html]

* arguments from the old change proposal:

Another change proposal suggests removing all advice for authors writing
alternative text, moving it to other documents. Historically, we have
tried that (HTML4 had virtually no advice) and we have found it to be a
poor solution: authors assume it is easy to write alternative text and
thus do not attempt to learn anything about it. We need to try having such
information as "in your face" as possible. Having additional documents
would be additionally helpful, but does not preclude having detailed
advice in the HTML spec itself.

A second change proposal suggests allowing otherwise non-conforming
content to be conforming based on the presence of ARIA attributes.
However, this is a layering violation and a language design error. ARIA is
intended to only affect accessibility API mappings (and thus ATs).
Features such as alt="", however, are relevant far beyond AT users, for
example to text browsers. It would be wrong, therefore, to make solutions
that exclusively affect accessibility APIs be a suitable alternative for
solutions that are necessary for UAs that do not use accessibility APIs.

==== Other issues ====

Argument against redundant requirements: This section contains requirements that are redundant with the [...] specification. Having specifications state redundant requirements is very poor form for specification writing, as it leads to unintended ambiguities (where different specifications unintentionally state things slightly differently), and thus interoperability failures. Implementors and advocates who are not fully engaged with the standards process are likely to try to find meaning in the unintended differences, with often quite unexpected conclusions (just look at the folklore that has sprung up around the spelling of the specification's name — is there a space between the "HTML" and the "5" or not? Entire yarns of pseudo-history have been spun around this question). These problems can be especially pernicious because to advocate that an implementor who follows one spec should instead follow the other requires more than the usual standards-compliance advocacy (and indeed, can be at odds with that advocacy, since it requires violating one spec to follow the other).

[[Category:W3C Issue]

Notes for W3C Issues - Revision history

Hixie at 03:10, 16 June 2011

Hixie: Created page with '=== Notes for future change proposals === * e-mails relating to ISSUE-32 (summary=""): [http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0158.html] [http://lists.w3....'