- From: <bugzilla@jessica.w3.org>
- Date: Tue, 26 Apr 2011 22:27:17 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239 Ian 'Hixie' Hickson <ian@hixie.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW --- Comment #21 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-04-26 22:27:13 UTC --- So I started doing as suggested in comment 20, and basically guess at what changes I had to make, but I still couldn't do it. There are a number of changes in [1] that are simply unsupported by the CP and not mentioned by the decision [2], and which seem to me to be either unintentional mistakes or simply nonsensical. For example: - The new API fails to handle magnification for interactive graphics that don't have a caret or selection, e.g. check boxes. Magnification only seems to occur if the script calls setCaretSelectionRect(). - drawFocusRing() is described sometimes as only working if the focused element is what is passed to the method, and sometimes as working even if the element passed to the method has a focused ancestor, even if the ancestor is also an ancestor of the <canvas> itself (e.g. <body>). - caretBlinkRate() is defined to return a rate in milliseconds, which doesn't make sense. - caretBlinkRate() is required to return a non-specified negative value in certain cases. This is an interoperability nightmare. - The example is far bigger than could possibly be useful. - The example in the proposed text is explicitly marked as needing changes! - The proposed spec text uses terms like "rectangular left edge" which are meaningless (a side's edge can't be rectangular, by definition). - The "selection position" term's definition doesn't handle bidi. - The caret API isn't sufficient for addressing modern accessibility and internationalisation needs, because it requires that the caret blinking be drawn by the app, which means it can't support Windows accessibility wide carets, bidi carets, or indeed anything other than what the author draws (e.g. on RISCOS an app wouldn't follow the platform-specific caret convention). - The entire caret aspect of this API simply won't work, because it doesn't do anything useful for authors who aren't trying to address accessibility issues. We know this is a problem, just look at longdesc. - The RFC2119 requirements make no sense. For example, there is a "must" requirement on what authors are to render! I've tried to get answers about these things from the chairs, but without much luck. At one point Maciej even said "I guess I should have read the text". It is simply absurd that decisions would be made by people who are not even reading the proposals. I cannot in good faith make this edit. It's not that I disagree with the decision, it's that the decision makes no sense. (For the record, there's also some issues that I disagree with and that I think are poor design, but that aren't nonsensical: - caretBlinkRate() is a method, not an attribute. - caretBlinkRate() only returns one number, whereas a blinking behaviour needs two numbers to be fully described, and that's assuming simple blinking carets. - The "caret position" term clashes with an existing term in the HTML spec. These wouldn't stop me making the edit, though; I'd just file bugs on them or put up with them, as I have with some of the other decisions.) [1] http://lists.w3.org/Archives/Public/public-html/2011Apr/att-0657/canvascarseldecision20110426.html#dom-context-2d-setCaretSelectionRect [2] http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Tuesday, 26 April 2011 22:27:18 UTC