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)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
enhancement

Tracking

()

People

(Reporter: aaronlev, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: access, uiwanted)

Attachments

(3 files)

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
Details
safari's use of focus rings
18.08 KB, image/png
Details
current critical outline / proposal
2.41 KB, image/png
Details 
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.
Summary: Bright, clear focus appearance for HTML content on Win/GTK platforms → Bright, clear focus appearance for HTML content on Win/GTK platforms
Depends on: 251498
Priority: -- → P2
Status: NEW → ASSIGNED
Assignee: aaronleventhal → pilgrim
Status: ASSIGNED → NEW
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.
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) [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.
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.

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.
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?
Target Milestone: --- → mozilla1.9alpha
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.
Blocks: keya11y
*** 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
Blocks: fox3key
No longer blocks: keya11y
OS: Windows XP → All
Depends on: 390719
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
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 → ---
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?
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.
Component: Layout: Form Controls → General
Flags: wanted1.9.2?
Product: Core → Firefox
QA Contact: layout.form-controls → general
Severity: normal → enhancement
Flags: wanted-firefox3.1?
(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?
Keywords: uiwanted
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.
Component: General → Layout: Form Controls
Flags: wanted-firefox3.5?
Product: Firefox → Core
QA Contact: general → layout.form-controls
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?
(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?
"WONTFIX" or "WORKSFORME"?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: