W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css3-flexbox] Flex items with negative margins

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 27 Nov 2012 13:48:55 -0800
Message-ID: <CAAWBYDB5hMK+ShmSms3zKWGse4r+NDh-BbE=tNLMHLm=Cv38qg@mail.gmail.com>
To: Tony Chang <tony@chromium.org>
Cc: "www-style@w3.org" <www-style@w3.org>
On Tue, Nov 27, 2012 at 1:24 PM, Tony Chang <tony@chromium.org> wrote:
> What should happen if a flex item has a negative margin?
> Here's an example:
> <div style="display:flex; width: 100px">
>     <div id="a" style="flex: 1"></div>
>     <div id="b" style="width: 10px"></div>
> </div>
> If we give #b a left margin of -50px, what should happen?  In ToT WebKit and
> Gecko, this causes the available space to go from 90px to 140px and #a
> flexes to fill this.  #a ends up being 140px wide, overflowing the flexbox.
> I also get weird behavior when I set the cross axis margins to negative
> values because we think there's additional space in the cross direction.
> This seems very unintuitive.  I think the simplest thing to do is to treat
> negative margins as 0 both for calculating available space and for
> positioning.

This is already in the spec - except for margin-specific things, the
spec talks only about margin boxes, which are shrunk by negative
margins.  This does indeed allow for weird results, but that's the
intent of negative margins, and how they already work in block layout,
including things like margin boxes gaining negative dimensions.

The right answer is probably "don't use negative margins", but given
that they exist, and their handling is simple (if sometimes dumb), we
should just do it.

Though... I am sympathetic to not caring about negative-dimension
margin boxes for the purpose of calculating available width. (That is,
clamping the dimensions of margin boxes to a lower bound of 0, when
doing that calculation.)

Received on Tuesday, 27 November 2012 21:49:44 UTC

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