Open Bug 92286 Opened 20 years ago Updated 3 years ago

Mimic native radio/checkbox rendering (remove groove)


(Core :: Layout: Form Controls, defect)

Not set





(Reporter: jameslariviere, Unassigned)



(Keywords: access, polish, testcase)


(3 files)

Spun off from bug 56585.

I think we should mimic native radio and checkbox rendering.  Currently mozilla
focuses with a groove border that looks odd.

Just by removing one rule in forms.css we can get rid of this rendering:

input[type="radio"]:focus {
  border-style: groove;
Summary: Mimic native radio/checkbox rendering (remove groove) → Mimic native radio/checkbox rendering (remove groove)
With that rule removed, there is no way to tell if a form widget has focus.
Just want to point out that NAV4.x and KDE konquerer does not render any focus
event and neither do windows or linux natively render a focus event.
Just because native widgets have bad accessibility does not mean we should too.
Keywords: access
What is the advantage if this bug is fixed by removing the groove? Personally I
do not like the groove, but I want a way to tell if a radiobutton has focus.
Idealy all radiobuttons would have labels and the labels can have a dotted
border around them (maybe another rfe?), but at the same time I think that we
still need a way to show that the radiobutton has focus. I would suggest drawing
a dotted border around the radiobutton (in a circle), but I've a feeling that it
the radiobutton has to be rebuild for that.
Target Milestone: --- → Future
I think this makes all the radio/check buttons ugly.  Plus it just plain doesn't
look right.  Why not just do the same thing for radio/checks as is done in the
prefs panel for example (or even the installer for that matter).  Click on/off
the button and it shades out and leaves (or un-does) it's mark.  I don't see why
I need to have anything hanging around to draw focus AFTER I've already checked
what I want...besides, the way it is now, as soon as you click anywhere on a
page after checking a box or radio, the ugly raised apearance goes away anyway,
so what's the point?  It's just another step not needed to bring whatever
button/box you're clicking to look 'normal'.  Anywayz, thanks to James for
pointing out where that can be removed from.
Let me clarify the accessibility issue.  If I am _not_ using a mouse and am
instead tabbing around a form using the keyboard, there is currently a way to
tell which control is focused.  That's the control that has the groove and if I
were to hit spacebar that's the control that would be triggered.  Please do not
remove this option -- not everyone uses mice or wants to.

> draw focus AFTER I've already checked what I want

As I just explained, the point is to draw focus _before_ the checkbox is
selected. Please do not confuse focusing the checkbox and clicking on it; not
the same thing.
IE is clever on this one and renders a groove square focus box, albeit _around_
the focused item.  This both looks OK, and is good for accessibility.
Attached image Screenshot
This is how IE 5.5 on Windows renders a focused radiobutton. It does the same
thing for checkboxes.

I think this is what we should do for Mozilla as well, what do you guys think?
I think that looks fine - Keeps the functionality along with keeping a 'natural'
look of the button/box themselves.
Would someone please explain what i missed?
This whole bug is about focus-behaviour on radiobuttons and checkboxes. You
missed to focus any of the test-widgets in the testcase.  I suggest you read the
bug before commenting.
ok, trying again now that i kind of understand what's going on.

imo merely setting the fill color isn't sufficient, if you happen to get focus
lost somewhere under something, and doing that somehow triggers another control
to go to the 'disabled' state, then it would have the fill color and you might
think you're on that control.  As always, there may not be any text attached to
a control, so having disabled and focused look the same is a bad idea.

hrm, fwiw i probably had one of the last 6 widgets focussed but i couldn't tell.
 bz is right, the proposed change alone is unacceptable.
Keywords: fcc508
I kind of like hwaara's suggestion though I'm wondering if the focus box could
be smaller/closer to the widgets?
I think that Håkan hit the point of this bug in comment #9 and a screenshot to
show it.  This is what I think mozilla should show (it works great for links).

Adding a couple of bug depends.
Depends on: css2outline, 151375
bug 151375 sounds like a duplicate, rather than a dependency.
Keywords: sec508
Assignee: rods → nobody
QA Contact: madhur → layout.form-controls

I don't think this is still an issue, is it?

You need to log in before you can comment on or make changes to this bug.