24296 2014-01-15 02:20:54 +0000 Treating text inputs as just an inline-block doesn't handle overflow correctly 2019-03-29 20:26:00 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED MOVED http://www.whatwg.org/specs/web-apps/current-work/#the-input-element-as-a-text-entry-widget blocked on getting a form control styling solution P3 normal Unsorted 1 contributor ian bzbarsky d ian jackalmage mike w3bugs contributor oldest_to_newest 98470 0 contributor 2014-01-15 02:20:54 +0000 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 98471 1 bzbarsky 2014-01-15 02:25:22 +0000 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... 98530 2 ian 2014-01-15 22:26:41 +0000 What should the spec say then? 98785 3 bzbarsky 2014-01-20 19:24:16 +0000 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).... 98839 4 ian 2014-01-21 21:33:09 +0000 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. 98846 5 bzbarsky 2014-01-21 21:39:56 +0000 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... 99508 6 ian 2014-01-30 22:50:37 +0000 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?). 129675 7 d 2019-03-29 20:26:00 +0000 https://github.com/whatwg/html/issues/4082