Suggested improvement to the table in section 10.4

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 24 Apr 2004 14:36:36 -0500
Message-ID: <408AC1C4.4060106@mit.edu>

```
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:29 GMT