1355521 - No longer able to hide type=number spinner UI with -moz-appearance: textfield;

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Mike Taylor [:miketaylr]]

STR)

1) in latest Nighty, visit https://accounts.firefox.com/signup

Expected: input[type=number] does not show number stepper thingers
Actual: It does

Apparently people have been using the following CSS as a pattern to remove the stepper UI from input type=number from Chrome/Safari and Firefox:

input.wt-numpad[type=number]::-webkit-inner-spin-button, 
input.wt-numpad[type=number]::-webkit-outer-spin-button { 
  margin: 0;
  -webkit-appearance: none;
          appearance: none;
}

input.wt-numpad[type=number] {
     -moz-appearance: textfield;
}

(codepen with the above: http://codepen.io/miketaylr/pen/MmgOLN)

So by making -moz-appearance chrome/UA only, we removed the ability to do this.

<https://github.com/search?p=1&q=-moz-appearance%3A+textfield%3B&ref=simplesearch&type=Code&utf8=%E2%9C%93>

(I checked Edge and they don't show the spinner UI ever).

So, possible ways forward:

1) make -moz-appearance not chrome/UA only, it lives on the web forever
2) implement ::-webkit-inner-spin-button, ::-webkit-outer-spin-button
3) ....invent something new and ask people to use that?

Comment 1

[Vlad Filippov (:vladikoff)]

> in latest Nighty

Just to add, this is in `55.0a1 (2017-04-11) (64-bit)`

Comment 2

[Mats Palmgren (inactive)]

> So by making -moz-appearance chrome/UA only, we removed the ability to do this.

We haven't done that yet (bug 1351745) - all three properties are enabled in v54/v55.
The testcase have no spinners in Nightly on Linux64.

On which platform(s) are you seeing this problem?

Comment 3

[Mike Taylor [:miketaylr]]

Ah, my bad -- I misread bug comments (and forgot I was cc'd on the right bug...)!

I'm seeing the spinners on Mac (originally reported to me by vladikoff who works on the FxA page).

Comment 4

[Mike Taylor [:miketaylr]]

(removing blocker until we have a better idea of what's up. I'll also run mozregression)

Comment 5

[Mike Taylor [:miketaylr]]

9:26.67 INFO: Oh noes, no (more) inbound revisions :(
 9:26.67 INFO: Last good revision: 8bb800ab23a51e39e17045be457c44f8b2612c62
 9:26.67 INFO: First bad revision: 675ff60e7653d448a0b59ce6375baaea2820c38e
 9:26.67 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8bb800ab23a51e39e17045be457c44f8b2612c62&tochange=675ff60e7653d448a0b59ce6375baaea2820c38e

 9:28.40 INFO: Looks like the following bug has the  changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

(ok, will re-add blocker...)

Comment 6

[Mats Palmgren (inactive)]

Thanks Mike, I can reproduce it in v54 on OSX.

It's definitely unexpected that OSX behaves differently here.  I'll look into it.

Comment 7

[Mats Palmgren (inactive)]

The CSS rule I see in devtools for the "age" form control in v54 on OSX is this:

.input-row input[type="number"], .input-row input[type="email"], .input-row input[type="password"], .input-row input[type="tel"], .input-row input[type="text"] {
        -webkit-appearance: none;
        -moz-appearance: textfield;
        background-color: #fff;
        border: 1px solid #8a9ba8;
        box-shadow: inset 0 1px 1px #f2f2f2;
        color: #424f59;
        outline: 0;
        position: relative;
        -webkit-transition-duration: 150ms;
        transition-duration: 150ms;
        -webkit-transition-property: border-color;
        transition-property: border-color;
        width: 100%;
        z-index: 2;
}

In v54/v55 "-webkit-appearance: none" trumps -moz-appearance.

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase

Here's a testcase with the above CSS rule.
When I try this in Chrome and Safari, the spin buttons are NOT disabled.
IOW, we are now compatible with those UAs, which I consider a good thing in general.

It's sad though that our spin buttons are so horribly ugly that authors
decide to *degrade* the UI by removing them.  I consider it user-hostile
to remove the spin buttons, because they provide a semantic cue to the user
that only numbers are allowed, as well as providing buttons to change
the value.

Comment 9

[Mike Taylor [:miketaylr]]

(In reply to Mats Palmgren (:mats) from comment #8)
> Created attachment 8857067 [details]
> Testcase
> 
> Here's a testcase with the above CSS rule.
> When I try this in Chrome and Safari, the spin buttons are NOT disabled.
> IOW, we are now compatible with those UAs, which I consider a good thing in
> general.

For that TC, yes, they also get served the following rule on the accounts page, to disable the spinner UI in webkit/blink:

.input-row input[type=number]::-webkit-inner-spin-button, .input-row input[type=number]::-webkit-outer-spin-button {
    -webkit-appearance: none;
    -moz-appearance: none;
    appearance: none;
    margin: 0;
}

Comment 10

[Mats Palmgren (inactive)]

Attachment: Testcase #2

> It's sad though that our spin buttons are so horribly ugly...

Sadly, it's not really any better in Safari / Chrome.
I tend to think we should stretch the spin buttons to
fill the height of the control, but other UAs don't
do that either so... :(

Comment 11

[Mats Palmgren (inactive)]

Mike, I don't see any regression here on our end.
"-moz-appearance: textfield" works the same as before, on all platforms.
The ::-webkit-inner/outer-spin-button CSS rules have never worked in Gecko.
For the signup page (see "Testcase"), the new behavior for the combo:

        -webkit-appearance: none;
        -moz-appearance: textfield;

makes Firefox compatible with other UAs. This is intentional.

It's good to know that authors are using the combo in comment 0 to remove
the spin buttons though.  We should take that into consideration before
disabling -moz-appearance.  I filed bug 1355574 about it.

Comment 12

[Mike Taylor [:miketaylr]]

Attachment: Fx 52 vs Fx 54 vs Chrome

Hmm, our behavior regressed here though (see screenshot).

Comment 13

[Mike Taylor [:miketaylr]]

Vlad, can you come up with a minimal test case showing the difference between 52 and 54+ here?

Comment 14

[Mats Palmgren (inactive)]

Yes, but the for the combo:

        -webkit-appearance: none;
        -moz-appearance: textfield;

that change in behavior is *intentional*, and it appears the signup
page is using that combo, per comment 7.

Comment 15

[Mike Taylor [:miketaylr]]

> "In v54/v55 "-webkit-appearance: none" trumps -moz-appearance."

OK, something to keep track of.

few depending on this trick(In reply to Mats Palmgren (:mats) from comment #11)
> Mike, I don't see any regression here on our end.
> "-moz-appearance: textfield" works the same as before, on all platforms.
> The ::-webkit-inner/outer-spin-button CSS rules have never worked in Gecko.
> For the signup page (see "Testcase"), the new behavior for the combo:
> 
>         -webkit-appearance: none;
>         -moz-appearance: textfield;
> 
> makes Firefox compatible with other UAs. This is intentional.

If Bug 1355574 is fixed, my concerns about this change in behavior disappear. Thanks for filing.

Comment 16

[Vlad Filippov (:vladikoff)]

Example: https://codepen.io/vladikoff/pen/mmbKVN 

52 hides the controls
54 shows them


I guess we can issue a fix to remove the `-webkit-appearance: none;` from our code.

Comment 17

[Mats Palmgren (inactive)]

Vlad, are you involved in the design of the pages on this site?
If so, I'd be interested to hear what the reasons are for removing
the spin buttons?
Is there anything we can do in Gecko to improve the appearance of these
buttons that would make you reconsider removing them?

Comment 18

[Vlad Filippov (:vladikoff)]

(In reply to Mats Palmgren (:mats) from comment #17)
> Is there anything we can do in Gecko to improve the appearance of these
> buttons that would make you reconsider removing them?


Probably not. This age field is a COPPA[0] field and users need to enter an age older than 12. 

To name a few reasons against the arrows (I'm sure our UX can come up with more reasons): 

1. We don't expect users to click the arrow up 13 times
2. We don't want negative values
3. We don't want the input field to look different in different browsers or look different from other inputs on the page.




[0] https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule

Comment 19

[Mats Palmgren (inactive)]

> This age field is a COPPA[0] field and users need to enter an age older than 12.

I fail to see why that has anything to do with disabling the spin buttons.

> 1. We don't expect users to click the arrow up 13 times

The field may have been pre-filled by the UA or an add-on, you can't know that.
Clicking up/down to change that value, for whatever reason, may make sense for
the user.

Granted, clicking up 13 times is unlikely, but the user may type in say 18
at first and then on second thought click down/up to adjust that value.

Also, as I said above, the spin buttons provide a semantic clue that this
control only accepts numbers, rather than say "twenty".  The spin buttons are
a recognizable trait that works across all sites.  It's good for the user if
form controls looks the same on all sites and in all applications on their
platform.

> 2. We don't want negative values

The way to do that is to add a min="0" attribute.
https://html.spec.whatwg.org/multipage/forms.html#attr-input-min

> We don't want the input field to look different in different browsers...

OK, that sounds like you would reconsider if our spin buttons looked
more like they do in other browsers.

> ... or look different from other inputs on the page

But that's actually a good thing for the user!

Comment 20

[Jiří Thiemel]

There are valid reasons for numeric inputs without any spinner arrows:

* Verification codes
* Credit card numbers

Yes you want numeric inputs there because of the keyboard on touch devices.

After you removed it you also broke a lot of UIs. It often led to removing the numeric inputs and forcing user to switch the keyboard manually on mobile. Or some other crazy hacks I can imagine.

Please reconsider this. I fully respect default browser behaviour and user's best interests and customs. But there are cases when the spinner arrows just only puzzle the user and make no sense and at the same time the content really is a number and numeric keyboard on touch devices is what actually helps the user.

Comment 21

[bugs]

Another use case: print.

The printed version should have clean numbers.
In my case there are also units after the numbers, and right now I get the spinner buttons in between the number and the unit symbol.

What I’m using is: (Firefox 76.0)

@media print {
    input[type="number"] {
        -webkit-appearance: none;
        -moz-appearance: textfield;
    }
    /* https://bugzilla.mozilla.org/show_bug.cgi?id=1355521 */
    input[type="number"]::-webkit-outer-spin-button,
    input[type="number"]::-webkit-inner-spin-button {
        -webkit-appearance: none;
        -moz-appearance: none;
        appearance: none;
        margin: 0;
    }
}