94387 - WRMB:juno.com - form select pulldown has not outline / shadow

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[Dave Barrowman]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726
Netscape6/6.1
BuildID:    20010727

The pulldown on the top right ("Explore by Category") of http://www.juno.com is
missing it's outline / shadow in Gecko based browsers.  The outline appears in IE.

I believe this is CSS related.

Reproducible: Always
Steps to Reproduce:
1. visit http://www.juno.com
2. look at the pulldown


Actual Results:  Pulldown appears with no shadow / outline.

Expected Results:  Expected to see an outline around the pulldown.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The stylesheet says:

SELECT {
  font-family: verdana, arial, helvetica, sans-serif;
  color: #000000;
  font-size: 11px;
  border: 0px;
}

Which naturally turns off the border (which normally looks like an outline).

Looks like IE does not support setting borders on select elements... over to
evang; this is not a mozilla bug.

Comment 2

[Madhur Bhatia]

This is not a netscape specific bug. Their style sheet needs to be corrected.

According to http://www.w3.org/TR/REC-CSS1#border ---
Value: <border-width> || <border-style> || <color> 
Initial: not defined for shorthand properties
Applies to: all elements
Inherited: no
Percentage values: N/A

and  http://www.w3.org/TR/REC-CSS1#border-width ---
Value: [thin | medium | thick | <length>]{1,4}
Initial: not defined for shorthand properties
Applies to: all elements
Inherited: no
Percentage values: N/A

part of the style sheet used for this site reads as -

TD, TABLE, SELECT {
	font-family: verdana, arial, helvetica, sans-serif;
	color: #000000;
	font-size: 11px;
        border: 0px;
}

the value assigned to property 'border' is not accurate. If I change the 
property-value to 'border-width: 1px', I get the desired outline around the 
select box.

Not an HTML form control bug --- probably should be assigned to evangelism.

Comment 3

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.

Comment 4

[jag (Peter Annema)]

Heh. Could be no evang is needed and they really don't want the border. Unless
we can evang MS to fix IE ;-)

Comment 5

[Bob Clary [:bc] (inactive)]

please don't change the leading part of the summary to include war room meta
bug. If you wish to mark as WRMB use the status whiteboard

Comment 6

[Bob Clary [:bc] (inactive)]

removing topembed. if you wish to have a product fix motivated, then reassign
this bug to a browser component.

Comment 7

[rubydoo123]

getting this reassigned to an engineer

Comment 8

[rubydoo123]

assigning to proper engineer, adding WRMB to summary, please refer to bugscape 
bug 5908 for more detail/history of this issue

Comment 9

[jag (Peter Annema)]

Last I read this is a bug in their stylesheet, not in our code. cc'ing some
people to see if we're actually doing the right thing here by not displaying
borders around form controls when the CSS tells us not to.

Comment 10

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

The CSS spec doesn't give a model for the display of form controls, so any
application of CSS to form controls is our extension of CSS.  The spec doesn't
define, for example, whether the 'border' property should be describing
something that's an additional border outside a native-looking control (as I
suspect it is in IE), the outer border of that native control (which is what we
do, since our form controls are constructed using box types that do exist in the
CSS model without any cutting off of style), a border around the selected item
inside that native control, the border around the drop-down, the border around
the selected item within the dropdown, or anything else.  That's why I've been
against allowing CSS to style form controls unless the spec defines what CSS
should mean or unless we come up with a really coherent model (such as XBL-based
form controls where authors can opt-in to a styleable version).

Comment 11

[rods (gone)]

Should just put !important on it?

Comment 12

[rods (gone)]

Attachment: proposed patch

Comment 13

[rods (gone)]

Let's put in !important for now and fix the entire stylable of form controls 
thing later.

Comment 14

[Kevin McCluskey (gone)]

Comment on attachment 51586 [details] [diff] [review]
proposed patch

r=[e-mail]

Comment 15

[Marc Attinasi]

Comment on attachment 51586 [details] [diff] [review]
proposed patch

sr=attinasi

Comment 16

[Kevin McCluskey (gone)]

Rod can you check it in the trunk?
Putting topembed keyword on. Updated status. 

Comment 17

[rubydoo123]

adding bugscape ref

Comment 18

[rods (gone)]

fixed

Comment 19

[Simon Fraser [no longer active]]

>Let's put in !important for now and fix the entire stylable of form controls 
>thing later.

What's the bug for this?
Note that form controls should be styleable via userContent.css, and this change
braeks that.

Comment 20

[Madhur Bhatia]

hmmm..... http://www.juno.com have made changes to their page. There is 
no pulldown on the top right ("Explore by Category") anymore.

Comment 21

[Madhur Bhatia]

verified www.juno.com page has changed. bug is now invalid.