W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: [box-sizing] and min/max/width/height was Re: [css3-ui] editor's draft updated per [CSSWG] Minutes and Resolutions F2F Kyoto Sat: CSS3 Fonts, Regions, @viewport, Variables, @supports, Selectors4, Administrivia

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 14 Jul 2011 14:24:58 -0400
Message-ID: <4E1F347A.4030101@mit.edu>
To: Tantek Çelik <tantek@cs.stanford.edu>
CC: www-style@w3.org
On 7/14/11 1:57 PM, Tantek Çelik wrote:
> Do you have a test case posted demonstrating what you mean by "how
> this is supposed to work for replaced elements"?

<!DOCTYPE html>
<img src="img-with-intrinsic-width-100x100.png"
      style="max-width: 150px; box-sizing: border-box;
      border: 40px solid transparent">

The h and w in the algorithm at 
http://www.w3.org/TR/CSS21/visudet.html#min-max-widths are both 100px. 
First of all, it's not clear whether the max-width in that algorithm is 
supposed to be 150px or 70px in this situation.

If it's supposed to be 150px, then the resolved width and height are 100 
and 100.  These are then treated as computed values.  In the only 
interpretation of box-sizing that makes sense to me so far (sorry for 
having to interpret, but http://dev.w3.org/csswg/css3-ui/#box-sizing0 
doesn't actually define the processing model), the subtraction of border 
and padding happens when going from computed to used value.  So in this 
case the image itself would render as a 20x20 pixel square.

If it's supposed to be 70px, then we end up in row 2, and the resolved 
width is set to 70px as is the resolved height.  Then we use those as 
computed values and end up with a 0x0 square for the image.

I think it's pretty clear that what we actually want in this case is for 
the image to end up as a 70x70 pixel square, which is neither of those 
results, but _is_ what WebKit, Presto, and Gecko do.  I've attached a 
test file that shows that.

But there are several ways to get there, which I don't think give 
equivalent behavior in other situations (eg. in the the cases where we 
end up in the "w > max-width) and (h > max-height), where (max-width/w ≤ 
max-height/h)" row of the table in visudet above it makes a difference 
whether we're doing "70/100" for the first ratio (corresponding to 
subtracting the border and padding from max-width before comparing to 
the intrinsic width) or "150/100" or "150/180" (corrsponding to adding 
the border and padding to the intrinsic width before comparing to the 
max-width) in the above testcase, all of which are possible values for 
that ratio depending on what the spec decides to say.

I think the 150/100 is clearly wrong.  For the rest, I think in the 
places where we're comparing ratios the ratio that makes the most sense 
is the ratio of "max-width of content area only" (so subtracting padding 
and border as necessary) to intrinsic width.  Similar for height.  And 
the definition of 'w' and 'h' needs to be adjusted so that they're the 
content-area width and height in general, and not the computed width and 
height.  And then the resolved widths at the end need to have the border 
and padding added to them as needed before being used as computed 
widths.  Again, this seems to be what Gecko, Presto, and WebKit are 
already doing at first glance, but I can't guarantee that.

Of course maybe my mental model of how box-sizing interacts with 
computed and used widths is wrong.  But _that_ interaction needs to be 
defined anyway.  Right now it's really not.  A specification here would 
clearly describe what actually needs to be changed in the various 
equations in 
http://www.w3.org/TR/CSS21/visudet.html#Computing_widths_and_margins and 
http://www.w3.org/TR/CSS21/visudet.html#Computing_heights_and_margins

-Boris


test.png
(image/png attachment: test.png)

Received on Thursday, 14 July 2011 18:25:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:42 GMT