Closed Bug 58755 Opened 24 years ago Closed 22 years ago

lycos.com - Radiobuttons don't render as checked

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Platform:
All
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: top100, topembed+, Whiteboard: [contact][patch] [adt1])

Attachments

(1 file, 2 obsolete files)

updated forms.css patch
2.32 KB, patch
john
: review+
bzbarsky
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
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.
is it that they aren't checked, or that they just aren't painting as checked?
Assignee: clayton → rods
just don't appear checked.
Summary: Can't check radiobuttons on page → Radiobuttons don't render as checked
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

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
Status: NEW → RESOLVED
Closed: 24 years ago
Keywords: evangwanted
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Rod says:  tell them to fix their broken CSS.
Assignee: rods → blakeross
Status: REOPENED → NEW
Component: Layout → Evangelism
QA Contact: petersen → zach
-> evangelism@telocity.com for my evangelism bugs.

removing the now-depreciated evangelism-related keywords.

setting platform to All.
Assignee: blakeross → evangelism
Keywords: evangwanted
Hardware: PC → All
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.
Reassigning evangelism bugs to bclary@netscape.com.
Assignee: evangelism → bclary
Summary: Radiobuttons don't render as checked → lycos.com - Radiobuttons don't render as checked
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
contact via webform.
Assignee: bclary → doronr
Whiteboard: [contact]
doron, when you contact them mark it assigned so we can track it. thanks. bc
forgot that, thx
Status: NEW → ASSIGNED
As per Dbaron's comments maybe we should fix this in the code, I will attach a
patch.
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.
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"
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.
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.
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
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.
Depends on: 43220
Keywords: top100
Keywords: evang500
URL was 404, updating.

(Problem still exists)
URL: http://hotbot.lycos.com/super.asp → http://hotbot.lycos.com/?query=descri...
been a long time, but I've been seeing this reported on topsites in europe.

Is anyone agaist this going in?
Not just Europe...many top US sites are affected by this.

moving bug to browser component
Assignee: doron → dbaron
Status: ASSIGNED → NEW
Component: US General → Style System
Product: Tech Evangelism → Browser
QA Contact: zach → ian
Version: unspecified → other
Whiteboard: [contact] → [contact][patch]
perhaps have this only in quirks mode?
This seems perfectly reasonable to me in all modes, although perhaps others
disagree.
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?
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...
Keywords: topembed
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.
Attachment #46444 - Flags: superreview+
Attachment #46444 - Flags: review+
Keywords: topembed → topembed+
Does topembed+ currently mean it needs to land on a certain branch at some
point?  (If so, when?)
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.
reviews?
Attachment #46423 - Attachment is obsolete: true
Attachment #46444 - Attachment is obsolete: true
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.
Attachment #94849 - Flags: review+
Comment on attachment 94849 [details] [diff] [review]
updated forms.css patch

sr=bzbarsky
Attachment #94849 - Flags: superreview+
Fix checked in, 2002-08-14 05:42 PDT.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
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
For the record, this caused regression bug 164484.
Keywords: nsbeta1
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. :-)
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.
Keywords: nsbeta1 → edt1.0.2, mozilla1.0.2, nsbeta1+
Whiteboard: [contact][patch] → [contact][patch] [adt1]
Comment on attachment 94849 [details] [diff] [review]
updated forms.css patch

a=rjesup@wgate.com for 1.0 branch.  Please make sure the regression fix is
included in the checkin.  You know the drill
Fix checked in to MOZILLA_1_0_BRANCH (along with that for bug 164484),
2002-09-11 13:39 PDT.
Keywords: mozilla1.0.2+ → fixed1.0.2
Please verify the bug. Once verified, change the keyword fixed1.0.2 to
verified1.0.2 
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.)
No problem at all.
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.2 → verified1.0.2
*** Bug 120021 has been marked as a duplicate of this bug. ***
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.
> 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.
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.
> 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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: