[css-align][css-overflow] Specify treatment of border-box padding for text input elements

[boazsender]

@alijuma, @Hexcles and I are working to squash an old compatibility issue over on whatwg/compat#81 where firefox clips input text and chrome, safari and edge don't.

Section 3.1 of css-ui comes close to specifying this behavior but does not (thanks for pointing that out @alijuma): https://drafts.csswg.org/css-ui-3/#valdef-box-sizing-border-box

What do we think of adding language to this section to specify border-box text/padding interaction. Per our conversation on the other issue, I would suggest that the correct behavior is not to clip the text when the input height minus the input padding minus the input border is smaller than the height of the text. In other words, when the padding is too large, ignore it, or paint it behind the text.

Here's what the compat issue looks like:

CC @dbaron, @bzbarsky, @tabatkins, @frivoal

[bzbarsky]

The basic question is what the scrollable area is here. Is the padding inside the scrollable area, or outside?

The actual behavior of at least Chrome is rather inconsistent here. For example, horizontal padding is not included in the scrollable area, but vertical padding is. In particular, the "chrome paints text over padding, and firefox paints padding over text" summary in whatwg/compat#81 is wrong as a blanket statement. See https://bugzilla.mozilla.org/show_bug.cgi?id=752790#c7

[frivoal]

I don't think this has much to do with css-ui or box-sizing: border-box, since there is no actual interop problem in terms of sizing, with all browsers giving the same sizes to the content/padding/border areas for both the <input> and the <div>.

This is either an overflow and/or an alignment problem. Retriaging accordingly.

[frivoal]

with all browsers giving the same sizes to the content/padding/border areas for both the <input> and the <div>.

Btw, this can be observed (at least) using dev tools.

[bzbarsky]

with all browsers giving the same sizes to the content/padding/border areas

That's unclear. The "padding" that browsers claim in their devtools doesn't actually behave like padding is defined to in CSS.

[boazsender]

Thanks for pointing me to css-overflow @frivoal. I'm submitting a ref test in css/css-overflow-3 to WPT per this issue that tests for the behavior of safari/chrome/edge (preserving text vertically).

I'm still not sure what the relevant spec change is and am looking for help on that.

[yachiehwu-zz]

#1941 might be a duplicate of this.
I have done some browsers test and summarized the browser behaviors on #1941.
A quick say is that there are three different behaviors among Firefox, Chrome, Safari, Edge, in the vertical direction.
I also bring up a proposal to try to find a solution for this on #1941.

[karlcow]

@frivoal @boazsender It doesn't seem to be an issue with overflow either. Changing the overflow value doesn't change the behavior of the text in Chrome and Safari for this specific case. @yachiehwu documented this clearly in #1941 and in https://bugzilla.mozilla.org/show_bug.cgi?id=752790#c29

[boazsender]

I'm closing this in favor of #1941 which lays out a more cogent proposal for a spec change.