Returning canvas to last call

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>> 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>>
>     To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
>     Cc: Rik Cabanier <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>
>
>     ------------------------------------------------------------------------
>
>
>
>     On Fri, Sep 20, 2013 at 4:28 PM, Richard Schwerdtfeger
>     <_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 19:32:37 UTC