Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

<select> font inconsistency in Firefox/Opera #143

Closed
iamkeir opened this Issue Dec 4, 2012 · 17 comments

Comments

Projects
None yet
6 participants

iamkeir commented Dec 4, 2012

Test case: http://jsfiddle.net/AXn93/

In Opera/Firefox (haven't tested IE), the font size is rendered several sizes larger than Chrome/Safari.

I'm linking to the latest normalize.css in the jsFiddle resources section:
http://necolas.github.com/normalize.css/2.0.1/normalize.css

I think it is being caused by the combination of the following:

html {
    font-family: sans-serif; /* 1 */
    -webkit-text-size-adjust: 100%; /* 2 */
    -ms-text-size-adjust: 100%; /* 2 */
}

button,
input,
select,
textarea {
    font-family: inherit; /* 1 */
    font-size: 100%; /* 2 */
    margin: 0; /* 3 */
}

Not exactly sure why though?

OS X 10.8.2
Chrome Version 23.0.1271.95
Safari Version 6.0.2 (8536.26.17)
Firefox Version 17.0.1
Opera Version 12.11

iamkeir commented Dec 4, 2012

Updated test case isolating that styling: http://jsfiddle.net/AXn93/1/

iamkeir commented Dec 4, 2012

Losing font-family: inherit; and font-size: 100%; seems to remedy the problem:
http://jsfiddle.net/AXn93/2/

However, I'm sure they were originally put in for other purposes so I don't see this as a fix yet.

iamkeir commented Dec 16, 2012

Has anyone else encountered this? Possible to fix?

iamkeir commented Dec 28, 2012

Apparently an issue on OSX only - could anyone try it on Windows/Linux?

iamkeir commented Feb 12, 2013

Anybody? :/

Tested on Chrome 24 and Firefox 18 on Windows 7, can´t test in Opera...
http://i.imgur.com/dpS36hR.png

iamkeir commented Feb 12, 2013

I'll do another cross-browser test and post screenshots too, thanks @hachesilva

iamkeir commented Feb 12, 2013

Here you go:

Seems like Chrome and Safari on OSX are the naughty ones...?

Can't do IE 7/8 as my XP virtual machine is being emotional...

Seems like potentially an OS default font size and interface difference to me.

Using http://jsfiddle.net/AXn93/1/ ->
boing

[Disclaimer: I do not run ie6, or ie7 or ie8, or windows. I just use browserstack.com for testing so I don't have to.]

iamkeir commented May 21, 2013

Here's the explanation of the issue we've been having with dropdowns - all down to WebKit buffoonery: "This is a fun one. In WebKit, if the font-size is between 0 and 10px, it will render the font size as 10px. From 11px to 15px, it will render as 11px, and 16px or larger it will render it as (wait for it), 14px. This behavior is similar they handle search inputs. Firefox, Opera, and IE will respect your change but again only if explicitly declared on the select, it will not cascade." http://css-tricks.com/dropdown-default-styling/

@ghost

ghost commented Jun 27, 2013

Tested on Chromium and Firefox for Ubuntu, don't see a difference that can be a problem:
Firefox 22:
firefox font

Chromium 25:
ubntu chromium font

iamkeir commented Jun 27, 2013

I did come up with a fix for this - I'll dig it out and post here.

running into this as well.

webkit annoyingly only lets <select> elements have a font-size of either 9px, 11px or 13px. And it's not even as simple as setting font-size: 13px and being done with it, because explicitly setting:

select {
  font-size: 13px;
}

results in:

font-size: 13px;

from what i can tell:

  • > 15px results in font-size: 13px
  • 15px - 11px results in font-size: 11px
  • < 11px results in font-size: 9px

maybe normalize should just set:

select {
  font-size: 16px;
}
Contributor

jonathantneal commented Nov 11, 2013

Normalizing <select> is very difficult.

As far as I know:

  • IE does not apply optgroup styles. Its label will always be bold and italic.
  • Firefox does not correctly apply font-size on <select>.
  • Chrome does not apply any optgroup / option styling.

Therefore:

  • Optgroup can be somewhat normalized between IE, Firefox, and Chrome by following Chrome styling.

For example:

http://jsbin.com/aWExUri/1/edit

select {
    font: 400 75%/normal "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Geneva, Verdana, sans-serif;
    min-height: 1.625em;
    padding-top: 0.125em;
}

optgroup:before, option {
    background-color: #FFF;
    font-size: 95%;
    font-style: normal;
    font-weight: 400;
    padding: 0.075em;
    padding-left: 0.625em;
}

optgroup {
    color: #888;
}

optgroup:before {
    content: attr(label);
    font-weight: 400;
    font-style: normal;
}

optgroup option {
    padding-left: 1.875em;
}

option:checked, option:hover {
    background-image: linear-gradient(#648cf5, #2765f2);
}

option {
    color: #333;
}
Owner

necolas commented Nov 11, 2013

WebKit on OS X currently doesn't allow you much control over font-size for select. All browsers are limited and different in what they do. Not much that can be done about that from this end, so I have to close this as 'wont/impossibleto'-fix :)

@necolas necolas closed this Nov 11, 2013

Contributor

jonathantneal commented Nov 11, 2013

@necolas, how do you feel about normalizing pieces of <select> / <optgroup> / <option> so that Firefox and IE conform to Chrome?

If a spec hasn't already outlined the default appearance of a menulist, then normalizing the appearance between browsers (to the best of their abilities) would seem appropriate.

Owner

necolas commented Nov 11, 2013

Not sure there's much value to it (related #102)

Form styles are fairly browser/OS-specific and people using those browsers aren't concerned about whether the form UI they are used to seeing is the same or different from another browser/OS combo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment