Closed Bug 53927 Opened 24 years ago Closed 2 years ago

Focus outlines (ring) should look like Aqua focus outlines on Mac OS X (text fields, listboxes, links)


(Core :: Layout: Form Controls, defect, P3)






(Reporter: mpt, Unassigned)


(Blocks 1 open bug)


(4 keywords)


(14 files, 2 obsolete files)

2.80 KB, image/png
3.74 KB, image/png
3.99 KB, image/png
7.24 KB, image/png
6.65 KB, image/png
2.60 KB, image/png
3.38 KB, image/png
3.59 KB, image/png
917 bytes, image/png
4.00 KB, image/png
4.49 KB, image/png
14.61 KB, image/png
21.22 KB, image/png
3.41 KB, text/html
This is son-of-bug-50804.

On Windows, focus for widgets is shown with a 1px rectangular dotted black line. 
The same style is used to show focus for hypertext links, in both Mozilla and IE 
for Windows.

On Mac OS **ONLY**, focus for widgets is shown with a 2px rounded line in the 
Appearance Manager variation color (#6666CC by default). The same style should be 
used (and is used, in IE 5) on Mac OS **ONLY** to indicate focus for hypertext 
links and form controls.

This depends on bug 1004 (proper value for variation color) and bug 24676 
(rounded corners for outlines). However, a partial fix is available and should be 
checked in for Mac OS **ONLY**.
Graphical mockup of wanted behavior:

Partial patch for html.css for Mac OS:
Depends on: 1004, 24676
Keywords: patch
Wait, so this should be ALL/ALL, right?
Keywords: pp
I don't think the partial fix is ready to be checked in.
1. is "Ian Hickson's Mailbox". My mailbox doesn't fix bugs,
   so assigning bgus to it won't help us. :-)

2. Doing this requires build changes, since we do not have platform specific
   ua.css files at the moment.

3. The patch is not acceptable, since it hard-codes a colour. If there are no
   CSS system UI colours that map to the "alternative" colour on Mac, then
   we should either introduce a stop-gap Mozilla colour -moz-alternative or
   some such (bryner knows how to do this, cc'ed) or wait for CSS3 to become 
   stable and use that.

4. The outline as currently described by the patch is ugly, even on Mac. 
   We need to improve it.

Reassigning to Marc for now. Moving to Future since this is low priority and
we have no usable patch at the moment.
Assignee: ianh → attinasi
Keywords: patchcss-moz, css3, helpwanted
Target Milestone: --- → Future
Accepting, leaving milestone.
Actually, fixing 1004 won't help this bug. You need the fix to bug 46174 to get 
the right colour.
Depends on: 46174
No longer depends on: 1004
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
qa contact updated.
QA Contact: gerardok → bsharma
Please see also accessibility bug 74225 - prefs needed for focus appearance.
I'm not sure how a fix for this bug would affect 74225, or vice-versa.
Depends on: css2outline
SPAM. HTML Element component is deprecated, changing to Layout component. See
bug 88132 for details.
Come on Bugzilla, you can do it...
Component: HTML Element → Layout
QA Contact: bsharma → moied
I wonder if this would be able to work via nsITheme to use real focus widgets
(at least on OS X).
I suggest wontfixing this even though I originally filed bug 50804 or making it
so that clicking a focusable item doesn't show the focus outline *by default*.

Some designers find even the 1px dotted outline unacceptable and think it looks
bad on their design. Hence, they try to find ways to defeat it. If the focus
outline becomes more conspicuous, there will be more designers who'll
successfully defeat it (via CSS or via JS .blur()). Then the effective result
would be that keyboard navigation became harder.

A similar thing has already happened with the page background color and the font
size. The old grey background default in Netscape 1 thru 4 wasn't acceptable to
designers so they overrode it with something else--usually white. If the default
has been acceptable to designers (white), they wouldn't have overridden it and
changing it in the browsers pref would actually be effective for those who want
to change it. Also, many designers believe that 16px is too large for the body
text. So they override it and adjusting the font size is harder for the user
than it should be. (I want 18px on my home display.)

So I think the defaults should be chosen in such a way that the designers
doesn't want to defeat them. (I think the border around link images is a bad
default, for example.)
Blocks: 73812
This bug needs a new owner.

See also bug 151375.
QA Contact: moied → petersen
Why can't our focus outlines get this appearance on all platforms? Is there
something sacred about the hard-to-see way we do focus outlines right now?

I have pretty good vision, but I really have a hard time finding our keyboard
focus sometimes.
> Is there something sacred about the hard-to-see way we do focus 
> outlines right now?

Yes. I think the focus outlines should be hard to see by default but there
should be an easy way (yet another pref, yes) for the user to make them better
visible. If we make them easily seen by default, more Web authors will try to
defeat the focus oulines leading to worse overall accessibility. See comment #14.

Case point: Image links have borders by default in Mozilla in order to allow the
user to distinguish image links. Have you seen borders around image links lately
with the default settings?
I think one reason why we do it this way now is because we have issues if we
draw the focus outline outside of the bounds of the form control frame (it won't
get refreshed or erased correctly). But I agree that the current focus
indication is truly awful.
Simon, yes that's bug 151375.

Drawing outside the frame can be done, we just have to be clever.
Depends on: 151375
shifting platform to OS X, since we no longer support pre-OS X Mac.
OS: Mac System 8.5 → MacOS X
Assignee: attinasi → nobody
Summary: Focus outlines should look like Mac focus outlines on Mac OS [outline] → Focus outlines should look like Mac focus outlines on Mac OS
We're getting closer with -moz-outline (fixed in bug 151375) and
-moz-outline-radius (bug 24676). We also need outline-offset.

Would those be enough to write a css rule for this?

Does someone have time to post a screenshot of focus outlines on the mac?
I'd like to see what it looks like for text links, buttons, image links,
textfields and anything else with a unique focused look.
Attached image Focused text link appearance (obsolete) —
Still looking for images of other focused controls.
Depends on: 251498
Attachment #153250 - Attachment is patch: false
Attachment #153250 - Attachment mime type: text/plain → image/png
Attached image Checkbox, unchecked
Attached image Radio buttons
Attached image Slider
- Multi-line text links. Combining the outline into one blob instead of having
intersecting lines hasn't been filed as a bug yet.
Also, what do Safari's text link outlines look like? I noticed IE's don't have
the fade effect.
- image map area focus rings - Mozilla's are horrible, but I think that would be
fixed in a separate bug.

Do people feel that we need the fade effect for Mozilla's Mac focus outlines
right away? Or would something like IE Mac's focus outlines be good enough to start.
Is there any potential CSS for fading focus outlines anyway? Something like
outline: 3px fading blue
Win/GTK version of this is bug 251998.
Look closer. IE/Mac's focus rings do fade, but (1) the colors are wrong (IE's
"Aqua" theme differs slightly from OS X's), and (2) they aren't anti-aliased.

Safari's text link rings are the same as IE's, except the colors are accurate. 
(I had forgotten Safari had rings because I don't use Full Keyboard Access.)

Helpful CSS extensions would be -moz-outline-collapse (following CSS2's border-
collapse) and -moz-outline-*-colors (following Gecko's -moz-border-*-colors). 
The latter would perhaps be better than "fade", because then focus rings would 
remain visible on pages where the background color = one of the ring colors.
Now that we have -moz-outline, -moz-outline-radius and -moz-outline-offset we
have enough to start experimenting with a fix.

The main things we haven't done for outlines:
1. Make overlapping outlines on the same element glob together (bug 266122)
2. Outlines not being rendered for some elements (bug 250269)
3. Remove the -moz prefix from these property names (bug 6647, not really
blocking this)
How does Safari/IEMac handle it when the background of the web page is the same
color as the blue outline focus ring? Or do they do nothing, and the focus ring
is very difficult to see?
my guess is they just let it blend in with the background.
This simulation requires a trunk build that contains the fix for bug 250269
(checked in on 11/11/2004 around 11 am -- cool).

Ignore the dotted outlines on selects and buttons -- those would go away. Also,
I notice that the outline for combo boxes goes too far to the right.
Comment on attachment 165562 [details]
Mac outline simulation v1 -- intended to start a discussion

Thanks for working on this Aaron.

1. The color is wrong.
2. We shouldn't draw the focus ring around buttons until we draw "native"
Component: Layout → Layout: Form Controls
Summary: Focus outlines should look like Mac focus outlines on Mac OS → Focus outlines (ring) should look like Mac focus outlines on Mac OS
> How does Safari/IEMac handle it when the background of the web page is the
> same color as the blue outline focus ring?
IE's remain visible, but Safari's do not. See comment 38, final sentence.
> Color
> still probably not the prettiest.

Use "-moz-mac-focusring"?

The Accessibar extension provides this functionality. Not perfect, but pretty nice.
Summary: Focus outlines (ring) should look like Mac focus outlines on Mac OS → Focus outlines (ring) should look like Aqua focus outlines on Mac OS X (text fields, listboxes, links)
Depends on: 415466
QA Contact: chrispetersen → layout.form-controls
Kinda crazy that this issue has just stayed open since 2009 having been opened in 2000.  This bug is almost as old as my company.

Thanks Mats for closing the bug I filed, but surely there could be efforts to address this.  

None of these discussions took place after WCAG 2.0 was released (which was a long time ago now).
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

We have better outlines now.

Closed: 2 years ago
Flags: needinfo?(emilio)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.