input text rendering with padding incompatible between FireFox and Chrome

[boazsender]

What do we think about using the compat spec to resolve this five year old input bug where chrome paints text over padding, and firefox paints padding over text?: https://bugzilla.mozilla.org/show_bug.cgi?id=752790

For example, see

Reproduce this with the following CSS:

input {
  height: 50px;  
  padding: 18px;
}

[Hexcles]

Here is a demo on the different behaviours of the box model in divs and inputs. In the demo we have one input and one div, both observing the border-box model with text height exceeding the visible area. https://codepen.io/anon/pen/vJZWgj

Firefox:

Chrome:

Both browsers render the text in front of the padding in div. But in input, Firefox puts text behind padding, while Chrome draws the text in front of padding.

[alijuma]

Behavior for this is almost specified in CSS Basic User Interface Module Level 3, in Section 3.1, for the input element's box model (border-box): https://drafts.csswg.org/css-ui-3/#valdef-box-sizing-border-box

[boazsender]

I believe that chrome's behavior is the correct behavior here in the above example. We should specify chrome's behavior.

[alijuma]

Edge 15 matches Chrome's behavior:

[dbaron]

It's not clear to me how the bits of spec are particularly relevant here -- but isn't one of the key questions what @bzbarsky raises in bug 752790 comment 7:

Chrome and Safari will allow painting into the vertical padding but not the horizontal padding of the input, which isn't exactly expressible with CSS normally. :(

[denschub]

I agree that this isn't expressible by CSS, but I fear this is one of the issues that is out of question. Given we agree on that our current behavior is right and Chrome is wrong, we would break all sites that are currently depending on this. Note that this is affecting Google, vimeo, eBay, yahoo, wikipedia, twitter and many, many more.

So, whatever we do, we have to do something to make sure inputs don't look broken/cut off in this case.

[bzbarsky]

If we're just talking about implementation in Gecko, there are ways to make this work. For example, we could have the scrollable area inside the input inherit the vertical padding and force the used vertical padding on the input itself to 0, but do nothing to the horizontal padding.

The question is what the spec is supposed to say here, given that it doesn't really have a concept of a scrollable thing separate from the input itself, but that's somewhat orthogonal to what we do in Gecko, where we do have such a distinction.

[boazsender]

@dbaron and @bzbarsky you were both right. That box-sizing wasn't the right spec, and gecko seems to get this behavior more "correct".

@frivoal kindly pointed me to the css-overflow spec as an anchor, and I'm about to open a PR on WPT for a ref test that tests for the behavior of chrome/safari/edge. I think that the number of compat issues this raises makes that seem like the way to go. But, I might be wrong here.

Also, this test might still not be in the right place. It assumes that the relevant spec change will be to css-overflow. That's the real work here, as you pointed out @bzbarsky. I'm not sure what that should look like, and will look for some guidance to make that happen.

[dbaron]

An issue calling for a spec change is w3c/csswg-drafts#1941.

[boazsender]

@alijuma and @Hexcles, I closed our spec bug w3c/csswg-drafts/issues/1717 in favor of w3c/csswg-drafts/issues/1941 which had a more cogent proposal.

@jetvillegas pointed out over on that issue that the 6 year old FF bugzilla bug #752790 that we started with for this is getting worked on as of 4 days ago.

I've also updated our test case from using a div for the reference to use an input in order to avoid a tiny rendering difference of text between divs and inputs. It's still waiting review at w3c/web-platform-tests/pull/8080

[Hexcles]

Sorry haven't been following this as closely as I wish. Thanks for the follow-up, @boazsender ! Also glad to see a long-standing issue being taken care of.