58048 - [Pref Stylesheet]`Always use my colors' shouldn't remove colors from form controls [CASCADE]

Status: RESOLVED FIXED

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

Description

[Matthew T (active 1999-2002)]

Build: 2000102420, Mac OS 9.0

To reproduce:
* Open the Colors panel of the Preferences dialog.
* Set your default background color to the lightest yellow shade which you are
  allowed to choose with the current colorpicker.
* Turn on the `Always use my colors' preference.
* View this bug report.

What happens:
* All the form controls have a light yellow background, the same as the page.
* Buttons and popup menus start looking like inverse text entry fields.

What should happen:
* Form controls should retain their white or gray background colors.

Comment 1

[Marc Attinasi]

Accepting bug (thanks for filing it, mpt).

The first big question is: why not make controls take on the colors of the
user's preferences when they indicate that they want to force their colors? Nav
didn't do it, but that is a moot point because its controls were all native and
could not be colored at all. Maybe it *is* appropriate to apply the preferred
colors to the controls. We apply the preferred fonts when the user wants their
fonts to override too, is that a bug as well?

The next big question I have is (assuming we decide that we do need to preserve
the 'normal' colors of the controls): how important is it to preserve the
ability for authors to modify the colors of form controls? Looking at the
settings in html.css, it seems like we are using system-dependent settings for
form controls, which suggests that we want the controls to look more or less
like system controls (i.e. native widgets). If this is true, then we can simply
make all of those background and color rules important to fix this bug. Authors
will have difficulty then in modifying the colors of controls, and CSS certainly
allows them to do just that.

My opinion is that we need to fully support the ability of authors to change the
colors of controls using normal author stylesheets, so making the html.css rules
!important is a bad idea. Given that, I cannot imagine a reasonably concise set
of rules to implement the 'force my colors' pref such that form controls are not
affected... maybe if we used some non-CSS selector syntax that allowed exclusion
of some element types it would work, but I imagine the performance would suck.

CC'ing rod for his form control input, and david baron for his general wisdom.

Comment 2

[Marc Attinasi]

Applies to all platforms/OS's

Comment 3

[Matthew T (active 1999-2002)]

In any other GUI, native widgets are the system colors by default (threedface 
etc), regardless of the background color of the window -- they do not inherit the 
background color of the window under them. I can think of no good reason for 
Mozilla to be any different in this regard. Currently, with `Always use my 
colors' turned on, only their borders are preventing form controls from 
disappearing altogether; the controls appear to be transparent, which reduces 
their apparent clickability, and there is not much visual distinction between 
text fields and buttons.

> We apply the preferred fonts when the user wants their fonts to override too,
> is that a bug as well?

Pardon? What's the difference between `the preferred fonts' and `their fonts'?

> I cannot imagine a reasonably concise set of rules to implement the 'force my
> colors' pref such that form controls are not affected...

I'm not a CSS expert, but isn't there some way of saying `this rule only 
overrides conflicting rules in author.css, it does not override conflicting rules 
in html.css'? You need to override fonts/colors specified by the author, but not 
those specified by html.css. See also bug 58195.

Comment 4

[Marc Attinasi]

>> We apply the preferred fonts when the user wants their fonts to override too,
>> is that a bug as well?
> Pardon? What's the difference between `the preferred fonts' and `their fonts'?

None, what I meant to say was that we apply the users preferred fonts to
controls when they specify 'always use my fonts' so why not use their preferred
colors when they say 'always use my colors'?

I'm less concerned with what other apps do in this regard. I'm more concerned
with what is most useful to the user, and after that, what is correct CSS. If
making the controls' backgrounds transparent makes the controls hard to use,
then it is bad. If it makes them easier for some people to see and thus easier
to use, then it is good. I'm not yet convinced one way or the other. As for CSS,
it is clearly the intention of CSS to allow authors to change the colors of
controls. I'd like to preserve that ability. Also, if CSS allows control colors
to be changed, then how can we argue that our own app should not be changing the
control colors according to the user's preferences? Ideally we would give the
user the choice byt providing another option 'apply my preferred colors to fomr
controls too', but there is another problem, and that is with our limited
implementation options...

So far, all I have been able to come up with as a solution to preserve the
control colors is to make the corresponding rules in html.css !important. The
drawback is that author stylesheets will have to use !important rules to change
the colors of the controls, and according to CSS we are suppossed to allow
authors to freely change the colors of the controls. Thus, to make the controls
retain their native look when the 'always use my colors' option is set, we have
to limit the ability of authors to change the colros of the controls. I don't
like this too much, as I can see where authors will want to change control
colors to make really slick forms.

I'm open to suggestions on how to re-craft the style rules to make controls both
overridable by authors, and immune to the 'always use my colors' options.

Comment 5

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

> As for CSS,
> it is clearly the intention of CSS to allow authors to change the colors of
> controls.

Clearly?  The spec doesn't say anything about form controls.  It doesn't explain
how any CSS properties would apply to them.  It doesn't describe a model under
which form controls can be described.  Therefore any implementation applying CSS
properties to form controls is extending CSS (and the choices made in that
implementation could easily be different from those made in other
implementations, creating an interoperability nightmare).

(I would personally prefer that CSS not affect form controls, so that authors
can style their document without worrying about destroying the system's standard
form control appearance.)

Comment 6

[Marc Attinasi]

> ... any implementation applying CSS
>properties to form controls is extending CSS (and the choices made in that
>implementation could easily be different from those made in other
>implementations, creating an interoperability nightmare).

Are you saying that applying a rule like 'textarea { background-color: white; }'
or 'input:hover { background-color: green; }'  represents an extension of CSS?
Selectors on HTML form elements apply, and there is nothing I am aware of to
indicate that they should not. You seem to be implying that a UA is free to
choose which elements style properties should apply to, or that controls are
somehow special in regard to selector matching or style rule application, but I
have seen no mention of that in the specifications.

I based my statement that CSS allows authors to style form elements on two
things: 1) there is nothing in the spec to say that selectors cannot contain
form element tags or otherwise refer to form elements, and 2) there are
references to control-specific system colors in CSS2 (18.2) and the CSS3
extension of that section in the UI draft (4.2) that indicate that styling of
buttons and fields, at least, are important.

Your preference is well noted, however others may prefer to be able to style
controls so their appearance matches the look of their website. I believe that a
great deal of effort has gone into making controls responsive to style in other
browsers as well (IE 5.5, at least). I'd be interested to see what the CSS WG
thinks about excluding controls from styling - you have more history there than
I, do you know?

As I mentioned in my previous comment, I am more concerned about what is useful
to the user. Since the 'always use my color' pref is not part of any
specification we are free to apply it as we see fit. I'm still most interested
in what benefits the user most, but then it may just be subjective in the end.

Comment 7

[Pierre Saslawsky]

This bug is valid, I think.  The pref should not change the form controls.

The rest of the debate is a completely different story that should be moved to 
the Layout or UI newsgroups.  I hope we can have a sound discussion about form 
controls for version 6.5.  The only 2 solutions I would consider valid are either 
native form controls or a completely new cross-platform widget set without any 
tie to the OS.  We have been fooled into abandoning native controls in order to 
implement the nifty xpfe widgets (http://www.mozilla.org/xpfe/nsGFXWidgets.html) 
but we are now stuck with form controls that are ugly like sin and with a half-
baked platform integration through CSS3 system colors and fonts.  We have lost on 
all fronts.

Comment 8

[Pierre Saslawsky]

I forgot to add that whatever solution we choose, form controls should be 
stylable and that's why we moved toward a XP widget set (no platform limitations, 
same predictable display everywhere).

Comment 9

[Matthew T (active 1999-2002)]

> None, what I meant to say was that we apply the users preferred fonts to
> controls when they specify 'always use my fonts' so why not use their
> preferred colors when they say 'always use my colors'?

Mozilla should applying the user's default widget fonts, e.g. Geneva, Charcoal, 
Tahoma, MS Sans Serif, or whatever (specified in the Appearance control panel 
on Mac OS, and the Display control panel on Windows), for form controls, and 
*insisting* on those fonts when `Always use my fonts' is on. Similarly, Mozilla 
should be using the user's default widget colors, e.g. gray, white, and black 
(specified in the same control panels) for form controls, and *insisting* on 
those colors when `Always use my colors' is on.

When `Always use my {fonts,colors}' is off, authors should be able to override 
these {fonts,colors}, and they should not have to use !important to achieve 
this.

How to implement this is unfortunately beyond me, but what I have described is 
what I think users expect.

Comment 10

[Marc Attinasi]

Implementation idea: With always use my colors/fonts on, we can insert rules to 
style the controls according to their default rules in html.css, but made 
!important so they cannot be overriden by an author rule. When always use my 
colors/fonts is off, then we have no special rules inserted for controls, and 
the rules in html.css will apply unless the author's stylerules override 
them (font and color rules get handled separately). It is a lot of duplication 
of stylerules but it should provide the desired behavior of: Allow author rules 
to style controls, unless the user wants to force their colors or fonts, and 
then use the standard control styles (for color/font). (This is how IE 5.5 
behaves, by the way.)

Comment 11

[Hixie (not reading bugmail)]

Another idea: have some predefined stylesheets, including one called   
   alwaysUseMyColours.css
...or whatever, and then add it or remove it from the mix the same way as we
add or remove quirk.css.

That would also make maintenance a lot easier.

Comment 12

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

> Are you saying that applying a rule like 'textarea { background-color: white
> }' or 'input:hover { background-color: green; }'  represents an extension of
> CSS?

Yes.  It's much clearer with a rule such as select { width: 200px; } , but I'd
say it's still true.  The 'background' property is only defined for boxes
(inline and block).  textarea and input elements can't be represented by such
boxes, so the background property isn't defined.

Comment 13

[Marc Attinasi]

Ian, yes it would be great to put the rules into a file, but we need a way for a 
property value to indicate that a value is in the prefs. I'm thinking we need a 
value like '-moz-pref-background-color' and '-moz-pref-link-color' that are 
computed by looking up the actual value from the pref., then we could avoid the 
code-level rules. (A way to conditionalize the !important would help too...)

Comment 14

[Marc Attinasi]

Moving out to Mozilla 1.0 - not a performance or stability issues, so I have no 
choice :(

Comment 15

[Hixie (not reading bugmail)]

xbl form controls need to be careful about this too (although I don't think
that they'll magically fix this).

Comment 16

[Marc Attinasi]

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

Comment 17

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

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

Comment 18

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

Taking

Comment 19

[Jo Hermans]

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

Comment 20

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

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

Comment 21

[Boris Zbarsky [:bzbarsky]]

So what we really want here is to not apply the prefs stylesheet to anonymous
content.  Should we be applying the normal user stylesheet to anonymous content?
 Perhaps user sheets should be cut off from anonymous content just like document
sheets are?

Comment 22

[Matthew T (active 1999-2002)]

For the purposes of this bug I don't think it matters whether the user style sheet 
can style form controls. But if users can't, then authors shouldn't be able to 
either.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Oh, yeah.  The problem here is not with the anonymous content but with the
actual controls.. <sigh>

mpt, prefs _are_ a user style sheet.

Comment 24

[David Harkness]

If I understand this bug, it means that if I set my browser colors to
green-on-black, Windows XP controls to yellow-on-blue and turn on "Use my
colors," controls on HTML pages -- not the browser GUI/chrome itself -- should
show up yellow-on-blue as per my Windows settings. Currently in 1.7.2 my browser
colors are displayed, just like the rest of the content.

If my reading of the bug is correct, as a visually impaired user I would request
that if the status quo is changed, it should be a preference. Actually, having
said that I would prefer this option so that I can make controls stand out or not.

I don't know if this is related, but using the settings above, hover popups
(e.g. email address in Gmail while hovering over the sender's name) and dropdown
lists created using popups (e.g. "Move To..." dropdown on Yahoo Mail) are
created with a *transparent* background -- not the black background color I've
chosen -- such that they are barely readable over the content they cover.

Comment 25

[Matthew T (active 1999-2002)]

That would be a reasonable idea, if it was common for other applications to have a "Controls should be: 
(*) visible  ( ) nearly invisible" option, or if people were likely to understand the purpose of such an 
option. Fortunately, neither of those are true.

Comment 26

[Frank Wein [:mcsmurf]]

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

Comment 27

[Barry Gilpin]

(In reply to comment #26)
> *** Bug 307938 has been marked as a duplicate of this bug. ***
I have read all these notes from 1 to 25 and technical though they appear I
don't think they address the problem I reported. Namely, if I switch on "Always
use my colours" then web pages lose thier background colours. Surley it's as
simple as this, let me set "Visited links" to the colour of my choice and don't
let it affect any web pages I visit.

Comment 28

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

Attachment: patch

This patch fixes this bug and bug 255829 and improves on the fix for bug 255411.  It reimplements the preference at the rule mapping level, so that it actually works by ignoring -- author-specified color, background-image, and border-*-color are ignored.  But author-specified background-color is not ignored; instead, non-transparent values are turned into the default background color.

This depends on the patch for bug 374907.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 264970 [details] [diff] [review]
patch

>+++ b/layout/style/nsCSSDataBlock.cpp
>+                        else if (iProp == eCSSProperty_color ||
...

What about moz-border-colors?  I know the old code didn't handle them, but maybe it should.

I almost wonder whether this is worth a field in nsCSSPropList so we can just do an array index operation here or something instead of having the conditional cascade....

r+sr=bzbarsky either way; file followup bugs as needed.

Comment 30

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

Attachment: patch

border_colors is a ValueList, so it's in a different chunk of code.  I fixed that (and factored a small chunk into a static method)

I should still:
 * test the moz-border-*-colors code
 * add code, as a followup, to do the same thing for transparent/non-transparent border-color as for background

Comment 31

[Boris Zbarsky [:bzbarsky]]

Also as a followup, outline-color...

This is why it might make sense to put this data in nsCSSPropList.h -- that would make us actually think about this for all properties, including new ones.  Plus the whole "don't represent data as code" thing.  ;)

Comment 32

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

Fix checked in to trunk, after testing -moz-border-top-colors.

Filed bug 380923 for preserving transparency / non-transparency of borders.

Filed bug 380924 on outline-color.

Comment 33

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

Honestly, I'm not sure if forcing border-color and outline-color to be the foreground color does more good than harm.  We might just want to leave them alone.