479251 - <select> menu items don't honor styles

Status: RESOLVED WONTFIX

(Camino Graveyard :: HTML Form Controls, defect)

Description

[camino-bugs]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.8pre) Gecko/2009021900 Camino/2.0b2pre (like Firefox/3.0.8pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.8pre) Gecko/2009021900 Camino/2.0b2pre (like Firefox/3.0.8pre)

Specifying font-size with style or CSS for SELECT element is not honored as it is in Firefox, Safari and Opera. 

Reproducible: Always

Steps to Reproduce:
Create select tag with options on any form and try to change the font-size in select statement. (XHTML document type)

Actual Results:  
one default font-size - the element is not changing font nor adjusting its size.

Expected Results:  
honoring the styled font-size - and the drop-down list adjusting with the font-size.

Comment 1

[Stuart Morgan]

Please attach a minimal testcase to this bug. I'm assuming you mean font size on the <option> elements, but without a test case it's not entirely clear.

Comment 2

[camino-bugs]

To be more specific; a simple <select> - tag with <option> items does not honor the style sheet font size / font family. Once opened - the drop down list opens up as it should in 'Mac style', but the font on the drop down selection list is presumably 'Lucida Grande' with a one specific font size always. The opened drop down list element should follow the font size / family described in style document or style 'attribute' and adjust its size closer to the width of the closed drop-down element. 

To reproduce: (rough example)

<select name="test" style="font-family:'MS Trebuchet'; font-size: 10px ">
<option value='on'>This is on</option>
<option value='off'>This is off</option>
</select>

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think this is probably WONTFIX.

Safari will snap down to mini-sized NSPopUpButtons, or snap up to full-sized ones (you have 3 sizes).

Firefox will scale to any arbitrary size.

By default, we don't scale/snap, but if you disable the Aqua select pref, we'll scale arbitrarily, just like Firefox.

Unless there's something we can tweak in that CSS, we either have the choice of having garish <select>s that will scale to an arbitrary size, or Aqua <select>s that always use the small size.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Well, we can change 

 font: -moz-list !important;

to

 font: -moz-list;

and get scaling (author font size) and author font-face back.

I'm not sure how badly that will degrade things with crazy author styles, though.  I've looked at the testcases in bug 394063 and they mostly look OK to me, and I think this behavior approximates what we used to have in Camino < 2.

Comment 5

[camino-bugs]

How about the Safarish approach with 3 sizes? Could that be an alternative?


(In reply to comment #4)
> Well, we can change 
> 
>  font: -moz-list !important;
> 
> to
> 
>  font: -moz-list;
> 
> and get scaling (author font size) and author font-face back.
> 
> I'm not sure how badly that will degrade things with crazy author styles,
> though.  I've looked at the testcases in bug 394063 and they mostly look OK to
> me, and I think this behavior approximates what we used to have in Camino < 2.

Comment 6

[Stuart Morgan]

The pref and our style sheet don't actually matter here, because this is about the menu itself. I thought we had a catch-all for this, but it looks like we don't, so I'm turning this into one.

Some things could be supported in a native menu, some things not so much, but we can leave this open as a general policy to consider in the future.

For 2.0, our <select> handling isn't going to change given the options available to us in Gecko 1.9.0.

Comment 7

[Stuart Morgan]

Attachment: testcase from comment 2

Firefox respects font and size in both the element and the menu.
Safari ignores font but semi-respects size (and Smokey describes above) in both the element and the menu.
We ignore both with the default pref, and ignore both in the menu no matter what (and making the pref control the menu isn't within the realm of plausibility for the short/medium term).

Comment 8

[philippe (part-time)]

(In reply to comment #4)
> Well, we can change 
> 
>  font: -moz-list !important;
> 
> to
> 
>  font: -moz-list;
> 
> and get scaling (author font size) and author font-face back.

In that case, remove the rule completely out of aquaSelect.css.

Note that Safari doesn't allow an author to set a font-family for drop downs. You always get Lucida Grande.

(Nothing more ugly than an Aqua select with font-family: Times New Roman - seen recently in the stylesheet on a phpBB forum. But that is just me.)
 
> I'm not sure how badly that will degrade things with crazy author styles,
> though.  I've looked at the testcases in bug 394063 and they mostly look OK to
> me, and I think this behavior approximates what we used to have in Camino < 2.

Widget will work reasonably well. Technically.

To get closer to what Safari/WebKit does; we could lock down the font-family, but leaving the font-sizing up to the author.
Replace the rule
> font: -moz-list !important;
with
font-family: 'Lucida Grande' !important;
font-size: 11px;

(untested, but I use a similar set for other form controls in my user stylesheet :-)
Font-fallback for CJK, Cyrillic, South-Asian, Arabic, etc will still work correctly.

Comment 9

[philippe (part-time)]

(In reply to comment #8)

> font-family: 'Lucida Grande' !important;
> font-size: 11px;

Note that this would also open the door for author-set 'font-variant', 'font-style' and 'font-weight'. Those properties are part of the font shorthand notation.

Safari allows all those font-* properties to work only if/when the author also sets a border and/or background

Comment 10

[camino-bugs]

Maybe we should not try to protect users from seeing ugly designs or authors from creating them. We should try to make the Camino to follow the authors wish as far as the standards and the current framework will allow, I am sure you all agree on that. If the page design and the author requests smaller font for the option items then the browser should follow that request. Having said that, and keeping in mind the 'Mac look and feel' , the webkit/Safari approach gets my vote hands down. Keeping the 'Lucida Grande' and allowing the font-size and the actual option element to adjust to the font size changes.

Comment 11

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]