Closed Bug 171186 Opened 22 years ago Closed 22 years ago

New XP based Form controls draws incorrectly when CSS styled

Categories

(Core :: Layout: Form Controls, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: robmv, Assigned: john)

Details

Attachments

(3 files)

I'm using the 2002092704 nightly.
I am using this stylesheet in a page with forms inside

select:focus {
  background-color: #EEFFFF;
}
input:focus {
  background-color: #EEFFFF;
}
textarea:focus {
  background-color: #EEFFFF;
}

The new XP Theme based form controls draws perfectly, with the exception in
focused components (They revert to the old control look and the xp look is
restored when the component lost focus) The select control does not expose this
behaviour, it is drawn with the xp look and correct background color.

I'm attaching an screenshot
Attached image Sample screenshot
Notice the error in the alignment of the select element

This select element is has the following html code

<input type="text" name="p.day.date" size="2" maxlength="2"/>/<select
name="p.month.date"><option value="1">Enero</option><option
value="2">Febrero</option><option value="3">Marzo</option><option
value="4">Abril</option><option value="5">Mayo</option><option
value="6">Junio</option><option value="7">Julio</option><option
value="8">Agosto</option><option value="9">Septiembre</option><option
value="10">Octubre</option><option value="11">Noviembre</option><option
value="12">Diciembre</option></select>/<input type="text" name="p.year.date"
size="4" maxlength="4"/>
Is this what's causing bug 171214 (mis-aligned submit buttons)?  (If so, it
should be marked a duplicate.)
I'll answer my own question and say "No".
Mind posting your testcase here?
Attached file Testcase HTML file
Extracted testcase from the page that are shown in the screeshots
This is a bug in IE.  If you'll notice, IE does the same thing when you specify
such a style on an input *normally* (i.e. without focus and such).  IE totally
ignores the input:focus { background-color: #EEFFFF; } rule, and that's why
you're not seeing this there.

Bottom line, if you customize CSS that affects the painting we have to turn off
the theme.  Alternatives for your case:
(a) use <meta http-equiv="msthemecompatible" content="no"> in the <head>, which
turns off XP Theming altogether in both IE and win
(b) don't use a background-color on focus
(c) use a background-color when focus is not true, which turns of theming
altogether for those controls in both IE and win
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
I don't think this is an invalid bug, The SELECT element when focused shows the
light blue background color without reverting to the non xp theme control. Why
can't the other form element do the same thing?

I removed the :focus part of the CSS and you are right, Mozilla do the same that
IE. but i think that it is a BUG in IE that Mozilla must not replicate. Any
control with a background must be shown like the SELECT element, XP look with
the CSS indicated background or make the SELECT element do the same that INPUT
one does. Why the difference? because IE do that, IE is not the W3C standard

---- Must I reopen this bug?
If you'll notice, IE switches out of XP Themes too when you change background
color with CSS--try it with a regular rule.  It is simply ignoring your focus rule.
Yes, I noticed that, but my question is why must we do what IE says? and INPUT
element with a background-color property only must not change the entire look of
the control, take a look at the second attachment: it shows a SELECT element (a
dropdown list) with XP look and blue background, with INPUT elements it can show
a TextField with blue background. I think that this can be done because the only
CSS property customized is background-color.

If IE instead of changing the look af the control, changes the type of the
control for example a radio button for a text field, must Mozilla replicate that
bug?, I think that that is not correct
adding to my previous comments. If other properties are changed, like border, it
is reasonable to change the control look, but not with only a background color
change
This is done so that we *can* paint the background.  This is *themed* stuff, you
can totally change the look and feel of a windows control and there is no way we
can control the theme.  Thus it makes sense that when you use relevant CSS you
leave "themed mode" altogether.  You're not using one part of the user's theme,
why should you use any other?

For example, what if you tested your site on Windows NT and specified a blue
background color; it would be black-border / blue-background on NT, the way you
intended it.  Then on XP it doesn't look like that, it's blue-on-blue because
the user's default theme has a blue border.

In short: if the page is using CSS it is trying to customize look and feel.  In
that case we should not use the user's theme at all.

Regardless, if you want *your site* in particular to work cross-browser /
cross-platform you should use the methods outlined above.
Ok... I understand what you exposed here Jhon. but what about the SELECT
element? if it has a CSS background-color property, the blue-on-blue problem can
happen, because it remains with the XP look. Sorry but i think that you must see
the second attachment again. :-P.

Now the problem is another: the SELECT element does not change to the
cross-platform look when is custom styled
WinIE does not turn off the WinXP look for SELECTs even when you change the
background.  We match that behavior. SELECTs differ from textfields and buttons
in that (a) you can't style the border (just like WinIE) and (b) you can't turn
off the WinXP look when you specify a background (just like WinIE).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: