W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css4-text? css4-box?] Absolutely positioned child elt, ignore width of parent elt for linebreaking

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 May 2013 08:37:44 -0700
Message-ID: <CAAWBYDBT=9Cx0SjbAwjpt_OQbL2vb+fQ2=6Mz=o5_M1uMw_hrQ@mail.gmail.com>
To: Zack Weinberg <zackw@panix.com>
Cc: www-style list <www-style@w3.org>
On Wed, May 1, 2013 at 8:25 AM, Zack Weinberg <zackw@panix.com> wrote:
> In the attached test case, the three outlined boxes are laid out at their
> narrowest possible width without breaking words, because despite being
> position:absolute (which takes them out of flow) and width:auto, they are
> *structurally* inside containers with fixed, narrow widths.  If you comment
> out width:30px in the first style declaration, they are instead laid out at
> their widest possible width given the max-width setting and the measure of
> the text.
>
> As far as I can tell, there is no way to get the "widest possible" behavior
> with this HTML structure and a fixed-width parent element.  It would be nice
> if there were such a way; this structure may be necessary for other reasons
> (I tripped over this while trying to put <details> elements in a table).

This happens, obviously, because the parent is still providing the
containing block for the absposes.  If you comment out the
position:relative, they'll also lay out widely, as they switch to
using the ICB as their containing block.

You want either:

1. Explicit control over the containing block, or
2. The sizing keywords, so you can say "width: max-content;" on the
absposes (and then use max-width to prevent them from going crazy, as
you've done in your example).

The latter is already present in the Sizing draft, and Moz implements
the values prefixed (Chrome is also implementing them).  The former
doesn't exist yet, but I've got some early ideas for it on my blog,
and plan to explore it in the future in the Positioning module

~TJ
Received on Wednesday, 1 May 2013 15:38:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC