This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html Multipage: http://www.whatwg.org/C#the-input-element-as-a-text-entry-widget Complete: http://www.whatwg.org/c#the-input-element-as-a-text-entry-widget Referrer: Comment: Treating text inputs as just an inline-block doesn't handle overflow correctly Posted from: 98.110.194.132 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:29.0) Gecko/20100101 Firefox/29.0
Testcase: <input style="overflow: visible; height: 0.5em" value="This is some text and it is both too tall and too long"> Per spec as currently written, there should be text overflowing the input. No UA I know of does that, and sites depend on that not happening. Furthermore, if we posit that these are inline-blocks with overflow set to hidden, then you're disallowing baseline-aligning the input, which is also suboptimal...
What should the spec say then?
I don't know. Basically, the CSS spec sucks here: if you make them replaced elements you can't give them a sane baseline per the spec, but if you make them non-replaced you get the issues I described. What Gecko does is make them replaced elements with sane baseline (i.e. baseline not at the bottom margin edge but rather on the baseline of the text in the input)....
Tab, any chance CSS can give us some better hooks here? On the long run we presumably want to define all this in terms of CSS being applied to actual nodes in a shadow tree of some sort.
Actually... that's very difficult. For example, padding specified on the input is expected to go inside the scrollable area (e.g. see https://bugzilla.mozilla.org/show_bug.cgi?id=157846 ). But the scrollable area is expected to be scrollable somewhat independently of the overflow styles on the node. And in particular, overflow:visible and overflow:scroll are both treated as "hidden" for inputs (but not for textareas!), except that the computed style says whatever the specified style is...
Well as I see it, here are our options, in decreasing order of idealness, but probably increasing order of readiness: - Wait for CSS and Web Components to be evolved enough that we can use a combination of those to describe this. - Wait for CSS to have hooks available such that we can define this as a magical binding, which couldn't actually be implemented by authors. - Monkeypatch CSS directly from HTML to define this as a magical binding that couldn't actually be implemented by authors. In any case, to do this we probably need a more firm description of what you want the spec to actually require (i.e. what is needed for Web compat?).
https://github.com/whatwg/html/issues/4082