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 23985 - drawCustomFocusRing and color scheme
Summary: drawCustomFocusRing and color scheme
Status: RESOLVED WONTFIX
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: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y_canvas
Depends on:
Blocks:
 
Reported: 2013-12-03 16:59 UTC by Philippe Le Hegaret
Modified: 2015-06-16 20:38 UTC (History)
5 users (show)

See Also:


Attachments

Description Philippe Le Hegaret 2013-12-03 16:59:28 UTC
[[
a canvas can contain absolutely anything. It might contain a wild and crazy color palette. Only the canvas author knows what focus ring is going to be visible on top of that canvas. If the canvas is white text on a black background, then a dark-colored focus ring is going to be practically invisible, and vice versa.

It just doesn't make any sense to me that we're providing an API that says,
if you want to draw your own focus ring, use this - BUT, under some
circumstances we're going to tell you not to draw it and the browser or
operating system is going to draw it for you, even though the browser has
no idea what colors are on your canvas and what type of focus ring would be
visible against it.

If the author wants to draw their own focus ring, it's probably for a good
reason. We should let them.

We may also want to give web authors visibility into the system color
palette so they can adjust the entire canvas - and not just focus rings -
for high contrast mode. But that's out of the scope of this discussion.
]]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0035.html

[[
The issue is when the application wants to draw its own focus ring - should
the system sometimes override that and draw its own focus ring instead?
That's the argument I don't buy.

Respecting the system focus ring color but ignoring the rest of the system
palette makes no sense. Suppose the user has chosen white-on-black text
with a yellow focus ring. The canvas normally draws a black-on-white GUI
with red focus rings that are really easy to see. If the canvas calls
drawCustomFocusRing and the system draws its yellow focus ring instead, it
will actually be worse. So drawing the custom focus ring, in the absence of
the rest of the information about the system palette, is not necessarily an
improvement at all.

I think this feature was proposed with the best of intentions by people who
misinterpreted how Windows system colors and styles work, and didn't think
through all of the implications.

I am totally in favor of trying to provide a better experience for users
who want a high-contrast theme and custom focus rings - I just don't think
this API is the way to achieve that goal, and I think it would actually
make things worse if user agents implemented it as specified.

Perhaps this shouldn't even be solved as part of canvas. Maybe we should
add web apis to indicate that the user prefers a custom color scheme that
could be used for rendering the whole page, not just canvas.
]]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0203.html
Comment 1 Jay Munro 2013-12-03 21:30:27 UTC
Reassigning to Canvas 2D Context Level 2 since drawSystemFocusRing and drawCustomFocusRing are at risk for CR.
Comment 2 Rich Schwerdtfeger 2013-12-04 15:03:10 UTC
I think everyone agrees this should be moved to L2.
Comment 3 Jay Munro 2013-12-04 19:48:46 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 4 Jay Munro 2014-01-07 17:28:43 UTC
Per A11y/Canvas task force, moving to Canvas Context 2D Level 2 for more work.
Comment 5 Philippe Le Hegaret 2015-06-16 20:27:50 UTC
Moved to L1
Comment 6 Philippe Le Hegaret 2015-06-16 20:38:03 UTC
We only have drawFocusIfNeeded now, so no longer relevant.