Open
Bug 251198
Opened 20 years ago
Updated 2 years ago
Bright, clear focus appearance for HTML content on Win/GTK platforms
Categories
(Core :: Layout: Form Controls, enhancement)
Tracking
()
NEW
People
(Reporter: aaronlev, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: access, uiwanted)
Attachments
(3 files)
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.
Updated•20 years ago
|
Summary: Bright, clear focus appearance for HTML content on Win/GTK platforms → Bright, clear focus appearance for HTML content on Win/GTK platforms
Reporter | ||
Updated•20 years ago
|
Priority: -- → P2
Updated•19 years ago
|
Status: NEW → ASSIGNED
Updated•19 years ago
|
Assignee: aaronleventhal → pilgrim
Status: ASSIGNED → NEW
Comment 1•19 years ago
|
||
browser.display.focus_ring_on_anything -> true
browser.display.focus_ring_width -> 10
Works on everything but frames. :(
Reporter | ||
Comment 2•19 years ago
|
||
(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.
Reporter | ||
Comment 3•19 years ago
|
||
Comment 4•19 years ago
|
||
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.
Comment 5•19 years ago
|
||
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.
Comment 6•19 years ago
|
||
Is the outline going to be theme controlled? A blue-grey outline will probably look really ugly with some color schemes.
Comment 7•19 years ago
|
||
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.
Comment 8•19 years ago
|
||
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.
Comment 9•19 years ago
|
||
- 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.
Comment 10•19 years ago
|
||
This is nice, although it looks like IE 5/Mac :)
Comment 11•19 years ago
|
||
really really ugly on machines or OSes using a "classic" theme...
Comment 12•19 years ago
|
||
(In reply to comment #4)
> Created an attachment (id=218882) [edit]
> 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.
Comment 13•19 years ago
|
||
Note that any hardcoded outline color will be invisible on _some_ sites. This is why we really want to do "invert" outlines, imo.
Reporter | ||
Comment 14•19 years ago
|
||
(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.
Comment 15•19 years ago
|
||
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.
Reporter | ||
Comment 16•19 years ago
|
||
> there's a reason people don't use blue outlines for their sites
s/outlines/backgrounds
Comment 17•19 years ago
|
||
We support an outline-style of auto to indicate that the specialized focus ring style should be used.
Reporter | ||
Comment 18•19 years ago
|
||
(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.
Comment 19•19 years ago
|
||
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.
Comment 20•19 years ago
|
||
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.
Comment 21•19 years ago
|
||
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.
Comment 22•19 years ago
|
||
Yeah, that's one of several reasons we discarded the idea, but I thought I'd throw it out there. :)
Comment 23•19 years ago
|
||
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.
Comment 24•19 years ago
|
||
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.
Comment 25•19 years ago
|
||
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.
Comment 26•19 years ago
|
||
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.
Comment 27•19 years ago
|
||
(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.
Comment 28•19 years ago
|
||
> 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.
Comment 29•19 years ago
|
||
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.
Comment 30•19 years ago
|
||
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.
Comment 31•19 years ago
|
||
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.
Comment 32•19 years ago
|
||
Let's file bugs on Gecko to help us make it look really nice too?
Updated•19 years ago
|
Target Milestone: --- → mozilla1.9alpha
Comment 33•19 years ago
|
||
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.
Comment 34•19 years ago
|
||
(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.
Comment 35•19 years ago
|
||
(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 ;).
Comment 36•19 years ago
|
||
(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>
Comment 37•19 years ago
|
||
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.
Reporter | ||
Comment 38•18 years ago
|
||
*** Bug 78839 has been marked as a duplicate of this bug. ***
Comment 39•18 years ago
|
||
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.
Comment 40•18 years ago
|
||
(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
Reporter | ||
Updated•18 years ago
|
Updated•17 years ago
|
OS: Windows XP → All
Reporter | ||
Comment 41•17 years ago
|
||
The Accessibar extension provides this functionality. Not perfect, but pretty nice.
Assignee: pilgrim → nobody
Component: Keyboard: Navigation → Layout: Form Controls
QA Contact: layout.form-controls
Comment 42•17 years ago
|
||
For what it's worth, I doubt much will happen to this bug in this component (esp. since the component is somewhat unowned).
Priority: P2 → --
Target Milestone: mozilla1.9alpha1 → ---
Reporter | ||
Comment 43•16 years ago
|
||
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.
Flags: wanted1.9.2?
Reporter | ||
Comment 44•16 years ago
|
||
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.
Reporter | ||
Updated•16 years ago
|
Component: Layout: Form Controls → General
Flags: wanted1.9.2?
Product: Core → Firefox
QA Contact: layout.form-controls → general
Reporter | ||
Updated•16 years ago
|
Severity: normal → enhancement
Flags: wanted-firefox3.1?
Comment 46•15 years ago
|
||
(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.
Comment 48•15 years ago
|
||
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.
Updated•15 years ago
|
Component: General → Layout: Form Controls
Flags: wanted-firefox3.5?
Product: Firefox → Core
QA Contact: general → layout.form-controls
Comment 49•15 years ago
|
||
We lost the wanted Firefox 3.5 flag, but there is nothing to replace it. Absent that, marking the closest remaining choice: "blocking 1.9.0.19"
Flags: blocking1.9.0.19?
Comment 50•15 years ago
|
||
(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 1.9.0.19"
That is Firefox 3.0 and this would in no way block a very old branch security/stability update release.
Flags: blocking1.9.0.19?
Comment 52•7 years ago
|
||
"WONTFIX" or "WORKSFORME"?
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•