- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 7 Aug 2012 14:26:38 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style@w3.org
- Message-ID: <CANMdWTt7BNqLHOH117_YRF0koojhoPcELj+A7YEF9oaBKKkCqg@mail.gmail.com>
On Tue, Aug 7, 2012 at 2:12 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 8/7/12 3:39 PM, Ojan Vafai wrote: > >> How should box-sizing affect things that are sized based off intrinsic >> dimensions? >> > > For what it's worth, in Gecko -moz-available (which is the fill-available > value) subtracts off the elements own border and padding in content-box > sizing but not in border-box sizing, so that the actual content width is > whatever is actually available. This seems like it has significantly > better ergonomics than the alternative. > > Similar for min-content and max-content, actually: I believe they always > set the content width, not the overall width. Yeah. That's fine with me. In fact, I think that might coincidentally already be what WebKit's implementation does. I suppose you're just getting what you ask for here? >> > > A fundamental problem with that is that it's impossible to ask for > different box sizing in different dimensions. If a page could do > content-box sizing horizontally while doing border-box vertically, it would > be a lot more reasonable to say "don't do that" when using border-box > horizontally with intrinsic widths. > > > I'm not sure it's worth adding magic to fix these cases. >> > > In case it matters, it doesn't take much magic: you just have to have the > computations for the intrinsic widths add in the padding and/or border as > needed, and then everything else works like it normally would. > > -Boris >
Received on Tuesday, 7 August 2012 21:27:27 UTC