W3C home > Mailing lists > Public > www-style@w3.org > March 2016

Re: [css-box] shrink-to-fit and floats

From: Pavel Panchekha <me@pavpanchekha.com>
Date: Mon, 07 Mar 2016 22:09:38 +0000
Message-ID: <CAE4=OQ_JbbyREQNfPWbDGmok_t_AnYY3uW7sRmncuBdDaOGKsw@mail.gmail.com>
Cc: www-style list <www-style@w3.org>
To: "Tab Atkins Jr. " <jackalmage@gmail.com>
> ​The section's size is well-described by the specs already.
> ​In particular, section 10.3.5 defines how to calculate the shrink-to-fit
width of the section

Yes, I understand that the shrink-to-fit of the section must be computed.
I think this section does not fully explain the algorithm to use.

​> ​the "preferred width" and "preferred minimum width" are both 10px​

This is what I cannot justify. The standard (CSS3-box, §9.11, or CSS2.1,
§10.3.5) say:​

​> Roughly: calculate the preferred width by formatting the content without
> lines other than where explicit line breaks occur, and also calculate the
*> minimum* width, e.g., by trying all possible line breaks. CSS does not
define the
> exact algorithm.​

​The outer width of the div is not known until the shrink-to-fit​ width of
the section is known,
because the div's right margin width is unknown (since the computed value
is ignored).
Thus, the spec seems to allow assuming the right margin to be -10px, or
really any other
value, which then changes shrink-to-fit width of the parent.

As a more pointed example: suppose the situation is as in my last email,
but the
div has a margin-right of -10px. Firefox renders the section as zero pixels
wide in
this case. On the other hand, without a margin-right of 0, the section is
10px wide.
Both of these are the "intuitively correct" renderings, but according to
the standard,
the used value of the right margin is ignored, so why does it affect the

(I agree that the renderings produced by browsers are correct, and also fit
the standard.
However, I cannot find where the standard does forces that rendering.)

—Pavel Panchekha
Received on Tuesday, 15 March 2016 14:14:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC