- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 18 Nov 2014 11:23:47 -0800
- To: Florian Rivoal <florian@rivoal.net>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Karl Dubost <kdubost@mozilla.com>, www-style list <www-style@w3.org>
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