161261 - Either ignore CSS color values on TEXTAREA, or honor background color

Status: RESOLVED WORKSFORME

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Andreas Schempp]

In a Textarea, the background-settings are ignored, but text-color is used.
textarea-background is still white, but user-text-color is white too. difficult
to read :)

Comment 1

[saari (gone)]

->bryner, or pink?

Comment 2

[Andreas Schempp]

what do you mean?

In Mozilla (1.0, Mac OS X), every color is used. But I'm using Chimera
(Navigator), there is the textarea always white.

Comment 3

[Mike Pinkerton (not reading bugmail)]

over to bryner, though i still think we should do native text areas

Comment 4

[Greg K.]

So we allow color styling on TEXTAREAs, but not background?

Comment 5

[Andreas Schempp]

exactly

Comment 6

[Greg K.]

Attachment: Minimal testcase

Comment 7

[Greg K.]

Attachment: Revised testcase

Comment 8

[Greg K.]

Of course, there are two possible fixes: start applying the background-color, or
ignore the text color also.

Comment 9

[Greg K.]

Let's make this bug about ignoring CSS color values on TEXTAREAs, since other
form elements ignore color values anyway. Reassigning to HTML Form Controls.

Comment 10

[Greg K.]

Attachment: Revised testcase

Comment 11

[Brad Kemper]

I noticed that CSS color values are not applied to buttons, the way they are 
in IE. Is that an impossibility with Quartz form controls?

Comment 12

[Stephane Moureau]

Is it not an old bug, CSS V2 specifications do not apply to form elements, see
Mike I think. Sorry no time to search for duplicates.

Comment 13

[Brad Kemper]

It appears as though buttons are respecting the CSS attributes on font and
width. And as a Web author, I really appreciate that. So why not color? 

Comment 14

[Greg K.]

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

Comment 15

[Eddie ORourke]

Attachment: shows the css screwyness that works on some elements but not all

This test is not meant to look pleasing but to show the CSS problems within
chimera - what I am trying to point out is that SOME style settings are honored
while others are not. What is Chimera supposed to be doing? If it doesn't honor
CSS completely then I consider that a BUG! As a developer it must honor CSS
fully! If no CSS value is made then it should use the default OS appearance!

Comment 16

[Brad Kemper]

Please don't delete the ability to set form control widths via CSS. I would 
like to be able to set color too, but width is even more important.

Comment 17

[Greg K.]

(Brad, this bug has nothing to do with form control widths.)

Comment 18

[Brad Kemper]

I'm glad to hear it, except that means you are handling some of the CSS 
for form controls, but not all CSS. I would like to see CSS color handled 
too.

Comment 19

[S Woodside]

With an eye towards eventually using cocoa native widgets, note that in
interface builder you can set the background and FG colours of a textbox, but
not (either) for a button. I'd like to see chimera's widgets allow whatever
cocoa's widgets allow.

Comment 20

[Brad Kemper]

I was thinking that if the buttons were native, you could still paint a region
on top of them with the ink set to "multiply" (PhotoShop terminology) and pass
all mouse actions through.

Comment 21

[Steve Smart]

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

Comment 22

[Alan Hysinger]

Attachment: testcase for select tag

I'm not sure if I should have filed a different bug or not, so here goes:

I wanted to point out the same symptom can be observed for a select element
where the "size" is greater than 1.  My attachment also illustrates that a
select does not have a transparent background, although it is fair to add that
I haven't found a browser that renders a transparent bg on a select.  In my
case, I used the nightly from 2002-12-14.

PS this is my first bugzilla report; I invite any clues if needed...

Comment 23

[Brad Kemper]

It occurs to me that if we are going to be able to set the color for select and
text and textarea element backgrounds and foregrounds, then we should also be
able to set the highlight color, to ensure that it is not the same. Or else the
highlight should automatically set to a complimentary color, so that it does not
disappear if it is the same as the background.

Comment 24

[Gabriel Radic]

I do a lot web application development and the background/color combination is
very useful in certain cases. Please fix this, as the bug summary sais: "Either
ignore CSS color values on TEXTAREA, or honor background color".

Comment 25

[Greg K.]

As reported in bug 198822, this may be a problem with other form widgets (such
as buttons), as well.

Comment 26

[Chris Casciano]

looking at attachment 107526 [details] in Camino 2003032008 the textarea case is infact
adhering to *both* the background color and the forground settings (color & type
size) so the original issue brought up by this bug seems to have resolved itself.

However, when entering text in the textarea element the vertical scollbar
appears with no handles (horiz seems ok) [this is probably a separate bug, if
not filed already]

As referred to in comment 25 the application of font color without background
color for button/submit is still an issue (that i'd prefer to see resolved by
the drop of foreground color as we seem to be doing already in the case of the
select)

as long as other people are seeing what I'm seeing I'd suggest resolving this
bug WFM, marking bug 198822 new and addressing buttons there, and opening a 3rd
bug for the textarea/scroll bar issue if there isn't one already out there.

Comment 27

[Greg K.]

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

Comment 28

[Greg K.]

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

Comment 29

[Chris Casciano]

can ayone out there confirm / deny my report in comment 26 in that the original
bug filed here (with text areas) is now resolved (WFM) in Camino nightlies due
to background color being picked up? I'm seeing it with the 3.27 build also so
its not a fluke. It would be nice to close this out and stick to bug 198822 for
the aqua button issues.

Comment 30

[Chris Blackstone]

with the 4-2 Nightly, this now WFM. Yeah!

Comment 31

[Chris Casciano]

great... marking WFM... this should only be reopened if theres still a problem
with textarea bg colors... other form elements should be filed separately (as in
bug 198822)

Comment 32

[Greg K.]

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