W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: Null change proposals for ISSUE-31, ISSUE-41, ISSUE-80, and ISSUE-88

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 23 Mar 2010 23:25:29 -0700
Cc: public-html@w3.org
Message-id: <E4A153C4-DC3D-4175-9E0D-440B00A4178B@apple.com>
To: Ian Hickson <ian@hixie.ch>
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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC