- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 14 Jul 2011 14:24:58 -0400
- To: Tantek Çelik <tantek@cs.stanford.edu>
- CC: www-style@w3.org
- Message-ID: <4E1F347A.4030101@mit.edu>
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
Attachments
Received on Thursday, 14 July 2011 18:25:37 UTC