css 2.1 negative width calculations?

[dave8421]

Hi,

I am reading CSS 2.1 draft specification:
http://www.w3.org/TR/2006/WD-CSS21-20061106/

Part of section 10.3.3 (Block-level, non-replaced elements in normal
flow) reads:

If there is exactly one value specified as 'auto', its used value
follows from the equality.

In the case that
margin-left + margin-right width of containing block
(see the constraint in 10.3.3) this would mean that 'width' would be
computed as a negative value in order for the equality to balance.

I'm not sure how a negative width is interpreted. It would seem that
from tests in firefox and opera that they treat used width as 0.

[Ben C]

On 2007-01-26, da******@hotmail.com <da******@hotmail.comwrote:

Hi,

I am reading CSS 2.1 draft specification:
http://www.w3.org/TR/2006/WD-CSS21-20061106/

Part of section 10.3.3 (Block-level, non-replaced elements in normal
flow) reads:

If there is exactly one value specified as 'auto', its used value
follows from the equality.

In the case that
margin-left + margin-right width of containing block
(see the constraint in 10.3.3) this would mean that 'width' would be
computed as a negative value in order for the equality to balance.

Yes.

I'm not sure how a negative width is interpreted. It would seem that
from tests in firefox and opera that they treat used width as 0.

I'm not sure the spec says anywhere how to interpret a negative width.
You can't actually set a negative value for the width property (that's
"illegal"), although as you say the computed value can be negative.

It makes most sense for it to be rendered as equivalent to 0 (rather
than rendering the box inside-out!)

[Ben C]

On 2007-01-26, da******@hotmail.com <da******@hotmail.comwrote:

Hi,

I am reading CSS 2.1 draft specification:
http://www.w3.org/TR/2006/WD-CSS21-20061106/

Part of section 10.3.3 (Block-level, non-replaced elements in normal
flow) reads:

If there is exactly one value specified as 'auto', its used value
follows from the equality.

In the case that
margin-left + margin-right width of containing block
(see the constraint in 10.3.3) this would mean that 'width' would be
computed as a negative value in order for the equality to balance.

I'm not sure how a negative width is interpreted. It would seem that
from tests in firefox and opera that they treat used width as 0.

The other thing is that even if the browser does follow the spec and
compute a negative width, and renders that as a zero width (which seems
the only logical choice), then it has to choose whether to respect the
styled value of margin-left or the styled value of margin-right-- it
can't make both true.

What they mostly seem to do is clamp width to 0 and solve the equality
by taking the difference out of margin-right (and it seems logical it
ought to be margin-left if direction is rtl).

I think it would make more sense if the spec were written that way.