Bug 11239

I reviewed Ian's patch, wasting yet another one of my mornings. This patch
does not reflect the chairs decision. Despite his patch's inaccuracies it
was my impression that Ian and other members of the working group were
wanting to avoid adding authoring guidance to the specification which he
has done. Nobody should be given carte blanche to write whatever they
please in the HTML specification without process approval. If Ian wants to
make changes like this he should submit a bug later on.


1. Ian's patch introduces technical extrapolations, leading to
inaccuracies, in the following comments. Also, not all applications require
you to enter text need to do all of what he is stating such as implementing
drag and drop. Also, contenteditable sections or standard UI controls don't
do all of what is needed in HTML. Take this one: http://www.lucidchart.com/

How does one enter text in a drawing object with out editable text in the
canvas? This is not an application you would create with a contenteditable
section of HTML. No drag and drop is required. No copy and paste is
required, etc. I could go on but this editorial comment is so limited in
scope (full blown rich text editing) that it should not be in the spec. in
the first place. Worse, this does not reflect the chairs decision.

Ian's editorial comments in the draft:

 "Authors should avoid implementing text editing controls using the +
canvas element. Doing so has a large number of + disadvantages:
+ +

    + +
    Mouse placement of the caret has to be reimplemented. + +
    Keyboard movement of the caret has to be reimplemented (possibly across
lines, for multiline text input). + +
    Scrolling of the text field has to be implemented (horizontally for
long lines, vertically for multiline input). + +
    Native features such as copy-and-paste have to be reimplemented. + +
    Native features such as spell-checking have to be reimplemented. + +
    Native features such as drag-and-drop have to be reimplemented. + +
    Native features specific to the user, for example custom text +
services, have to be reimplemented. This is close to impossible + since
each user might have different services installed, and there + is an
unbounded set of possible such services. + +
    Bidirectional text editing has to be reimplemented. + +
    Text selection has to be reimplemented. + +
    Dragging of bidirectional text selections has to be reimplemented. + +
    Platform-native keyboard shortcuts have to be reimplemented. + +
    Platform-native input method editors (IMEs) have to be reimplemented. +
+
    Undo and redo functionality has to be reimplemented. + +
    Accessibility features such as magnification following the + caret or
selection have to be reimplemented. + +

+ +

This is a huge amount of work, and authors are most strongly + encouraged
to avoid doing any of it by instead using the + input element, the textarea
element, or + the contenteditable + attribute.
+ +

Authors that eschew these existing solutions and instead take on + the
monumental task of implementing a text editor from scratch must + expose
the position of the caret and selection using the setCaretSelectionPos() +
method. "



2. In the agreed on change proposal getCaretBlinkPeriod should return a
value less than zero if no operating system setting exists. Ian removed
that from the chairs decision. The actual name change on the function both
Maciej and I had no problem with. Furthermore, this text was never in the
chairs decision:

<p class="warning">Exposing the information mentioned in this
+  section increases the ease with which authors can fingerprint users
+  across sites even in the absence of third-party cookies or other
+  intentionally unique identifiers. Implementors are encouraged to
+  very carefully consider the implications of implementing these
+  features.</p>
+

3. The actual procedural steps for driving magnification do not match the
chairs decision:

This is what Ian has:

 <li><p>Optionally, inform the user that the focus is at the
+   location given by the path. (For example, this could involve moving
+   the user's magnification tool.) User agents may wait until the next
+   time the <span>event loop</span> reaches its "update the rendering"
+   step to optionally inform the user.</p></li>
+

This was the spec. change to the section:

 1. If the element is not focused or is not a descendant of the element
      with whose context the method is associated, then return false and
      abort these steps.


 2. If supporting an accessibility API, implementors may use the drawing
      path to form a best fit rectangle in screen coordinates and apply it
      to the bounding rectangle of the associated accessible object.


 3. If the user has requested the use of particular focus rings (e.g.
      high-contrast focus rings), or if the canDrawCustom argument is
      absent or false, then draw a focus ring of the appropriate style
      along the path, following platform conventions, return false, and
      abort these steps.
The focus ring should not be subject to the shadow
      effects, the global alpha, or the global composition operators, but
      should be subject to the clipping region.


 4. Return true.


Ian's change does not reflect what is required to drive a magnifier.
Furthermore, he makes an assumption that the user agent is going to move
the user's magnification tool. The magnification tool moves in response to
accessibility APIs, in some function, and is a separate function. The only
thing the chairs said should not be applied in the change proposal was the
removal of canDrawCustom.

4. This was not in the chairs decision either. I have no idea where this
came from:

-<span>Navigator</span> implements
<span>NavigatorStorageUtils</span>;</pre>
+<span>Navigator</span> implements <span>NavigatorStorageUtils</span>;
+<span>Navigator</span> implements
<span>NavigatorUserPreferences</span>;</pre>

Rich Schwerdtfeger
CTO Accessibility Software Group