A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Notes for W3C Issues: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(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....')
 
No edit summary
 
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]]

Latest revision as of 03:10, 16 June 2011

Notes for future change proposals

  • e-mails relating to ISSUE-32 (summary=""): [1] [2]
  • e-mails relating to ISSUE-103 (srcdoc="" in XML): [3]
  • e-mails relating to ISSUE-110 (IANA registrations): [4]
  • e-mails relating to text editors using canvas: [5]

ISSUE-31 (alt="")

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