- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 24 Mar 2010 00:56:59 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org
On Mar 23, 2010, at 11:25 PM, Maciej Stachowiak wrote: > 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.) Ian sent individual copies to www-archive. They are now recorded here: http://dev.w3.org/html5/status/issue-status.html#ISSUE-031 http://dev.w3.org/html5/status/issue-status.html#ISSUE-041 http://dev.w3.org/html5/status/issue-status.html#ISSUE-080 http://dev.w3.org/html5/status/issue-status.html#ISSUE-088 I also removed the deadlines from all these issues since the calls for counter-proposals are now expired. Regards, Maciej > > 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 07:57:33 UTC