Issue metadata
Sign in to add a comment
|
Outline should not appear on elements focused by mouse |
|
||||||||||||||||||||||
Reported by oliverj...@gmail.com, Aug 9 2013 | Back to list | |||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1591.0 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Disable the "Pressing Tab on a web page highlights links, as well as form fields" option 2. Use the keyboard to tab through items on a web page / mouse down on a button (but do not mouse up) What is the expected behavior? There should be no outline on the focused element. What went wrong? There is an outline, with or without the setting enabled. It also appears when you click on an element too, whereas before I believe it only appeared when you used the keyboard to tab onto the element. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Does this work in other browsers? Yes Chrome version: 30.0.1591.0 Channel: canary OS Version: OS X 10.9.0 Flash Version: Shockwave Flash 11.8 r800
Aug 11 2013
,
This is an expected behavior since Chrome 30. Clicking a button focuses on the button, and the button has :focus style. Please contact to the web page author if you think this is wrong.
Oct 4 2013
,
Umm, this is far too obtrusive. The outline on every button seriously affects the look of the webpage — even here, on Google Code. Disabling the outline, however, also affects <tab>ing, where the outline is the only indicator of focus. Seems like a related bug: https://code.google.com/p/chromium/issues/detail?id=25518 Focus ring appears on mouse interactions (as opposed to only when tabbing through items): https://bugzilla.mozilla.org/show_bug.cgi?id=418521
Dec 16 2013
,
Out of interest, why is this the behaviour for buttons but not links?
Dec 16 2013
,
Furthermore, this only happens on buttons when the button’s CSS background is set to `none: http://jsbin.com/oJUNAkaT/2/edit
Feb 1 2014
,
Can this be re-opened? I've got a strong feeling this is causing serious accessibility degradation on the web and the longer it remains the larger the damage. Given that styling buttons is such a widespread practice and a blurry outline on mere clicking will likely cause developers to disable outlines entirely, we'll be left with forms that show no indication that you've tabbed to buttons. At best. At worst we'll be without all focus outlines.
May 11 2015
,
I think we should revisit this. I agree with comment #6 - people are removing the focus style from elements to avoid this issue, which hurts accessibility overall. http://stackoverflow.com/questions/19053181/how-to-remove-focus-around-buttons-on-click is just one example of advice to remove the focus ring to avoid this issue.
May 11 2015
,
Jul 27 2015
,
Aug 25 2015
,
In agreement with #3, #6, and #7. I'm getting requests from the UX team to remove the outline on click... when in fact that's out of my hands. Setting the focus state to outline: 0 is not a viable alternative since it hurts accessibility. Any chance this can get looked at again?
Aug 25 2015
,
Also, in response to #5, it looks like the focus ring is showing up on click when the background property has been set to any value, not just "none". Leaving background untouched, it correctly does not show the focus ring on click.
Aug 26 2015
,
At this moment we can do nothing for Chromium/Blink. We need to focus on an element when it is clicked, and it should be matched to :focus. Web authors can implement the desired behavior by small JavaScript code. Example: https://chromium.googlesource.com/chromium/src/+/master/ui/webui/resources/js/cr/ui/focus_outline_manager.js The best solution would be the CSS standard introduces a pseudo selector like :focused-by-pointer or :focused-by-keybaord.
Aug 26 2015
,
Well, how does Firefox handle this internally? They _don't_ apply `:focus` on a mouse click at least. Only when you tab to buttons.
Aug 27 2015
,
Apparently this has already been fixed. See #5 in https://code.google.com/p/chromium/issues/detail?id=521305#c5.
Oct 1 2015
,
Ok, let's close this as it's already fixed. Adding rob@ in cc so he could verify.
Oct 1 2015
,
I cannot verify the bug because I don't see a clear bug description here.
Oct 2 2015
,
The bug is, for example, 1. open data:text/html;charset=utf-8,<button type=button style="background:gray">Button</button> 2. Click on the button by a mouse (not TAB focus navigation) Expected: The button has no focus ring Actual: The button has focus ring So, we don't fix this yet.
Oct 2 2015
,
I've tested the following in several browsers (http://jsfiddle.net/t9g1403n/1/show), by clicking on the button and moving the mouse away (to avoid :hover effects): 1: <button>Button default</button> 2: <button style="background:gray">Button gray</button> 3: <button class=outline-focus>Button :focus outline</button> <style>.outline-focus:focus { outline: 1px solid red; }</style> In all browsers, button 2 looks different from 1 and 3 (button 1 and 3 has a "native" style, while 2 looks like an ugly styled button with a custom background). Has focus effect, for each of the buttons? - Safari 5.1 (Windows 7-10) : N N N (note1) - Safari 9 (OS X 10.11) : N N N (note1) - IE Edge (Windows 10) : N N Y - IE 11 (Windows 7, 8.1, 10): N Y Y (note2, note3) Firefox follows the platform conventions. - Firefox 41 (Linux) : Y Y Y (note2, note4) - Firefox 41 (Windows 10) : Y Y Y (note2, note4) - Firefox 41 (Windows 7-8.1): Y N Y (note3) - Firefox 41 (OS X 10.11) : N N N Chrome has a uniform styling across platforms. - Chrome 47 (Linux) : N Y Y - Chrome 47 (Windows 10) : N Y Y - Chrome 47 (OS X 10.11) : N Y Y Opera Presto is no longer used, but I'm showing it because it's a different rendering engine. - Opera 12.16 (Windows 8.1) : Y Y Y (note2) - Opera 12.15 (OS X 10.11) : Y Y Y (note2) * note1: Does not focus the buttons, let alone activate :focus upon click, even after enabling "Press tab to highlight each item on a webpage". * note2: button 2's visual focus differs from button 1's focus effect (shown by clicking on button 1 or tabbing to it if clicking does not activate a focus effect). * note3: IE's visual focus on button 2 is subtle: the inner border becomes slightly thicker. * note4: Firefox's visual focus is subtle: a dotted box inside the button. CONCLUSION There is no consistency in focus effects upon click among browsers, but the browsers made by OS vendors (IE Edge, OS X) seem to prefer no focus effect after clicking a button. Firefox attempts to match platform conventions (https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-focusring). Therefore I think that we should indeed change Chrome's behavior, and not show the focus ring after clicking the button (probably with logic similar to my a[href]:focus changes in bug 388666 ). <button>s are not the only form element, are there any other elements that need such visual changes?
Oct 4 2015
,
Windows 10 seems pretty inconsistent. The newer Windows UWP dialogs (e.g., windows 10 settings) never show focus on mouse down. Other programs like Paint will not show focus in some cases (open file dialog accessed via the ribbon button) but will in others (open file dialog accessed via ctrl+o). The Windows 10 start menu works more like UWP/OSX and does not show focus on mouse down. Firefox/Opera may not have made the same decision if Windows 10 had been out back then. Android also works like UWP/OSX. How do folks feel about contacting the Edge and Firefox teams about unifying on the UWP/OSX behavior, both for {browser,platform} consistency and so users don't break accessibility due to this?
Oct 5 2015
,
+1, let's improve compat on this.
Oct 7 2015
,
Some discussions in WICG: http://discourse.wicg.io/t/detecting-users-dont-require-visible-focus-rings/804 Detecting users don’t require visible focus rings http://discourse.wicg.io/t/exposing-a-users-input-modality/1067 Exposing a user's input modality
Oct 7 2015
,
Removing Cr-Blink-Paint since this is not really a paint bug.
Jun 16 2016
,
Tab proposed :focus-ring. https://lists.w3.org/Archives/Public/www-style/2015Sep/0226.html We can implement it so that it matches only when an element was focused by keyboard. We'd like to implement it when it is added to the CSS selectors specification.
Mar 26 2017
,
:focus-ring is on the draft. We should send intent-to-implement (and ship). https://drafts.csswg.org/selectors/#the-focusring-pseudo
Mar 28 2017
,
Apr 21 2017
,
Apr 21 2017
,
Jul 27 2017
,
Jul 31 2017
,
Sep 29 2017
,
Sep 29 2017
,
|
||||||||||||||||||||||||
►
Sign in to add a comment |
Comment 1 by meh...@chromium.org
, Aug 10 2013