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: Wed, 24 Mar 2010 00:56:59 -0700
Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org
Message-id: <DCFC23E5-79F9-439C-927A-3B72C74E2FF8@apple.com>
To: Maciej Stachowiak <mjs@apple.com>

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

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