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

Logging this as ISSUE 69 (https://wiki.csswg.org/spec/css3-ui?&#issue-69)

> On 14 Jul 2011, at 20:24, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> 
> 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

This still seems to be an open issue. While browsers seem to agree in behaviour and to follow Boris' suggestion at the end of the mail in the (simple) cases I tested, I don't css3-ui or any other spec defines the model explicitly.

If anyone can think of a case where one or more browsers diverge from the model he suggests, at TC would be very much welcome.

Otherwise, I suggest we adopt his proposal. It will need somewhat careful wordsmithing, but conceptually it makes sense to me, and seems to match reality.

 - Florian

Received on Friday, 9 January 2015 14:02:32 UTC