Try this page or paste the CSS rules into your userContent.css. Once you get used to it the old focus outlines seem ridiculously small and hard to see.
3.51 KB, text/html
18.08 KB, image/png
2.41 KB, image/png
Even once bug 151375 is fixed making outlines appear outside of the current frame, there will still be a visibility problem with the thin dotted outline. It's very difficult to see, especially at high resolutions or for partially sighted users. It would be good to have a thicker brightly colored outline on Windows and Linux -- possibly even looking like the Mac focus outline. Simply making the dotted outline 2px thick does not help, becuase the 2x2 pixel square dots are just ugly. The Mac version of this bug is bug 53927 -- on Mac we definitely want to follow the system focus appearance. Roc says that this is dependent on some changes Hixie is making to the CSS 2.1 outline spec, and a z order code refactoring he's working on.
browser.display.focus_ring_on_anything -> true browser.display.focus_ring_width -> 10 Works on everything but frames. :(
(In reply to comment #1) > browser.display.focus_ring_on_anything -> true > browser.display.focus_ring_width -> 10 Makes it more visible if you know the magic, but it's too ugly to be a default. This bug is about making the default focus appearance attractive and visible. We don't need to do it like IE & Netscape did just because of history.
Created attachment 217886 [details] Try this page or paste the CSS rules into your userContent.css. Once you get used to it the old focus outlines seem ridiculously small and hard to see.
Created attachment 218882 [details] safari's use of focus rings I like this idea, but not the exact implementation which seems to be more noticable to a point of distraction. I've attached Safari's implementation of this as a reference, and while I'm not sure we can emulate it as nicely (can we get translucent borders with CSS? I didn't think we could ...) 2px at the widest, I'd think, and a soft blue-grey colour would likely work best.
Do we also get this new focus outline on Firefox tabs? That would be ugly. I don't particularly like it, anyway, although I do think the Safari example from comment #4 looks better than the examples Mark posted in his weblog.
Is the outline going to be theme controlled? A blue-grey outline will probably look really ugly with some color schemes.
Will this use the OS selection color? Will this only affect the web content area, or are you also planning to apply it to XUL? If that is the case, we should probably have some theme author input here.
In bug 333513 we discussed whether clicking something should also put a focus ring around it. At least on Mac OS, clicking a link (which already does styling when clicked) and some widgets are exempt from focus rings on click in Safari. That is, unless you explicitly focus it in some way - for example tabbing to it with the keyboard. Invoking the focus ring on every click could be slightly too intrusive, imho.
- On Windows, how does this interact with system colors? Pages with different colored backgrounds, etc? - A hard rectangle looks pretty weird around controls with rounded off edges (like buttons). I think a requirement to pursuing this would be to get some help from the Gecko folk to make this not look so harsh.
This is nice, although it looks like IE 5/Mac :)
really really ugly on machines or OSes using a "classic" theme...
(In reply to comment #4) > Created an attachment (id=218882)  > safari's use of focus rings > > I like this idea, but not the exact implementation which seems to be more > noticable to a point of distraction. I've attached Safari's implementation of > this as a reference, and while I'm not sure we can emulate it as nicely (can we > get translucent borders with CSS? I didn't think we could ...) Cairo builds support rgba() at least.
Note that any hardcoded outline color will be invisible on _some_ sites. This is why we really want to do "invert" outlines, imo.
(In reply to comment #13) > Note that any hardcoded outline color will be invisible on _some_ sites. This > is why we really want to do "invert" outlines, imo. Yes but inverted outlines are either too thin to see or just plain ugly if they're bigger. Another solution is to use a hardcoded color that switches to something else when the background behind it has a similar else. BTW, I've been surfing with a blue outline focus for a long time now and haven't yet run across a site with a blue background or any color which makes it hard to see. It's always been esier to see. Yes, technically the possibility exists but there's a reason people don't use blue outlines for their sites -- it's too hard to see text. Same reason IE Mac can get away with this.
Some issues with trying to copy the "Mac OS X" style focus ring in Safari. (1) We allow control of the focus ring color via CSS and then take the CSS-specified color and force a 50% alpha. (2) We had to support the CSS3 outline-offset since some controls have the outline overlap slightly (thus needing a negative outline-offset to be supported). (3) Controls in Safari can be either mouse focusable or key focusable (or both). When you don't see the ring on a mouse down that means the control is not mouse focusable. Having the outline always show up could be a bit strange/distracting. (4) You need really good support for the outline property. We are still fixing bugs to this day in Safari to get this right. It is very very hard.
> there's a reason people don't use blue outlines for their sites s/outlines/backgrounds
We support an outline-style of auto to indicate that the specialized focus ring style should be used.
(In reply to comment #15) > (2) We had to support the CSS3 outline-offset since some controls have the > outline overlap slightly (thus needing a negative outline-offset to be > supported). We have -moz-outline-offset and -moz-outline-radius > (3) Controls in Safari can be either mouse focusable or key focusable (or > both). When you don't see the ring on a mouse down that means the control is > not mouse focusable. Having the outline always show up could be a bit > strange/distracting. It wouldn't show up any more than it does now. > (4) You need really good support for the outline property. We are still fixing bugs to this day in Safari to get this right. It is very very hard. We're already using the outline property for focus in Firefox, but with dots.
Right, but focus rings show up more on Windows than on OS X since everything is mouse focusable. My point is just that this "Mac-style" focus ring might be perceived as "noisy" if it shows up on links and buttons.
One experiment we tried in Safari was defaulting the focus ring color to the foreground color. The downside is that the rings changed color as you tabbed through elements with distinct foreground colors, but the upside was that the rings were always clearly visible. Ultimately we just went with the OS ring color for everything though.
Foreground color has problems on the folowing markup, which I've seen a bunch in menu system type things: <div style="background: black; padding: 5px"> <span style="background:white; color: black;"> Text </span> </div> Note that in this case the outline is painting on a black background, not a white one.
Yeah, that's one of several reasons we discarded the idea, but I thought I'd throw it out there. :)
In practice using the foreground color did work very well for visibility (since focus rings apply to a limited set of content), but the Mac OS system color has also worked out ok for us. The ring is sometimes not as visible as it could be, but typically it's more visible than a tiny set of dots.
Attachment 217886 [details] had corrupted CSS. I've updated the testcase: http://design-noir.de/bugzilla/focus-indication It's a PHP script in order that you can try out different color codes easily: http://design-noir.de/bugzilla/focus-indication?c=rgba(6%25,73%25,88%25,.5) http://design-noir.de/bugzilla/focus-indication?c=%23fc6 http://design-noir.de/bugzilla/focus-indication?c=rgba(100%25,80%25,40%25,.6) http://design-noir.de/bugzilla/focus-indication?c=rgba(50%25,80%25,50%25,.6) Looks pretty neat with cairo.
Here's a real example using rgba(100%,80%,40%,.7): http://design-noir.de/Bilder/Schnappsch%FCsse/ (In reply to comment #19) > My point is just that this "Mac-style" focus ring might be > perceived as "noisy" if it shows up on links and buttons. I agree. Esp. on links it's exceeding the limit.
I think the thick coloured rings are a bit intrusive for those of us that haven't really relied on them before. The dotted line was fine by me, but that's considering my eyesight isn't all that bad. As the suggestion stands I think they would need to properly wrap around the element outlines, if possible. They also would look a lot better if the rounded corners were antialiased but that holds for border-radius (and even radio buttons) too. It may be pie-in-the-sky, but an aesthetically pleasing focus ring might be one that gets obvious as you're actively focussing through things, dims / slims after you stop and slowly throbs if you've scrolled off it and back again. Would involve a lot of technical wizardry for a relatively small feature, though.
(In reply to comment #26) > I think the thick coloured rings are a bit intrusive for those of us that > haven't really relied on them before. You seem to use a 1.8 branch build. I think this issue is targeting the trunk, so grab a trunk build and take a look at my examples in comment #24. Some of them use rgba() and thus are less intrusive. > The dotted line was fine by me, but > that's considering my eyesight isn't all that bad. I think it's fine to offer this sacrifice in favour of novice and visually handicapped users. As a experienced user you can still customize your userContent.css. > As the suggestion stands I think they would need to properly wrap around the > element outlines, if possible. Maybe I'm getting this completely wrong, but how should something wrap around the outline? Doesn't outline itself actually do this? > They also would look a lot better if the rounded > corners were antialiased Again, you should use a trunk build.
> but how should something wrap around the outline? data:text/html,<a href="http://www.mozilla.org">Text1<br>Text2</a> Load that, then tab to the link with the outlines from this bug. Note that if the outline actually went around the outline of the <a> (as the CSS spec requires), it wouldn't look nearly as bad.
Created attachment 220233 [details] current critical outline / proposal Now I think I know what you mean now. Correct me if I'm wrong again, but if not, I have to agree: It would indeed look nicer. It's bug 266122.
I haven't tried it, but ... If the outline was 1px of the selection color, surrounded by 1px of a color halfway between white and the selection color, it would look like MacIE/Safari against a typical white/cream background -- and against a plain colored background, the focus ring would never be invisible. (You'd still need translucency for proper anti-aliasing, both of rounded ring corners and of the focus rings for non-rectangular <area>s.) > We don't need to do it like IE & Netscape did just because of history. This isn't about history; it's about how native focus outlines look today. It will make Gecko look more native on Mac OS and GTK+, but less on Windows.
I really like it. I think it might encourage (or at least indirectly suggest) using keyboard navigation to a slew of people who would never have considered it before, and in plenty of scenarios that's way faster than using the mouse.
Let's file bugs on Gecko to help us make it look really nice too?
As per the image on http://diveintomark.org/archives/2006/04/25/new-focus-indicator I really don't like the proposed change; it looks clunky, almost like something from a development version that still needs to be polished. However, while I don't think that most users would benefit (or like) this, I suspect that it would be very helpful for the visually impared. Thus I suggest that this become an option that can be turned on under Accessibility (e.g. in 1.5 its in the Advanced Prefs on the General tab) but be off by default.
(In reply to comment #33) > it looks clunky, almost like something > from a development version that still needs to be polished. That's because it's a proposal that needs to be polished.
(In reply to comment #34) > > it looks clunky, almost like something > > from a development version that still needs to be polished. > > That's because it's a proposal that needs to be polished. Heh; point taken. Even if you round off the edges nicely as in the Safari attachment though (see comment #4) I still think its overkill for the average person. Put it in Accessibility and if the adoption rate is high, make it the default (but please let me turn it off in about:config ;).
(In reply to comment #35) > (In reply to comment #34) > > Put it in Accessibility and if the adoption rate is high, make it the default > (but please let me turn it off in about:config ;). I concur, or make it per the OS -- Mac users are more used to this effect, so enable it there. Windows users are quite used to seeing the dotted outline. As for the colouring, is it possible to leverage CSS 3 values? "flavor" sounds as though it's explictly designed for this purpose: <http://www.w3.org/TR/2003/CR-css3-color-20030514/#flavor> As well there's User Interface values: <http://www.w3.org/TR/2000/WD-css3-userint-20000216.html#color> If those can't nice be used, there's always the CSS2 system colours: <http://www.w3.org/TR/CSS21/ui.html#system-colors>
Not only is "flavor" "not expected ... [to] make sense on all platforms and machines", in reality it applies only to Macintoshes produced from 1998 to 2002 (and even then, it was a Tasman-only frivolity), so it is not really helpful for this bug (just like arguing about uselessly obscure focus ring configurability isn't.) Similarly, CSS2/3 UI colors apply sensibly only to Windows 95/98/ME/2000, and don't really work in other OSes or newer Windows themes. So implementing this would need a value akin to -moz-mac-focusring.
*** Bug 78839 has been marked as a duplicate of this bug. ***
Will this also work on Firefox tabs? If so, then it will fix the problem here: https://bugzilla.mozilla.org/show_bug.cgi?id=318168#c98 where you can't tell which tab is in focus.
(In reply to comment #39) > Will this also work on Firefox tabs? > > If so, then it will fix the problem here: > https://bugzilla.mozilla.org/show_bug.cgi?id=318168#c98 > > where you can't tell which tab is in focus. Bug 251198 is: - about HTML content - for Gecko 1.9 Bug 318168 is: - about tab strip overflow - for Firefox 2 - already fixed
The Accessibar extension provides this functionality. Not perfect, but pretty nice.
For what it's worth, I doubt much will happen to this bug in this component (esp. since the component is somewhat unowned).
I'd like to bring this up again -- Google Chrome does it now and it's beautiful. Noticeable right away, and it make a big usability difference, not only for people with visual impairments -- for everyone.
One other note -- Google Chrome does this without fixing outline globbing and it looks perfectly fine. For us that's bug 266122 -- I don't think we should count that as a dependency.
You really should get some UI people on this bug, then, perhaps by moving it to the right component.
(In reply to comment #45) > You really should get some UI people on this bug, then, perhaps by moving it to > the right component. Can you add "uiwanted" key word? I would, but it is not an available choice for me. Thank you.
Alex, do you have any suggestions or thoughts here?
I think Dao is headed in the right direction. In general I'm in favor of us improving the focused state for hyperlinks, or form elements that have been focused with the keyboard. A lot of the focus work done in bug 418521 sets us up for drawing a more obvious focus state, but not being annoying and applying it to every mouse interaction. cc'ing stephen for visual feedback. We should be careful to try to match native platform colors, even if the ring itself is not technically a native behavior.
We lost the wanted Firefox 3.5 flag, but there is nothing to replace it. Absent that, marking the closest remaining choice: "blocking 188.8.131.52"
(In reply to comment #49) > We lost the wanted Firefox 3.5 flag, but there is nothing to replace it. > Absent that, marking the closest remaining choice: "blocking 184.108.40.206" That is Firefox 3.0 and this would in no way block a very old branch security/stability update release.