RE: drawSystemFocusRing in Canvas

I like the idea that no matter who customized the system focus ring (web
developer, user through OS setting, etc) that style will be used.



I have a concern/question about how the focus ring will be cleared:



According to the spec, drawSystemFocusRing actually draws onto the canvas:



If the given element is focused, draws a focus ring around the current
default path<http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#current-default-path>or
the given path, following the platform conventions for focus rings.



It doesn’t set up onfocus and onblur automatic events, like the presence of
an ordinary active element, which would be more like this:



Permanently associate the current default
path<http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#current-default-path>or
the given path with the given element, so that, as the given element
gains and loses focus, focus indication is shown and hidden on the canvas
and communicated to AT following the platform conventions for focus rings.



So, would a Web developer use drawSystemFocusRing in a function triggered
by onfocus(), something like this:

      function myFocus(num){

                      rc.beginPath();



                      rc.moveTo(275,165);

                      rc.lineTo(415,165);

                      rc.lineTo(415,285);

                      rc.lineTo(275,285);

                      rc.lineTo(275,165);

                      rc.closePath();




rc.drawSystemFocusRing(document.getElementById(‘thefallbackitem’));

      }



If so, with each browser having different fallback styles, and with
possible end user customization, how will we know how to un-draw the focus
ring, which might actually overlap fairly complex backgrounds?



Thanks,

Suzanne
 ------------------------------

*From:* Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
*Sent:* Thursday, July 25, 2013 11:03 AM
*To:* public-html-a11y@w3.org
*Subject:* drawSystemFocusRing in Canvas



I am working with Google on their implementing support for this feature.
One of the things we did not specify with greater clarity is how the focus
ring style is determined for the standard focus ring associated with a
fallback element.

Default Focus styling by default should be determined from the outline
style of the fallback element associated with the element drawn on the
canvas

http://www.w3.org/TR/CSS2/ui.html#dynamic-outlines

>From CSS2:
"Graphical user interfaces may use outlines around elements to tell the
user which element on the page has the *focus*. These outlines are in
addition to any borders, and switching outlines on and off should not cause
the document to reflow. The focus is the subject of user interaction in a
document (e.g., for entering text, selecting a button, etc.). User agents
supporting the interactive media
group<http://www.w3.org/TR/CSS2/media.html#interactive-media-group>
must
keep track of where the focus lies and must also represent the focus. This
may be done by using dynamic outlines in conjunction with the :focus
pseudo-class.

For example, to draw a thick black line around an element when it has the
focus, and a thick red line when it is active, the following rules can be
used:


:focus  { outline: thick solid black }
:active { outline: thick solid red }"

This would of course mean that should the author decide to change the
default focus style for the outline of that element that that style could
change on the physical canvas.

I would like to add informative text to the Canvas 2D API document that
states something on the order of (and this could be placed in a note):

Note:

The agents may use the <a href="
http://www.w3.org/TR/CSS2/ui.html#dynamic-outlines">CSS outlines around
focused elements</a> in determining the system focus style on fallback
elements to determine the standard system focus ring style drawn on the
canvas. This would mean that if an author were to override this style that
the appearance of the standard focus ring drawn on the canvas could reflect
this change in style.

Since this is non-normative text and would not require us to go back to
Last Call and because Google requested that we add informative text I would
like to propose adding this or similar to text to the current Canvas 2D API
CR document.

Rich








Rich Schwerdtfeger