"style" attribute not supported in <select> list

VERIFIED WORKSFORME

Status

Camino Graveyard
HTML Form Controls
P3
minor
VERIFIED WORKSFORME
15 years ago
11 years ago

People

(Reporter: Avi Drissman, Assigned: Chris Lawson (gone))

Tracking

unspecified
Camino2.0
PowerPC
Mac OS X

Details

Attachments

(5 attachments, 4 obsolete attachments)

(Reporter)

Description

15 years ago
The "style" attribute doesn't seem to be supported in a selection list.

Chimera 2003021307. Works in Mozilla 1.3b.
(Reporter)

Comment 1

15 years ago
Created attachment 114369 [details]
Shouldn't this text be red?
Tesxt still not in red in 2003082402. 

Comment 3

13 years ago
We probably have some form CSS that's overriding it.
Assignee: bryner → sfraser_bugs
Priority: -- → P3
Target Milestone: --- → Camino1.0
*** Bug 315203 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

13 years ago
Created attachment 201969 [details] [diff] [review]
patch for forms.css for embedders

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
Assignee: sfraser_bugs → bugzilla
Status: NEW → ASSIGNED
(Assignee)

Comment 6

13 years ago
Created attachment 201970 [details]
testcase for SELECT transparency

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

Comment 7

13 years ago
It's at
http://lxr.mozilla.org/mozilla/source/layout/style/forms.css

Note that it gets preprocessed.
(Assignee)

Comment 8

13 years ago
Created attachment 201971 [details] [diff] [review]
version 2, just without !important

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

cl
Attachment #201969 - Attachment is obsolete: true
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)?
Created attachment 201976 [details]
Testcase showing where we get into trouble with version 2 patch

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).
(Assignee)

Comment 12

13 years ago
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
Created attachment 201978 [details]
Updated with a select with default phpBB2 styles

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.
Attachment #201976 - Attachment is obsolete: true

Comment 14

13 years ago
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.

Comment 15

13 years ago
Created attachment 201984 [details]
Showcase that compares with Input Text and Textarea
Created attachment 201985 [details]
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.

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.
Created attachment 201986 [details]
More extensive testcase, incorporating both "Updated" and "Showcase"
Attachment #201978 - Attachment is obsolete: true
Attachment #201984 - Attachment is obsolete: true
(Assignee)

Comment 18

13 years ago
(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
(Assignee)

Comment 19

13 years ago
For the record, Safari disallows any styling of form controls too.

cl
(Assignee)

Comment 20

13 years ago
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.... :-(
(Assignee)

Comment 22

13 years ago
(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.
Target Milestone: Camino1.0 → Camino1.2

Comment 24

13 years ago
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.

Comment 25

12 years ago
*** Bug 328658 has been marked as a duplicate of this bug. ***
QA Contact: winnie → form.controls
Target Milestone: Camino1.2 → Camino2.0

Comment 26

11 years ago
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.

Comment 27

11 years ago
Fixed by trunk work (there's a remaining issue with the background of menu selects, but that's another bug).
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

11 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.