Re: [CSS2.1] Visual formatting model details

Note: As these comments came in after the deadline, they were not
processes with all the other comments in time for the San Diego face to
face meeting. The comments below are my own, and do not represent the
official opinion of the working group.

On Sun, 2 Nov 2003, fantasai wrote:
>
> 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?

Good question. I've added this to our "emergency" issues list (issues
which are either important enough, or trivial enough, to warrant being
fixed despite this pushing the release date even further) as issue 248.


> 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*.

Depends on the value. If the image is intrinsicly 200px, and width is
200px, then it won't be scaled. Hence "may".


> # 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.

But in CSS1, "the percentage width was always calculated with respect to
the content box of the parent element", so (the argument goes) this is a
change. (I personally disagree, since I think that the CSS1 spec's concept
is still present in CSS2.1 as "the containing block", but that's a long
issue, which we resolved by adding the above text.)


> 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.

Other than 'left' and 'right', which, if you read this section (10.3) as
pseudo-code instead of prose, would be the last two properties you looked
at. (They are mentioned at the end of section 10.3's introduction, the
"parent scope" of 10.3.3.)


> Also: between -> among

Trivial change. Filed as issue 249.


> 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 think it is put where it is used.


> (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.)

Yes, we agree (last I checked). New feature, though, see CSS3.


> Also, the expanation doesn't need to be duplicated under section
> 10.3.7.

The section isn't actually duplicated. The two differ slightly, enough
that we felt it not worth the effort to do the same with this as we did
with 'height:auto' (which is now a separate section for certain cases).


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

That's clear (IMHO) from the fact that that is what is being discussed.


> 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.

Agreed. But would require too much effort (mainly in the proof reading,
not rewriting) to change safely.


> 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?

Maybe. No strong need to do this though, so no.


> Also, you should mention the *purpose* of these rules: it's to
> preserve the aspect ratio.

Yes, that would probably have been nice. Editorial enhancement, though,
so not this time.


> # 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:

Too much work (especially in checking the table is right) to be worth the
effort since this is not a semantic change.


> 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?

Because while it was being discussed, someone asked, probably.


> # depending on the baseline alignment of the fonts.
>
> What does this mean?

I don't understand what is unclear about this.


> 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.

Probably, but the risk that such a change would cause an unintentional
semantic change (e.g. by the editor accidentally deleting something in
that paragraph) isn't worth it. :-)


> # 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.

Again, not worth it.


> # This will cause the borders on subsequent lines to paint over the
> # borders and text of previous lines.
>
> What about backgrounds?

See appendix E for the nitty gritty.


> # The three rules in the example below have the same resultant line height:
>
> Mention that they won't inherit the same way.

That should be obvious from the rest of the spec.


> # 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?

The other prose say which one, no?


> 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.

I agree. The majority of the working group did not. The strut was the
compromise solution.

Thanks for your input. Responses to comments that came before the deadline
will be sent at some point, hopefully with more positive replies to most
points!

Cheers,
-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 9 January 2004 12:42:42 UTC