- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 23 Mar 2010 23:25:29 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-html@w3.org
Hi Ian, Thanks for the Change Proposals. Would you mind posting each as a separate message, so I can have a distinct URL for the issue status list? (I'd rather not link this one email for four different issues.) Regards, Maciej On Mar 23, 2010, at 10:33 PM, Ian Hickson wrote: > > ISSUE-31 > ======== > > SUMMARY > There is no problem and the proposed remedy is to change nothing. > > RATIONALE > There is no problem. > > 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. > > DETAILS > Change nothing. > > IMPACT > > POSITIVE EFFECTS > Having authoring advice will help advise authors. > Having conformance requirements independent of AT APIs will ensure > that > authors are encouraged to write documents that are optimal even for > users > that do not use ATs. > > NEGATIVE EFFECTS > None. > > CONFORMANCE CLASS CHANGES > None. > > RISKS > None. > > > ISSUE-41 > ======== > > SUMMARY > There is no problem and the proposed remedy is to change nothing. > > RATIONALE > "Decentralized extensibility" is not a problem description. > > The issue description says that "The HTML5 specification does not > have a > mechanism to allow decentralized parties to create their own > languages, > typically XML languages, and exchange them in HTML5 text/html > serializations", but to all appearances this is a good thing, not a > problem. Why would we want to encourage vendors to create proprietary > languages and exchange them as text/html? The whole point of having a > standard is that people shouldn't do that. > > Another change proposal suggests a convention should be provided for > preventing vendor-specific non-standard extensions from clashing with > themselves and future standard development. This is a real problem, > but it > is inappropriate to address this problem via the change proposal > process > since it corresponds to an open bug and does not have any bearing on > the > topic given by the issue description (as quoted above): such non- > standard > extensions would by definition not be "allowed"; they would merely be > handled by the provision of a convention for experimentation in non- > validating documents (as, for instance, with CSS vendor prefixes). > > DETAILS > Change nothing. > > IMPACT > > POSITIVE EFFECTS > By not providing solutions without corresponding problems, we avoid > the > danger of designing solutions that do not address any real problems. > We > also avoid encouraging people to use these solutions to address > problems > that either should not be addressed at all, or to address problems > that > should be addressed in other ways that are far more appropriate. > > NEGATIVE EFFECTS > None. > > CONFORMANCE CLASS CHANGES > None. > > RISKS > None. We can always add further extension mechanisms later if an > actual > problem is found to exist after all. > > > ISSUE-80 > ======== > > SUMMARY > There is no problem and the proposed remedy is to change nothing. > > RATIONALE > There is no problem. > > Another change proposal suggests disallowing the use of the title="" > attribute to provide titles for images, instead requiring the use of > separate elements for this purpose. This makes writing accessible > pages > harder and therefore is likely to have negative effects on the overall > accessibility of the Web. > > DETAILS > Change nothing. > > IMPACT > > POSITIVE EFFECTS > None. > > NEGATIVE EFFECTS > None. > > CONFORMANCE CLASS CHANGES > None. > > RISKS > None. > > > ISSUE-88 > ======== > > SUMMARY > There is no problem and the proposed remedy is to change nothing. > > RATIONALE > There is no problem. > > Another change proposal suggests a number of changes, but those > changes > have by and large already been made and therefore it is hard to > provide > coherent counter-arguments to the remaining differences: it isn't > clear > which are merely editorial choices and which are intended to be actual > proposed changes. > > DETAILS > Change nothing. > > IMPACT > > POSITIVE EFFECTS > None. > > NEGATIVE EFFECTS > None. > > CONFORMANCE CLASS CHANGES > None. > > RISKS > It is possible that some of the changes in the other change proposal > would > be worth making, but it is hard to tell which changes that would be > since > that proposal is out of date. > > -- > Ian Hickson U+1047E ) > \._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _ > \ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'-- > (,_..'`-.;.' >
Received on Wednesday, 24 March 2010 06:26:27 UTC