1000077 - Padding on <input type=number> affects spinner button pseudo elements

Status: RESOLVED INVALID

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

Description

[Ian Oliver]

Padding on <input type=number> applies to spinner button pseudo elements

This behaviour on inputs is different to Chrome/Blink, where padding (padding-right, for instance) is only applied to the left of the spinners, not to the right of them.

I'm not sure which behaviour is correct, but the inconsistency makes it difficult to accurately position things 'over' the input without overlapping the pseudo elements (see example URL). I'm assuming this could also mean inconsistencies when it comes to styling the pseudo element spinners themselves (if this becomes available).

Comment 1

[Boris Zbarsky [:bzbarsky]]

> I'm not sure which behaviour is correct

There is no spec for how number inputs should render, so both are correct.  So would be not showing a spinner at all, not showing a textbox at all and providing some other sort of number-selection UI, etc.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Ian Oliver from comment #0)
> This behaviour on inputs is different to Chrome/Blink, where padding
> (padding-right, for instance) is only applied to the left of the spinners,
> not to the right of them.

Are you sure?

Chrome and Firefox render your URL approximately the same, for me. (The main noticable difference is that the input is slightly taller in Firefox). I'll attach screenshots. Maybe Chrome has changed their behavior [or it varies cross-platform]? Or maybe I'm misunderstanding you.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: firefox nightly screenshot on linux

Here's a screenshot on Firefox Nightly (31.0a1 (2014-04-22)) on 64-bit Linux.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: chrome dev screenshot on linux

...and here's a screenshot in Chrome on the same machine (Version 36.0.1941.0 dev aura) (installed using a "google-chrome-unstable" .deb file from Google)

Comment 5

[Ian Oliver]

Attachment: Number input with padding on Chrome 35.0.1916.47 beta-m, Win 7, 64-Bit

Yep, I've checked and they render differently. This is Chrome 35.0.1916.47 beta-m, Win 7, 64-Bit. Sorry, I should have said that checking the radios applies different padding-right values to the input. The units (cm, mm etc.) are absolutely positioned over the top of the input.

Comment 6

[Ian Oliver]

Attachment: Firefox Aurora 30.0a2 (2014-04-22), Win 7, 64-Bit

This is the latest Aurora (as of yesterday).

Comment 7

[Daniel Holbert [:dholbert]]

Ah, sorry - I hadn't tried clicking the radio buttons.

I can reproduce your results with Chrome 34 -- they keep the spinner buttons right-aligned. But Chrome 36 matches Firefox; so it appears that they decided to change this behavior.

Per comment 1, this isn't defined in any spec, so there's no one "right answer"; however, given that Chrome dev version has switched to match Firefox on this, we probably shouldn't switch away to match their old version. :)

So this is probably INVALID (in the sense that there's no clear bug here, and no clear reason to change our behavior).

Comment 8

[Daniel Holbert [:dholbert]]

(And more importantly from your content's perspective: you probably don't want to build a layout that depends on the current Chrome version's behavior, if upcoming versions of Chrome are changing to break your assumptions.)

Comment 9

[Ian Oliver]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> I can reproduce your results with Chrome 34 -- they keep the spinner buttons
> right-aligned. But Chrome 36 matches Firefox; so it appears that they
> decided to change this behavior.
> 
> Per comment 1, this isn't defined in any spec, so there's no one "right
> answer"; however, given that Chrome dev version has switched to match
> Firefox on this, we probably shouldn't switch away to match their old
> version. :)
> 
> So this is probably INVALID (in the sense that there's no clear bug here,
> and no clear reason to change our behavior).

Right you are - I just looked in Chrome Canary 36 (should have done that before, *facepalm*) and it's the same behaviour as Firefox. They must've changed for Chrome 36, matching Firefox's behaviour.

As said, even though there is technically no right or wrong, I'm glad there's convention in the presentation, and now seemingly in the details.

Regarding the content, yeah, it's a pretty janky method, but the variables/magic numbers were pretty safe (at the time). Will definitely need some re-thinking now though!

Comment 10

[Daniel Holbert [:dholbert]]

Thanks, and good luck!

[Resolving INVALID per comment 7 through comment 9.]