W3C home > Mailing lists > Public > www-style@w3.org > January 2015

Re: [css-sizing] Intrinsic sizing on parent, extrinsic sizing on child

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 23 Jan 2015 17:38:57 -0800
Message-ID: <CAAWBYDAfHn8vCoO9+SDix1wJrJWNzfWFyG9OaVgHf-dmuAu4Dg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style list <www-style@w3.org>
On Fri, Jan 9, 2015 at 4:50 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Sun, Jan 4, 2015 at 6:01 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> On 1/4/15 8:49 AM, Robert Hogan wrote:
>>> I'm pretty sure WebKit/Blink are correct here
>> Per spec, it's not clear what "correct" would be here, since this behavior
>> is not actually defined at all as far as I can tell.  Something that should
>> be fixed, of course.
> I think the Chrome behavior is *better*, in that it seems to match
> intent well.  But I don't think it follows from the current
> definitions in Sizing, which is almost certainly a Sizing bug; we've
> been pretty sure for a while that our handling of intrinsic sizes of
> replaced elements is wrong.  We also simply dont' define what the
> min-content size contribution is of a replaced element, so the current
> spec's answer to the question is mu.
> Okay, so what should it say?  I suspect that the contribution should
> be the size, if it's definite, or the intrinsic size otherwise,
> clamped by min/max.  Assuming that a min/max-content size is
> considered definite, that'll give us the desired behavior here, I
> think?

Spec has been updated with this definition.

Received on Saturday, 24 January 2015 01:39:44 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:47 UTC