Suggested improvement to the table in section 10.4

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.



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