The "style" attribute doesn't seem to be supported in a selection list. Chimera 2003021307. Works in Mozilla 1.3b.

Tesxt still not in red in 2003082402.

We probably have some form CSS that's overriding it.

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

Got it. I can't find the file in CVS, though -- the file that needs to be changed is ~/mozilla/dist/Embed/res/forms.css but it's pretty hard to do a CVS diff (and thus a patch) when the file's not in the CVS repository ;) I've attached a patch generaged by diffing the fixed file against ~/mozilla/dist/bin/res/forms.css I'm also going to upload the testcase from the recent dupe, as the two are related. cl

Testcase with yellow background. The SELECT element should (probably) not be transparent, although I'm not absolutely 100% certain on how the HTML spec says this should be handled. cl

It's at http://lxr.mozilla.org/mozilla/source/layout/style/forms.css Note that it gets preprocessed.

On second thought, let's just take away the !important declarations. Someone probably knew exactly what they were doing when transparency was declared. cl

We just need to make sure we don't get into a situation where we're honoring one color but not the other. I think we're OK here and that's mostly/more of an issue with the form buttons. Oh, no we're not, at least compared to Fx; testcase coming. Why is that transparent there (I assume that's the issue)?

We have a lot of widget styling bugs running around out there; would a tracker be useful?

The transparent bit apparently keeps the border of the select from being drawn red (in addition to everything else it does).

I don't see how our behaviour with the version 2 patch is wrong in your testcase, Smokey. The red applies to the entire div, and it appears to apply properly. There's no inheritance in the SELECT at all, in any of the three CSS declarations in the file. If I take out the style declaration in that div in your testcase, everything looks as I would expect it to. Am I not understanding what you're saying? In response to your query in comment 9, the "transparent" isn't the problem. The "!important" is, because it's forcing an override of whatever style would otherwise be applied (and thus causing bug 315203's transparency issues). cl

I added in a select with the default phpBB2 styles which will illustrate the problem of whiting out the grey parts of the menu-selects.

I am the poster of Bug 315203. I'd like to explain why I think selects with size set should be white unless they're told otherwise directly, through css: Add any other form element to the testcase and you'll see what I mean. Compare with a Textarea or a Input Text.

OK, I guess I got things confused; bug 315203 wants us not to honor styles in selects, and this bug does want us to honor styles. However, version 2 patch solves neither problem and creates new ones. 1. We now honor text-color styles in selects with size (as requested by this bug), but the bg-color of the div bleeds through, making the text unreadable. [In Fx, the text color is red but the select bg-color is white; in Safari 1.3.1, the text color is ignored and the select bg-color is white] 2. The grey part of the select menu is missing; it's now white (and the text color could be pink, if I'd thought to change that). My understanding is that selects as menu should always be standard Aqua grey-with-blue (and black text). [Fx doesn't use Aqua styles, so no valid comparison; Sf keeps text black and the widget itself grey-and-Aqua] 3. We've not solved bug 315203; the select bg is yellow. [White in Fx and Sf] Do you not see what I see? I'm not sure there's a way to 1) allow text-color and bg-color styles for select multiple when asked but 2) keep text black and bg white otherwise and 3) always keep select menus black text and grey-with-Aqua styled.

(In reply to comment #16) > Created an attachment (id=201985) [edit] > What I see with version 2 styles > > OK, I guess I got things confused; bug 315203 wants us not to honor styles in > selects, and this bug does want us to honor styles. No. Bug 315203 wants us to *default* to something that looks standard relative to the rest of the OS. Right now, we don't do that. :) > However, version 2 patch solves neither problem and creates new ones. > > 1. We now honor text-color styles in selects with size (as requested by this > bug), but the bg-color of the div bleeds through, making the text unreadable. This looks like it may have something to do with trunk/branch or with Tiger/Panther. I'm not seeing what you're seeing in the screenshot. > 2. The grey part of the select menu is missing; it's now white (and the text > color could be pink, if I'd thought to change that). My understanding is that > selects as menu should always be standard Aqua grey-with-blue (and black text). I agree with this, and your most recent testcase breaks that. I'll see what I can do about re-Aqua-fying that. > 3. We've not solved bug 315203; the select bg is yellow. [White in Fx and Sf] Again, I'm not seeing that. Seems to be a Tiger/Panther or trunk/branch thing. > I'm not sure there's a way to 1) allow text-color and bg-color styles for > select multiple when asked but 2) keep text black and bg white otherwise and 3) > always keep select menus black text and grey-with-Aqua styled. Gotta go to work, but I think I can come up with something. Meanwhile, here's a question that a friend raised: Do we even *want* to allow styles to be applied to form controls in Camino? Your latest testcase demonstrates some of the ways they can be thoroughly abused. I guess the question is this: Is Camino's Mac-standard appearance more important, or is Camino's HTML standards compliance more important? cl

For the record, Safari disallows any styling of form controls too. cl

Blah. I'm an idiot. I was applying the changes to the wrong file. When I apply version 2 of my patch to the file actually inside the Camino package, it breaks just like Smokey said. I *gotta* stop doing that! Version 1 works better, although version 1 only serves to further exacerbate this particular bug. However, it essentially mimics Safari's behaviour, and as I mentioned, I don't know if we even *want* to allow styling of form controls' backgrounds and text colours. My vote, for what it's worth, would be to WONTFIX this, un-dupe bug 315203, and solve the problem in that bug. cl

> Is Camino's Mac-standard appearance more important, or is Camino's HTML > standards compliance more important? My position has always been that we should allow as much styling as possible without breaking Aqua widgets (or making the result unuseable), but when that's not possible, I'd much rather see an Aqua widget than whatever styles some l33t h7x0r has picked. Alternatively, we could get the Gecko engineers to implement some selectors like Hyatt is using in Safari (see the button styling bug 309556) for all our form elements.... Because select-the-menu and select-the-box are the same element and the former is never styled (except font size), I think that puts us in the position of being unable to fix this bug (and I'm not sure we can fix bug 315203, either) without breaking the Aqua select-as-menu. I tried a little changing the order of things in the cascade without much luck.... :-(

(In reply to comment #21) > > Is Camino's Mac-standard appearance more important, or is Camino's HTML > > standards compliance more important? > > My position has always been that we should allow as much styling as possible > without breaking Aqua widgets (or making the result unuseable), but when that's > not possible, I'd much rather see an Aqua widget than whatever styles some l33t > h7x0r has picked. Yep, totally agree with you there. > Alternatively, we could get the Gecko engineers to implement some selectors > like Hyatt is using in Safari (see the button styling bug 309556) for all our > form elements.... We should probably re-target this for "future" if we try to talk them into that ;) > Because select-the-menu and select-the-box are the same element and the former > is never styled (except font size), I think that puts us in the position of > being unable to fix this bug (and I'm not sure we can fix bug 315203, either) > without breaking the Aqua select-as-menu. I tried a little changing the order > of things in the cascade without much luck.... :-( We can definitely fix 315203 -- I've posted how in that bug -- but I think this bug and that one are mutually exclusive. Fixing one will break the other, and vice-versa. Personally, I think 315203 is higher priority at the moment, especially considering that as far as text INPUTs, SELECTs, and TEXTAREAs go, we can (with the fixes in bug 315203) do no worse than Safari's current behaviour. cl

We moved the other style issues (save bug 315203) to 1.2.

This problem screams for a new user preference in annoyance blocking, or appearance. We seem to be going back and forth on what exactly is the Right Thing here to honor standards, but I think we need to take the view just like we have with Fonts and Colors. We have a user preference to override the styles for those elements, but not for form widgets. Looks like if we had this preference, then we could either be 100% standards compliant, or the user preference override "Don't Allow Web Sites to alter Form Style", selector would be honored.

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

I think the aqua widgets should be honored when it comes to the browser's UI, not webpage's UI. I, quite frequently, visit a site that heavily uses form elements (styled to mimic plain text links) and in Camino, Safari, and other Webkit browsers, the zillion aqua buttons makes the site looks tasteless.

Fixed by trunk work (there's a remaining issue with the background of menu selects, but that's another bug).