- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 24 Sep 2013 15:32:05 -0400
- To: Rik Cabanier <cabanier@gmail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>
- CC: public-html-a11y@w3.org, "public-html-admin@w3.org" <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>> 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