[CSS2.1] Visual formatting model details

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

# 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

# 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

# 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

# CSS 2.1 does not define the exact algorithm.

-> CSS 2.1 does not define the exact algorithm for finding preferred

10.3.7 Absolutely positioned, non-replaced elements

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'

# 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


Received on Sunday, 2 November 2003 02:19:41 UTC