- From: <bugzilla@jessica.w3.org>
- Date: Fri, 04 Mar 2011 18:24:06 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11956 --- Comment #5 from steve faulkner <faulkner.steve@gmail.com> 2011-03-04 18:24:05 UTC --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > What is the use case for allowing presentation on all elements? > > Some answers to that question can be found inside the request to 'Allow > role="presentation" to override the default role of any element', which was > filed as bug 10919 by Martin Kliehm, and which resulted in the current > permission to use 'presentation' on any element that you now are questioning. > > If you disagree with that general permission to use 'presntation' on any > element, then it seems that you EITHER need to re-open 10919 needs to be > reopened. OR ELSE, file bugs about each element for which it should not be > permitted. hi leif, i am aware of bug 10919 it does not provide use cases for using presentation on form controls or links. so it doesn't provide any use cases to cover these, the rationale of the editor was; "It seems that the ARIA spec is very confused on this issue, but in the interests of expediency, and under the assumption that the ARIA spec will be corrected to match implementations, I've changed the spec to allow role=presentation everywhere." I don't believe 'expediency' to be an acceptable rationale. as to your statement: "then it seems that you EITHER need to re-open 10919 needs to be reopened. OR ELSE, file bugs about each element for which it should not be permitted." whose rules are these? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 4 March 2011 18:24:07 UTC