- From: Brian Manthos <brianman@microsoft.com>
- Date: Tue, 13 Apr 2010 06:04:42 +0000
- To: Brad Kemper <brad.kemper@gmail.com>
- CC: Zack Weinberg <zweinberg@mozilla.com>, fantasai <fantasai.lists@inkedblade.net>, W3C Emailing list for WWW Style <www-style@w3.org>
On Apr 12, 2010, at 6:47 PM, Brian Manthos wrote: >> Given that neither padding nor border widths can be negative, it remains conveniently simple. On Apr 12, 2010, at 10:37 PM, Brad Kemper wrote: >I'm not sure I follow what you mean about the negative widths. Can you elaborate? Sure. http://www.w3.org/TR/CSS21/box.html#padding-properties "Unlike margin properties, values for padding values cannot be negative." http://dev.w3.org/csswg/css3-background/#border-width Links to <border-width>... http://dev.w3.org/csswg/css3-background/#ltborder-widthgt "<border-width> = <length> | thin | medium | thick The <length> may not be negative." If padding were allowed to be negative, the content-box could grow larger than the padding-box. If border widths were allowed to be negative, the padding-box could grow larger than the border-box. With both of these possibilities ruled out, we can be assured that border-box is never smaller than padding-box which is never smaller than content-box. This assurance allows us to ignore the border widths and padding to identify which of the 3 boxes is biggest. Further, it means we don't have to worry about cases where the padding-box has grown wider but shorter than the border-box; similarly for the content-box and padding-box. Were that not the case, then term "biggest" would mean area calculation which doesn't buy us much from an aesthetic rendering perspective at all; it would open the door for performance pain as well as visually undesirable renderings.
Received on Tuesday, 13 April 2010 06:06:27 UTC