58755 - lycos.com - Radiobuttons don't render as checked

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Blake Ross]

Build ID: new {branch, trunk}

Steps to Reproduce:
(1) Go to http://hotbot.lycos.com/super.asp
(2) Try to check any of the radio buttons on the page

Result: the buttons just remain in the focused state.  Also note that the right 
radiobuttons aren't checked upon page loading as they should be.

Comment 1

[buster]

is it that they aren't checked, or that they just aren't painting as checked?

Comment 2

[Blake Ross]

just don't appear checked.

Comment 3

[Ben Guthrie]

I don't know if it's related, but when I look at my portfolio at The Motly Fool
( http://quote.fool.com/portfolios/index.htm )  selecting the radio button doesn't
"stick".  Specifically, in my case, when I select the "by trade lot" option, the
page refreshes as it should, but remains "by ticker" This doesn't happen with NS
4.75.  My nightly is a day old: 2000103104

Comment 4

[rods (gone)]

The site has bad CSS:

<style>

<!--

#LycLnk{COLOR:#00ff00;TEXT-DECORATION:none}

#searchFont{font-size:14px}

#bgGreen{background:#99FF33;color:#99FF33;}

-->

</style>

They are purposely setting the color of the checkbox BG and of the "dot" to the 
same color.

somebody should let them know, so they can change there style rules

marking invalid

Comment 5

[buster]

I think if you mark it invalid, the evang folks won't see it.  So I'm going to
reopen, just to reassign to them.  Thanks for the analysis.

Comment 6

[buster]

Rod says:  tell them to fix their broken CSS.

Comment 7

[Blake Ross]

-> [e-mail] for my evangelism bugs.

removing the now-depreciated evangelism-related keywords.

setting platform to All.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There's nothing in the CSS spec that says that's how color and background should
apply to radio buttons.  If it's incompatible with other browsers, then we
should fix our implementation.

Comment 9

[Blake Ross]

Reassigning evangelism bugs to [e-mail].

Comment 10

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.

Comment 11

[Doron Rosenberg (IBM)]

contact via webform.

Comment 12

[Bob Clary [:bc] (inactive)]

doron, when you contact them mark it assigned so we can track it. thanks. bc

Comment 13

[Doron Rosenberg (IBM)]

forgot that, thx

Comment 14

[rods (gone)]

As per Dbaron's comments maybe we should fix this in the code, I will attach a
patch.

Comment 15

[rods (gone)]

Attachment: simple patch for background and color are the same

Comment 16

[Eric A. Meyer (dead account)]

The patch seems like it's hacking around the problem rather than addressing the
root question: how should form elements be styled?  What properties apply, and
how?  We don't know, I admit, but the patch seems tome the kind of "silently
rescue the author" behavior that has made Internet Explorer infamous in
standards circles.  A better solution might be to block the styling of form
elements' foregrounds and backgrounds until the CSS WG finishes its UI module.

Comment 17

[rods (gone)]

I really don't like the hack either. But we use style to color the BG and the
"dot". IE uses the "background" color for coloring what is bacically the margin
that is around the outside of the circular border. Or in otherwords, they really
don't let you style the radiobutton. We allow it, but one could almost argue "in
a non-standard" way because the standard doesn't specify what attrs are to be used.

We could use the "!important" rule and just use some standard colors, but I hate
tying the hands of web developers also (meaning I would immediately see bugs on
that, they hate the !important rule) I don't feel strongly about any particular
solution, but the user should always see a "dot"

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I agree with Eric.

Comment 19

[Eric A. Meyer (dead account)]

My point is basically this: no browser does a great job of styling form
elements; Gecko is probably the best one out there.  But until the CSS WG
finishes the UI module, we don't know how things like radio buttons and
checkboxes should be styled.  The WG might add a property called 'widget-color'
and specifically forbid styling the dots and checks with 'color'.  (No, I don't
think they'll actually do that, but the general point stands.)

My point was basically that we're risking forward compatibility by allowing
styles in this manner, which is classic "embrace and extend" behavior.  We've
found a potential problem: great.  Bring it to the attention of the CSS WG, if
it isn't already covered in the UI module.  When we know what the final
standards say, we can implement that (whatever it is).  In the meantime, we
really ought to consider rolling back the styling of form widgets for the
reasons I give above.

Comment 20

[rods (gone)]

Ok, I agree with all of that.

Except we can't roll anything back because that is the way we do it. But we 
could make the current rules "!important" and we should be fine.

Comment 21

[rods (gone)]

Attachment: patch for forms.css until the issue with the spec get worked out

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

r=dbaron

Comment 23

[Marc Attinasi]

I'm happy with making the rules !important, but I don't think Pierre will like
it (see the discussion in bug 43220). sr=attinasi

Comment 24

[Pierre Saslawsky]

CCd Ian and Daniel. Marked dependency on bug 43220.

Marc, it depends on what the WG decides this week.  If go with the current 
recommendation (ie. UA-!important can be overrided), I have no problem with this 
patch.  The color can still be overrided in the User stylesheet.  If we go with 
Ian's proposal (ie. UA-!important cannot be overrided), then I'm against it.  It 
would represent a clear abuse of what UA-!important is intended to do, both by 
the spec and Ian's proposal.

I'm against this patch for now.  We should at least wait and see what decision 
comes out of the WG.  This being said, Rod, you have r=dbaron and sr=attinasi so 
you might as well ignore my opinion and check in if you like.

Comment 25

[kurros (Wade Majors)]

URL was 404, updating.

(Problem still exists)

Comment 26

[Doron Rosenberg (IBM)]

been a long time, but I've been seeing this reported on topsites in europe.

Is anyone agaist this going in?

Comment 27

[Susie Wyshak]

Not just Europe...many top US sites are affected by this.

moving bug to browser component

Comment 28

[Doron Rosenberg (IBM)]

perhaps have this only in quirks mode?

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This seems perfectly reasonable to me in all modes, although perhaps others
disagree.

Comment 30

[Doron Rosenberg (IBM)]

with the patch, can it happen that a user defines the color of say a checkbox
(whickh will affect the checmark) to be the same color of the background color
we set, thus creating a usability issue?

Comment 31

[Eric A. Meyer (dead account)]

Marking topembed for usability reasons.  I could see restrciting this to quirks
mode, but I could just as easily see having it apply in all modes.  Other
browsers also refuse to style forms-- NN4.x, of course, but also Opera 6.  IE/*
styles some aspects of some form elements, but not others.  And so on...

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 46444 [details] [diff] [review]
patch for forms.css until the issue with the spec get worked out

Marking prior reviews (see comment 22 and comment 23) in patch manager.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does topembed+ currently mean it needs to land on a certain branch at some
point?  (If so, when?)

Comment 34

[Boris Zbarsky [:bzbarsky]]

That patch does not apply any more (needs to be updated to current version of
the file).

The general idea makes plenty of sense to me, though.  And I think we should do
this in both standards and quirks mode.

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: updated forms.css patch

reviews?

Comment 36

[John Keiser (jkeiser)]

Comment on attachment 94849 [details] [diff] [review]
updated forms.css patch

r=jkeiser

One of these days we need to make radio paint the circle itself instead of
having the inner button be a frame unto itself.  What a waste of space.

Comment 37

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 94849 [details] [diff] [review]
updated forms.css patch

sr=bzbarsky

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in, 2002-08-14 05:42 PDT.

Comment 39

[Alfred Kayser]

Checkout the forms.css in LittleMozilla.
I use a set of images to draw the radiobuttons themselves,
so that they are less dependent on border settings.

Url to use for Verification: 
http://www.deskmod.org/?show=showcat&cat_name=mozilla

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For the record, this caused regression bug 164484.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

susiew: If nsbeta1 (which changes meaning every few months) means you want this
on a certain branch, you need to let me know, because otherwise I won't know. :-)

Comment 42

[Jaime Rodriguez, Jr.]

who in QA can verify this as fixed for the trunk?

From email from Evangelist, "This is a usability/accessibility issue that
affects many sites. Radio buttons are not white when on a colored background;
they assume the background color."

The fix has been baking on the trunk for 3 weeks, with no known regressions.
Adding edt1.0.2 and Mozilla1.0.2 keywords to nominate for 1.0 branch landing.

Comment 43

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 94849 [details] [diff] [review]
updated forms.css patch

a=[e-mail] for 1.0 branch.  Please make sure the regression fix is
included in the checkin.  You know the drill

Comment 44

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_0_BRANCH (along with that for bug 164484),
2002-09-11 13:39 PDT.

Comment 45

[Susie Wyshak]

Using 2002-09-17-09-1.0 commercial branch on Win2K the radio buttons look good on 

http://www.paylessloans.com/
http://hotbot.lycos.com/?query=&cobrand=&matchmode=all&datedelta=0&language=any&recordcount=10&descriptiontype=2&modsign1=MC&dateoption=within&placeselection=georegion&act.super.x=104&act.super.y=7&act.super=%2BRevise%2B
http://www.usairways.com/

Comment 46

[Gayatri Rimola]

Please verify the bug. Once verified, change the keyword fixed1.0.2 to
verified1.0.2 

Comment 47

[lchiang]

Ian - I'm focusing on getting verifications to bugs checked into
MOZILLA_1_0_BRANCH completed by September 30.  Since you're the QA contact on
this bug, do you have any objections if I ask a member of Netscape QA to mark
this bug verified as it pertains to the branch?  Thanks.  (This will apply to a
few add'l bugs where you are QA contact.)

Comment 48

[Hixie (not reading bugmail)]

No problem at all.

Comment 49

[Madhur Bhatia]

verified fixed
--- 2002-10-03-trunk build
--- 2002-10-03-1.0 branch build

changing status to verified + changing KW from fixed1.0.2 to verified1.0.2

Comment 50

[Boris Zbarsky [:bzbarsky]]

*** Bug 120021 has been marked as a duplicate of this bug. ***

Comment 51

[nemo]

Say this bug has been around for a long time, and the comments discuss pretty well the issues that caused the decision to put !important in forms.css on checkbox colour, background colour and border.

If the issue is just allowing the user to see the dot, however, could a compromise be made to allow a bit more flexibility?

For one thing, you have to enable -moz-appearance: none nowadays to even begin to screw up checkbox styling.

However, even if this wasn't enough, could perhaps the !important be restricted to colour? 

Seems that unless you wanted to style a checkbox with a black background (which I think would be pretty obvious to the user as being the website's fault), the check would not be obscured.  And background-color would still be a useful style attribute. 

Of course, given the need to explicitly set -moz-appearance: none;  it'd be nice if the !important were simply removed.  They get in the way of both website stylings and stuff like userstyles.org.

Just bringing this up since periodically we get people complaining about Firefox' lack of flexibility compared to, oh, IE when it comes to styling form inputs.  This decision to utterly remove the ability to adjust colours on checks has spawned a number of bugs too.

Comment 52

[Boris Zbarsky [:bzbarsky]]

> which I think would be pretty obvious to the user as being the website's fault

Uh... except quite a number of sites set black backgrounds on _everything_.  And yes, the users tend to blame the browser if the site is "broken" and doesn't look exactly like it does in IE (in that order; you can get away with differences as long as they don't affect the user).

Also, allowing styling of the border makes it easy to make radio buttons invisible.. Of course all that is covered in this bug.

> lack of flexibility compared to, oh, IE

IE doesn't style the same things the Firefox styles, as you might have noticed.  For example, border and background styling for radios work very differently in IE.

If you want to be able to style form controls, there needs to be a standard for how it should work.  Until then, random behavior changes just cause confusion and create more harm than good.

Comment 53

[nemo]

Good points from Boris, just wanted to make one more plea, then I'll stop poking a closed bug.
http://m8y.org/tmp/testcase71.xhtml  -  Demo of the inconsistency/incoherence of Moz behaviour - invisible text field and button.

You can't protect websites from themselves, that's not really what CSS/HTML is about.  And users can always override with userstyles.org addon or at least they could if it wasn't being forced in forms.css.

Re: black backgrounds on everything.  Yeah, although they'd have to be going out of their way to screw up checkboxes if they set -moz-appearance: none.

You're right, I did realise setting border could make it invisible, and yes, is well covered in bug.

My other hope was that perhaps forms.css could use some extra "weight"  to its rule  (html > body input["checkbox"] to make it hard, but not impossible to override).  But I suppose if a site is deliberately setting -moz-appearance: none;  they'd have no trouble setting !important too.

Still, it is a shame this is all focused on radio buttons.  As noted, there are plenty of other fields in a form a person can make invisible.  I wonder if forms.css would have forced them too, if a bug had been filed.

Comment 54

[Boris Zbarsky [:bzbarsky]]

> forms.css could use some extra "weight"  to its rule 

That doesn't work, because any author rule overrides any UA rule...  :(

I think forms.css would have forced other controls if there had been a problem with them.  But for the other controls IE interpreted border/background in a much more sane way, so people who tested only in IE didn't accidentally create pages broken in Gecko, which was the problem with radios/checkboxes.

Which brings us back to the fact that for the whole thing to work UAs need to be doing the same thing with border/background/etc on form controls.