FW: Returning canvas to last call

Hi Sam,

I will work with Rich and Dominic on what we can put on the at-risk list for the focus rings.


Rik
---------- Forwarded message ----------
From: Sam Ruby <rubys@intertwingly.net<mailto:rubys@intertwingly.net>>
Date: Tue, Sep 24, 2013 at 12:32 PM
Subject: Returning canvas to last call
To: Rik Cabanier <cabanier@gmail.com<mailto:cabanier@gmail.com>>, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>>
Cc: public-html-a11y@w3.org<mailto:public-html-a11y@w3.org>, "public-html-admin@w3.org<mailto:public-html-admin@w3.org>" <public-html-admin@w3.org<mailto:public-html-admin@w3.org>>


On 09/23/2013 11:12 AM, Rik Cabanier wrote:
Rich,

yes, an API with the same name was implemented but it is not following
the spec.
It doesn't seem like this would pass the bar as an implementation unless
we update the spec.

Rik (and other canvas editors) and Rich (and other members of the A11y TF), can you work together to agree on what should be included in a new Last Call draft?

Current status:

The current charter[1] has HTML Canvas 2D Context going to PR in 2013 Q3 and Rec in 2013 Q4.  There is a desire by both the editors and W3C staff to come as close as possible to meeting these dates.

There are Canvas features which are known to not be interoperably implemented at this time which were not called out as at Risk at the time the previous Last Call draft was published.  These features were identified prior to the Last Call but weren't communicated to all potential reviewers.

This will require us to put out another Last Call draft.  Minimum period for such would be 6 weeks.

Such a draft could mark additional features as being at Risk.  It could also remove such features.  The danger of removing features is that if it were later felt necessary to add back in those features, yet another Last Call would be required.

My personal recommendation would be to produce a draft which only included features which are comfortably likely to meet the published Public Permissive Exit Criteria[2] by 1Q2014, and to defer features which are not likely to make that date to HTML Canvas 2D Context, Level 2.

- Sam Ruby

[1] http://www.w3.org/html/wg/charter/2013/#milestones
[2] http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html

Rik

On Mon, Sep 23, 2013 at 6:42 AM, Richard Schwerdtfeger
<schwer@us.ibm.com<mailto:schwer@us.ibm.com> <mailto:schwer@us.ibm.com<mailto:schwer@us.ibm.com>>> wrote:

    Paul, Janina,

    I was correct in stating that drawCustomFocusRing() was implemented
    in Chrome for both Windows and Mac. So, we have one implementation
    of BOTH drawSystemFocusRing and drawCustomFocusRing().

    As Rik stated, the Path object does not have a full implementation
    and the for Canvas 2 is to introduce a Shape object to support
    magnifier location information.

    Rich


    Rich Schwerdtfeger
    ----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 09/23/2013
    08:38 AM -----

    From: Dominic Mazzoni <dmazzoni@chromium.org<mailto:dmazzoni@chromium.org>
    <mailto:dmazzoni@chromium.org<mailto:dmazzoni@chromium.org>>>
    To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
    Cc: Rik Cabanier <cabanier@gmail.com<mailto:cabanier@gmail.com> <mailto:cabanier@gmail.com<mailto:cabanier@gmail.com>>>
    Date: 09/23/2013 01:11 AM
    Subject: Re:
    Sent by: dmazzoni@google.com<mailto:dmazzoni@google.com> <mailto:dmazzoni@google.com<mailto:dmazzoni@google.com>>

    ------------------------------------------------------------------------



    On Fri, Sep 20, 2013 at 4:28 PM, Richard Schwerdtfeger
    <_schwer@us.ibm.com_ <mailto:schwer@us.ibm.com<mailto:schwer@us.ibm.com>>> wrote:

        Hey Dominic,

        When we talked you said you had implemented both
        drawSystemFocusRing and drawCustomFocusRing. I only tested with
        drawSystemFocusRing.


    That's correct, they're both implemented.

        Rik thought there was some problems with the custom focus ring
        function.

        Is that still the case and if so what is the concern. Other than
        driving the magnifer I would think this basically involved
        calling stroke().


    I'm going by the spec from here:
    _http://www.w3.org/TR/2dcontext/#dom-context-2d-drawcustomfocusring_ -
    let me know if that isn't the correct document. Here's what it says
    for step three of drawCustomFocusRing.

    /3. If the user has requested the use of particular focus rings
    (e.g. high-contrast focus rings), then draw a focus ring of the
    appropriate style along the intended path, and set result to false./

    As best as I can determine, no operating system exposes such a
    preference for high-contrast focus rings. Assistive technology like
    ZoomText or MAGic just draw their own additional focus rings, they
    don't tell applications to draw high-contrast focus rings. While in
    theory it's possible for a browser to add that as a user preference,
    there are no plans to do so at this time. Because of all this, it
    seems like this part of the spec isn't currently useful and should
    be removed.

    So, given that such a preference never exists, Chrome never draws
    anything when you call drawCustomFocusRing. It just updates
    assistive technology and returns false every time.

    It's still useful - but the name no longer makes sense. Something
    like notifyFocusRingPath might make more sense.

    I don't understand why we would ever call stroke() - can you explain
    how that's implied by the spec?

    - Dominic

Received on Tuesday, 24 September 2013 20:40:09 UTC