Closed Bug 1481112 Opened 5 years ago Closed 4 years ago

User Agent Stylesheet Default for select, button


(Core :: Layout: Form Controls, enhancement)

63 Branch
Not set



Webcompat Priority P2
Tracking Status
firefox63 --- wontfix
firefox70 --- fixed


(Reporter: karlcow, Assigned: emilio)


(Whiteboard: [webcompat])


(2 files)

This is a spin off of

Chromium user agent stylesheet

input, textarea, select, button {
    text-rendering: auto;
    color: initial;
    letter-spacing: normal;
    word-spacing: normal;
    text-transform: none;
    text-indent: 0px;
    text-shadow: none;
    display: inline-block;
    text-align: start;
    margin: 0em;
    font: 400 13.3333px Arial;


In this codepen I have done instead:

.spacing {
    text-rendering: optimizespeed;
    color: red;
    letter-spacing: -.2em;
    word-spacing: 10em;
    text-transform: capitalize;
    text-indent: 50px;
    text-shadow: 2px 2px;
    display: inline-block;
    text-align: right;
    margin: 2em;
    font: 400 13.3333px Arial;

This is the rendering in Firefox.

[![Screenshot Description](](

and the rendering in Chrome.

[![Screenshot Description](](

For certain values, Chrome seems to ignore the parameters.

Let's see where the values are applied

in button and select only

* text-rendering: firefox
* color: none
* letter-spacing: firefox 
* word-spacing: firefox
* text-transform: firefox
* text-indent: none
* text-shadow: none
* display: none
* text-align: none
* margin: both

Some of the values are changing in Firefox. 

This needs a better assessment and to double check the initial values in between Chrome on Desktop AND mobile. Here I only assessed desktop.
Flags: webcompat?
Priority: -- → P3

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Karl, how do we make this bug actionable? Is the idea to align with Chrome in the default UA style? Or something else? Thanks

Flags: needinfo?(kdubost)
Attached image firefox, safari, chrome

ok let's see. Restarting from the testcase.

from left to right

  • Firefox 70.0a1 (2019-07-30) (64-bit)
  • Safari Release 88 (Safari 13.0, WebKit 14608.1.36)
  • Chrome Version 78.0.3869.0 (Build officiel) canary (64 bits)
<div class="thirtyone" style="font-size: 30px;letter-spacing: -.31em;">
  <option value="">badaboom</option>

or data:text/html,<div class="thirtyone" style="font-size: 30px;letter-spacing: -.31em;"><select><option value="">badaboom</option></select></div>

I will add a testcase.

If I select option in devtools, I get computed values:

  • Firefox: letter-spacing: -9.3px
  • Safari: letter-spacing: normal
  • Chrome: letter-spacing: normal

In Chrome, this is coming from the user-agent stylesheet on select. Note that positive letter-spacing (aka wide space) has no effect also on the button text. It still stays normal.

select {
    -webkit-writing-mode: horizontal-tb !important;
    text-rendering: auto;
    color: black;
    letter-spacing: normal;
    word-spacing: normal;
    text-transform: none;
    text-indent: 0px;
    text-shadow: none;
    text-align: start;
    white-space: pre;
    -webkit-rtl-ordering: logical;
    cursor: default;
    font: 400 11px system-ui;

In Safari, defined in the same way and positive number has no effect.

input, textarea, keygen, select, button {
margin-top: 0em;
font-style: normal;
font-weight: 400;
font-size: 11px;
font-family: system-ui;
font-variant-caps: normal;
color: initial;
letter-spacing: normal;
word-spacing: normal;
line-height: normal;
text-transform: none;
text-indent: 0px;
text-shadow: none;
display: inline-block;
text-align: start;

Now if I set letter-spacing directly on the select element, for example 10em

  • Firefox: applied
  • Safari: applied
  • Chrome: says in devtools that it applied a computed value, but visually did nothing.

so it's complicated,

but maybe the logical expectation would be at least that we set select in the UA stylesheet with letter-spacing: normal.

Then we would need to decide if changing the value in a personal CSS has effects or not. Maybe something for the CSS working group.

select {

    margin: 0;
    border-color: ThreeDLightShadow;
    background-color: -moz-Combobox;
    color: -moz-ComboboxText;
    font: -moz-list;
        line-height: normal;
    line-height: initial;
    white-space: nowrap !important;
    word-wrap: normal !important;
    text-align: start;
    cursor: default;
    box-sizing: border-box;
    user-select: none;
    -moz-appearance: menulist;
    border-width: 2px;
    border-style: inset;
    text-indent: 0;
    overflow: -moz-hidden-unscrollable;
    text-shadow: none;
    display: inline-block;
    page-break-inside: avoid;
    overflow-clip-box: padding-box !important;

Flags: needinfo?(kdubost) → needinfo?(miket)

Thanks Karl. Resetting the priority so Sean can re-triage.

Flags: needinfo?(miket)
Priority: P3 → --

Emilio: Do you have thoughts on this? I know you recently did some work in bug 1561794 for padding compat with <select>. Maybe we should decide if we want to align on these other properties.

Flags: needinfo?(emilio)

I don't have strong thoughts of this other than the current situation is pretty terrible. Blink behaves inconsistently across platforms and I don't think we'd want to just mimic that.

There are tons of properties that are only reset if the control is themed, but for any element with -webkit-appearance: {button, menulist}. The last part of that (the "any element" part) will go away with this crbug.

I also know that Blink has a sort of new form controls "refresh" project (, which looks like could change a bunch of this (unsure if for the better or for the worse).

Anyhow, for the current state of things, the stuff to look for is:

In general I think our existing behavior is not unreasonable (or not more unreasonable than Blink at least). We should consider aligning on some of the bits where there's no good reason to go one way or another, or our behavior is not useful to authors or not consistent:

But anyhow: The UA stylesheet is useful as a reference, but they also rely on other theming mechanisms that we would need to implement as well or something, and those are mostly insane (I'm looking at you, LayoutThemeMac).

I think it's useful to file individual bugs for interop issues that are actionable specially if it causes pain for developers or compat problems. But I don't think this bug as-is is particularly actionable, or at least the title is too generic.

The issue described in comment 0 is about letter-spacing inheriting through the <select>, etc. Seems like some mobile websites rely on the user-agent stylesheet to have letter-spacing: normal for some form controls.

That is a reasonably well-scoped, low-risk change. Having letter-spacing: normal in the UA sheet doesn't restrict authors either.

It's still a bit unclear to me whether this bug as filed was intended to be a "catch-all" thing or just about the issue in comment 0. If the former, we should totally do it. Note that we already do this for input and textarea.

Flags: needinfo?(emilio)

So for the first probably should do. Need to write a test if it comes back green.

As emilio said, it is a bit of a mess. There are many undocumented behaviors and interactions which are weird, but probably we could fix indeed the things which seems to create issues.

It is basically in the same vein than Bug 1435665

There should be no change in behavior for <input> and <textarea>. Tests need to
be written for <button> and <select>.

Tests are at

Pushed by
Be consistent on which properties we allow to inherit through for input, textarea, button and select, for compat with other UAs. r=mats
Webcompat Priority: ? → P2
Flags: webcompat?
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Assignee: nobody → emilio
QA Whiteboard: [qa-70b-p2]
You need to log in before you can comment on or make changes to this bug.