- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 24 Apr 2004 14:36:36 -0500
- To: www-style@w3.org

I was looking at the table in section 10.4 (applying min/max-width/height to replaced elements), and it seems unnecessarily complicated, with cases that are conceptually the same separated out into separate rows. Specifically: Constraint Violation Resolved Width Resolved Height ------------------------------------------------------------------------- w > max-width max-width max(max-width * h/w, min-height) ------------------------------------------------------------------------- (w > max-width) and max-width min-height (h < min-height) Conceptually, what's going on here is that w is too big, so we have to shrink it. We shrink it down to max-width, and compute the scaled height that corresponds to this. Since |h <= max-height| holds in both cases, the scaled value can't possibly be too big and we just have to ensure that it's not too small. I'm assuming that the way it's written right now is to have the thing in the "constraint violation" column actually be a constraint violation? Otherwise this could be rewritten as: Case Resolved Width Resolved Height ------------------------------------------------------------------------- (w > max-width) and max-width max(max-width * h/w, min-height) (h <= max-height) This is exactly equivalent to the other two casesm, since in the |h < min-height| case the scaled height will also be less than min-height (we're shrinking, recall) and the "max()" will force the resolved height to min-height. Writing it this way also makes this case more parallel to the to the two "(w > max-width) and (h > max-height)" cases... Similarly, the "w < min-width" and "(w < min-width) and (h > max-height)" cases can be combined into a single "(w < min-width) and (h >= min-height)" case (similar situation -- we have to increase width, and we know the increased height can't go below min-height). Having said all this, I can see the argument for keeping the column as a list of constraint violations, since that may disambiguate the "h < min-height" and "h > max-height" cases better (those actually correspond to "w OK but h not OK"). But the "case" version of the table could easily make this clear by writing the conditions on w in those cases explicitly. Thoughts? -Boris

Received on Saturday, 24 April 2004 15:37:17 UTC