Re: Bug 11239

On Thu, Apr 28, 2011 at 4:10 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> 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.

Where have people said they want this?

> Nobody should be given carte blanche to write whatever they please in
> the HTML specification without process approval.

Our decision policy says that the editor should make edits to the
editor's draft,
and that if anyone has a problem with his edits they should raise them as bugs,
then issues, etc. The policy is designed to minimize process approval.

http://dev.w3.org/html5/decision-policy/decision-policy.html

In this case, no changes have been made to the editor's draft; instead we're
just reviewing the editor's patch in lieu of the Chairs providing a patch.

> 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.

Drag and drop is standard behavior for editable text in WIMP desktop
environments.

> 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?

Use SVG.

Or, if like the Lucid Chart developers you're happy to make your app an
morass of nested divs and overlaid canvas elements, I don't really see
why you could not mix contenteditable into the chaos to provide text
editing.

> No drag and drop is required.

It is if the text editing experience is to match user expectations for
text editing in WIMP desktop environments.

> No copy and paste is required

It is if the text editing experience is to match user expectations for
text editing in most situations in most environments.

> 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.

The editorial comment is relevant to text editing of any sort, not just
rich text editing.

> Worse, this does not reflect the chairs decision.

The chairs decision does not require this warning, but I don't believe
this decision or any other has said we should not discourage authors
from attempting to create text editing functionality with canvas.

Ian's comment can be seen as an elaboration of the HTML spec's current
warning: "Authors should not use the canvas element in a document when
a more suitable element is available."

http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element

It would have been more politic to look to add this elaboration in a subsequent
revision rather than in a patch purporting to enact the chairs' decision.

> 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.

Yes, I'm not sure of Ian's rationale here. In fairness, Ian specifically
asked twice what negative number to return in the bug and nobody answered him:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239#c21

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239#c23

Ian: could we perhaps specify to return -1 in this case?

> 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>

I note you don't challenge the substance of the warning.

This is consistent with the advice given elsewhere in the spec about features
that allow fingerprinting, for example:

http://dev.w3.org/html5/spec/timers.html#client-identification

Surfacing the user's caret blink rate is clearly a member of that set, as I
noted in earlier feedback about the proposal:

http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0049.html

Adding a note like this did have some support within the Canvas TF. Charles
Pritchard said: "I'm up for adding a note somewhere, identifying these a11y
apis as data points which could be used for fingerprinting, as a hint to
vendors."

http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0057.html

> 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.

The practical differences seem to be:

  * Ian's patch is less detailed in its suggestion of how focus notification
    should be approached, whereas your list suggests that a best fit
rectangle on
    screen should be created and surfaced in the accessibility tree. I suppose
    vagueness provides for accessibility APIs that can understand
non-rectangular
    areas. Ian, could we perhaps include the best fit rectangle approach as just
    as an example?

  * Ian's patch tries to ensure notification about change of focus happens
    after drawing the focus ring (potentially in the next event loop), whereas
    in your list the notification happens *before* drawing the focus ring
    (presumably preventing progress to the next event loop). Is this a bad
    change?

Have I missed something?

> 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>

Ian's patch moves caretBlinkPeriod from the canvas context to
window.navigator, much as I suggested in earlier feedback on the proposal:

http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0049.html

Every property on the navigator object is defined as part of an
interface, so if we're happy with moving the property, defining a new
interface is consistent with how we define properties of the navigator
object.

As with the warnings about the difficulty of implementing text editing,
it would have been more politic to put this interface on the canvas
context in this patch, then look to migrate it in a subsequent revision.

Does anyone object to moving the property from canvas context
to navigator in this iteration?

--
Benjamin Hawkes-Lewis

Received on Thursday, 28 April 2011 18:00:37 UTC