Re: Returning canvas to last call

Hi Sam,

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


On Tue, Sep 24, 2013 at 12:32 PM, Sam Ruby <rubys@intertwingly.net> wrote:

> 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<http://www.w3.org/html/wg/charter/2013/#milestones>
> [2] http://dev.w3.org/html5/**decision-policy/public-**
> permissive-exit-criteria.html<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_<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
>>
>>
>>
>