This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23982 - Focus Ring out of canvas
Summary: Focus Ring out of canvas
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: CR HTML Canvas 2D Context (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 major
Target Milestone: ---
Assignee: Jay Munro
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y_canvas
Depends on:
Blocks:
 
Reported: 2013-12-03 16:52 UTC by Philippe Le Hegaret
Modified: 2014-01-21 01:05 UTC (History)
6 users (show)

See Also:


Attachments

Description Philippe Le Hegaret 2013-12-03 16:52:09 UTC
If the "intended path" goes outside the visible canvas (or if it's too close to the edge to draw a proper ring), what should the user agent (system focus ring) and web app (custom focus ring) do?
Comment 1 Jay Munro 2013-12-03 21:31:37 UTC
Reassigning to Canvas 2D Context Level 2 since drawSystemFocusRing and drawCustomFocusRing are at risk for CR.
Comment 2 Rich Schwerdtfeger 2013-12-04 14:57:27 UTC
This is simple. Anything drawn in canvas is clipped to the bounds of the canvas region. This is 2D graphics engine 101. You don't see any of the other canvas drawing calls talking about clipping. This should be handled by the browser and is far too detailed a level of specificity. We don't mandate this elsewhere in canvas that I am aware of.
Comment 3 Philippe Le Hegaret 2013-12-04 17:59:25 UTC
Given that the question was asked in some of the threads, I'm still thinking that this is worth to clarify the specification.

[[
Apple people pushed back on the patch so it did not go in. They were
unclear on how the API is supposed to work, for instance, what if the path
is crossing the edge of the canvas?
]]
http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0004.html
Comment 4 Jay Munro 2013-12-04 19:47:40 UTC
I jumped the gun on moving to L2, there are still ongoing discussions on the focus ring methods. Moving back to CR until discussions are complete.
Comment 5 Rich Schwerdtfeger 2013-12-05 22:14:19 UTC
Alright. The one caviat here is the other bug that asks for the object with focus to be scrolled into view when it receives focus. When the text goes in for this the drawn focus ring or (whatever we call it) should deal with this issue. IOW. If the ring is scrolled into view we would then say that anything that does not fit in the view would be clipped to the bounds of the canvas area.

So, should we include this to the text on scrolling and if so should this be part of that defect?
Comment 6 Rich Schwerdtfeger 2014-01-13 23:47:04 UTC
It was agreed that the focus ring would be clipped to the bounds of the canvas area but that the location of the corresponding fallback element would not be clipped and would match the current default path passed. 

Action for Jay to add this text to the processing for drawFocusIfPossible()
Comment 7 Jatinder Mann [MSFT] 2014-01-20 23:43:04 UTC
Keep the following sentence in step 3: "When the focus outline is clipped by the canvas element, only the visual representation of the focus area is clipped to the clipping region."

Move and integrate this sentence with step 4: "The full location of the corresponding fallback element is passed to the accessibility API."


This sentence needs fixing as well: "(The effect of transformations is described above and varies based on which path is being used.)"
Comment 8 Jay Munro 2014-01-21 01:05:49 UTC
Updated the CR and L2 spec to reflect:

Moved and integrated this sentence with step 4: "The full location of the corresponding fallback element is passed to the accessibility API."


Updated CR: 

Removed : "(The effect of transformations is described above and varies based on which path is being used.)", since it had to do with path object which was removed.