- From: Shelley Powers <shelley.just@gmail.com>
- Date: Wed, 24 Mar 2010 07:51:20 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org
I hope you and the other co-chairs agree that these are not sufficient change proposals. The format is followed, but Ian vaguely references other change proposals without links. In fact, I'm not sure he's even addressed actual change proposals, or the change proposals specific to the issue. And it would seem that all that is needed for a good rationale is that he doesn't like the other proposal(s). Whatever ones they are. His rationale seems to be more along the vague assertions that the other change proposals are wrong, or bad, or he knows better. Frankly, they seem almost an insult to both process and the group. I'm assuming that you and the co-chairs are reviewing these and will apply the same stringent requirements from Ian as you've required from the rest of us. If there are no good rationales for any of these items, I do have to wonder now about the overall quality of the documents we are producing. We should be concerned. Shelley On Wed, Mar 24, 2010 at 2:56 AM, Maciej Stachowiak <mjs@apple.com> wrote: > > 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 12:52:02 UTC