Re: box-sizing and text in value attribute of input element

On Tue, Nov 18, 2014 at 6:38 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> On 05 Nov 2014, at 21:43, Florian Rivoal <florian@rivoal.net> wrote:
>>> On 05 Nov 2014, at 18:26, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>>> On 11/5/14, 12:20 PM, Brad Kemper wrote:
>>>> Seems like some replaced elements (i.e., inputs, but not textareas) have an absolute minimum height of their content height
>>>
>>> That's clearly not true, unless you think this absolute minimum height
>>> mechanism somehow shrinks the used padding...
>>
>> It rather seems to me that the cotent area stays at 0 (and the padding stays unchanged), but that the replaced element overflows it, since it doesn’t fit at its minimum size (in non gecko browsers).
>>
>> That said, the overflow mechanism involved here does seem a bit unusual, since it doesn’t seem to respond to the overflow property.
>
> I’d be nice if we could reach some conclusion here.
>
> 1) Do we all agree that this has nothing to do with box-sizing after all, since it can be reproduced without using it

Yes, it's clearly not related to box-sizing.

> 2) Does it sound like my explanation or Brad’s hits close enough to the mark?

I think your explanation is kinda close to the mark, but not quite
right.  If it was just visibly overflowing, it should render with the
top of its linebox 20px down from the border.  Instead, it's centered
in Chrome.

I don't think Brad's is correct in its details, but right in that this
is probably a result of some incredibly hacky shadow-ish
implementation stuff.  The same is likely true of Firefox's, just with
a different result (unless they have overflow:hidden on the contents
of their <input> for some reason).

> 3) Does something need to be added to a spec (which?)

That's a harder question.  We need to figure out what behavior is
sane, and what we can converge on, if any.  I don't have the ability
to easily test IE for this case right now, but getting that data would
help; it'll either tell us that there's no compat whatsoever and we
can probably do what we want, or it'll lean towards one behavior being
something we should prefer.

This belongs in no existing spec, as form elements are technically
replaced content and outside the domain of CSS.  It will belong in the
Form Elements spec that I'm vaguely committed to writing (with smaug
from Mozilla, I think), which has the goal of documenting the
semi-replacedness of some form inputs, and explaining and specifying
which parts of an input can actually be styled cross-platform.

~TJ

Received on Tuesday, 18 November 2014 19:24:33 UTC