W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: Control over collapsing margins

From: Patrick Garies <pgaries@fastmail.us>
Date: Wed, 29 Apr 2009 23:49:13 -0500
Message-ID: <49F92DC9.6080102@fastmail.us>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: www-style@w3.org
Boris Zbarsky wrote:
>  What you're seeing here (presumably with all browsers) is various
>  artifacts of their internal data storage for CSS data.
>
>  In particular, Gecko stores lengths internally as integers in units
>  of 1/60 of a CSS px.  0.5/60 = 0.008333333333333333... (the 3
>  repeats), so any value of the form 0.0083...34 will end up rounding
>  to "1" in these internal units and give a nonzero length.   Any
>  positive value smaller than the above repeating decimal will round to
>  0.
>
>  If it ends up 1, then it will in fact affect layout: everything below
>  will be shifted by 1/60 of a px.  If you have 60 of these in a row,
>  you will in fact see a 1px offset on screen.  There's some rounding
>  and pixel-snapping that happens at paint time, of course, but that's
>  done to device pixels, not CSS pixels (so if you're on a 6000 dpi
>  device or so you'll actually get an entire device pixel devoted to
>  that 1/60px of padding).

I figured that there was a reason for the odd number; thanks for the 
explanation.

Boris Zbarsky wrote:
>  I doubt that will happen in the near future for performance reasons.
>  Gecko has been thinking for a while about switching to floating point
>  for the value storage, which will replace the arbitrary threshold
>  0.5/60 with the arbitrary threshold of "smallest floating-point
>  number that can be expressed on your architecture"; in practice
>  that's pretty close to what you're asking for, I suspect.  You'd
>  certainly have to try pretty hard to tell the difference.

Using floating point numbers would not be optimal, but would be 
significantly better. You'd have to go through a lot more decimal places 
to see any peculiarities. This point would be somewhat moot though if we 
just had a mechanism to suppress collapsing.

Boris Zbarsky wrote:
>  Out of curiousity, is the Opera and Safari behavior that the padding
>  ends up nonzero if it's at least 0.5 CSS px, or if it's at least 0.5
>  device px?  Or do they not differentiate between the two?

I'm not sure how I would test that.

If it's just seeing that the threshold is met at |0.5px| or 0.5/96th of 
a pixel, then their thresholds are significantly higher: I did some more 
testing and found that Opera and Safari both have their own 
smaller-than-one thresholds as well; they stop collapsing margins at 
thresholds of 0.99499997496604… and .98999997973442… pixels, 
respectively, which are even weirder numbers than Mozilla Firefox uses. 
Unlike Firefox, however, they both draw a pixel of padding in every 
instance of the threshold being met. (Presumably, both numbers go on; I 
stopped testing at 14 fractional digits.) I don't have the slightest 
clue where these numbers are coming from.

As for WIE8, it doesn't follow the same pattern; the threshold seems to 
be a flat 0.01 pixels after testing to 113 decimal places.

— Patrick Garies
Received on Thursday, 30 April 2009 04:50:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT