W3C home > Mailing lists > Public > www-archive@w3.org > April 2011

Re: Bug 11239

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 28 Apr 2011 10:21:31 -0700
Message-ID: <BANLkTikoH4idfcbCPJ+m+ERa=oni=7U3Wg@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>, www-archive <www-archive@w3.org>, Sam Ruby <rubys@intertwingly.net>
Hi Richard,

Sorry to bring this up again so soon.

Can you please use existing threads rather than start new ones. Was
there any reason that you couldn't simply reply to Ians email asking
for feedback, thus making your email use his thread. That would make
it easier both for people wanting to follow that discussion, and for
people not wanting to do so.

You also did the same thing in your email with the subject "question
about the meta-generator exception". This email would have been more
contextual if you had simply replied to the existing emails with the
subject "Objection to generator decision (Re: Working Group Decision
on ISSUE-31 / ISSUE-80 validation survey)".

I'm sorry to be a nag about this, but creating new threads at the rate
that you do both fragments discussions, as well as makes it more
costly (in time) to follow the public-html list.

/ Jonas

On Thu, Apr 28, 2011 at 8:10 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> 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
Received on Thursday, 28 April 2011 17:22:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:35 GMT