- From: fantasai <fantasai@escape.com>
- Date: Sun, 02 Nov 2003 02:19:31 -0500
- To: www-style@w3.org
width, height: # Computed value: the percentage as specified or the absolute length; 'auto' # if the property does not apply What happens if 'auto' is specified on an element to which the property /does/ apply? S10.2 Content width: the 'width' property http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#the-width-property # The width of a replaced element's box... may be scaled by the user # agent So, will the UA scale it or no? The rules for max/min imply that it *will*. # Note: For absolutely positioned elements whose containing block... This # is a change from CSS1, where the percentage width was always calculated # with respect to the content box of the parent element. CSS1 didn't have absolute positioning. 10.3.3 Block-level, non-replaced elements in normal flow http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#q6 # The following constraints must hold between the used values of # the other properties: What "other" properties? If you mean "other than width", then you've missed the 'width' in the equation. Also: between -> among 10.3.5 Floating, non-replaced elements http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#q8 # Calculation of the shrink-to-fit width... This paragraph belongs under the 'width' property definition, not here. Shrink-to-fit width is mentioned in several sections, and it would be best to put it where one is most likely to expect it. (I'd also recommend creating a 'width' value to explicitly specify this on blocks and such, so we don't have people using tables and floats to get the shrinkwrap effect.) Also, the expanation doesn't need to be duplicated under section 10.3.7. # CSS 2.1 does not define the exact algorithm. -> CSS 2.1 does not define the exact algorithm for finding preferred widths. 10.3.7 Absolutely positioned, non-replaced elements http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#abs-non-replaced-width The organization of the prose in this section is awful. The section after the equation especially was much clearer before the rewrite. Likewise for height. 10.4 Minimum and maximum widths: 'min-width' and 'max-width' http://www.w3.org/TR/2003/WD-CSS21-20030915/visudet.html#min-max-widths # However, for replaced elements with both 'width' and 'height' # specified as 'auto', the algorithm is as follows: max-height hasn't been introduced yet. Maybe this should be put in the height section instead of the width one? Also, you should mention the *purpose* of these rules: it's to preserve the aspect ratio. # Select from the following list of width-height pairs (a, b) the # first one that satisfies the two constraints min-width ≤ a ≤ # max(min-width, max-width) and min-height ≤ b ≤ max(min-height, # max-height). The resulting pair gives the used width and height # for the element. In this list, Wi and Hi stand for the intrinsic # width and height, respectively. Use this table instead: Constraint | Resolve to Problem | width, height -------------------+------------------------------------ none | w, h w > wmax | wmax, max(wmax*h/w, hmin) w < wmin | wmin, min(wmin*h/w, hmax) h > hmax | max(hmax*w/h, wmin), hmax h < hmin | min(hmin*w/h, wmax), hmin w > max, h > max | if (hmax/h < wmax/w) | wmax, max(hmin, wmax*h/w) | else | max(wmin, hmax*w/h), hmax w < wmin, h < hmin | if (hmin/h > wmin/w) | wmin, min(hmax, wmin*h/w) | else | min(wmax, hmin*w/h), hmin w < wmin, h > hmax | wmin, hmax w > wmax, h < hmin | wmax, hmin 10.6.1 Inline, non-replaced elements # Note: level 3 of CSS will probably include a property to select # which measure of the font is used for the content height. Why are you telling us this? # depending on the baseline alignment of the fonts. What does this mean? 10.8.1 Leading and half-leading # Since the value of 'line-height' ... borders and text of previous lines. This section should be moved to *after* the 'line-height' definition. # if the height specified by 'line-height' is less than the content # height of contained boxes, backgrounds and colors of padding and # borders may "bleed" into adjacent line boxes. >if the height specified by 'line-height' is less than the content >height, backgrounds and borders may "bleed" into adjacent line boxes. # This will cause the borders on subsequent lines to paint over the # borders and text of previous lines. What about backgrounds? # The three rules in the example below have the same resultant line height: Mention that they won't inherit the same way. # The following values only have meaning with respect to a parent # inline-level element, or to the strut of a parent block-level element. Well, which one? Can I choose to always align wrt the strut? BTW, it seems to me that introducing a root inline--instead of struts, which aren't properly containing boxes like everything else in CSS--would make this section (and the one on text decoration, which essentially already assumes this) go a lot smoother. ~fantasai
Received on Sunday, 2 November 2003 02:19:41 UTC