[Bug 11239] Canvas support accessible caret tracking independent of Focus Ring tracking

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