Re: [CSS2.1] Visual formatting model details

Ian Hickson wrote:
>
>># 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.
...
> but that's a long issue, which we resolved by adding the above text.)

Figuring out how to explain this difference was a long issue? wow.

>>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.
> 
> ...if you read this section (10.3) as pseudo-code instead of prose...

:/ Can't you just s/other/these/ so I can read the prose as prose?

> >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 think it should be put in one place: where width itself is defined.
Defining it in two different places makes the prose less organized
and more prone to errors

like this one:

# Thirdly, find the available width: in this case, this is the width
# of the containing block minus 'margin-left' and 'margin-right'.

The available width should be the width of the containing block minus
margin-left, margin-right, border-left-width, border-right-width,
padding-left and padding-right. In other words, it's the maximum width
that will fit the constraint equation for non-replaced blocks.

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

It's also not too good, if that's what's meant. Mozilla, for example,
improves on the definition given here by shrink-wrapping the width to
the maximum line length after the text has been wrapped to the
min(max(...), preferred width) length. That's not allowed if the
min(max(...), preferred width) part is normative.

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

It would be less of a change from the original (2.0) wording, though.

Something like this, perhaps:
http://fantasai.inkedblade.net/style/specs/css2.1/width#abs-non-replaced-width

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

What, you're afraid of deleting something again?

Insert "in order to preserve the aspect ratio" between
"However," and "for replaced elements".

IMO it's important to give readers a sense of what these rules
are for; it gives them something to hang on to while they try to
decipher this obfuscated bit of pseudo-code.

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

It is, actually, a semantic change.

Consider the case where
    w > wmax
    h > hmax
    hmax/h > wmax/w
    w*hmax/h < wmin

In the current text, we read down the list of choices and pick the
first one that will get wmin <= w <= wmax and hmin <= h <= hmax

    1. (Wi, Hi)

w > wmax, so no go

    2. (max(Wi, min-width), max(Wi, min-width)*Hi/Wi)

w > wmax again

    3. (max(Hi, min-height)*Wi/Hi, max(Hi, min-height))

h > hmax; keep going..

    4. (min(Wi, max-width), min(Wi, max-width)*Hi/Wi)

ok, the width is good now, but the height hasn't been
reduced enough (remember hmax/h > wmax/w)

    5. (min(Hi, max-height)*Wi/Hi, min(Hi, max-height))

Here both the height and the width are under max, but
the width has gone below its minimum.

    6. (max(Wi, min-width), min(Hi, max-height))

width is too big

    7. (min(Wi, max-width), max(Hi, min-height))

height too big

    8. (max(Wi, min-width), max(Hi, min-height))

width and height both too big

    9. (min(Wi, max-width), min(Hi, max-height))

and here we are at our final destination.
   width = max-width
   height = max-height

But -- recall that ideally, the width would be w*hmax/h,
which is smaller than max-width. It didn't work because
it was under the minimum, so we went back up to max-width.

We didn't *have* to go that far back up, though. We could
have just stopped at the min-width.

Which is what I do in my table.[1] Scan down the first column
until you reach the problem w > wmax, h > hmax:

       Problem      |                 width, height
-------------------+------------------------------------
                   ...
w > max, h > max   | if (hmax/h < wmax/w)
                    |                  wmax, max(hmin, wmax*h/w)
                    | else
                    |   max(wmin, hmax*w/h), hmax
                   ...

The height was more over the limit than the width (hmax/h > wmax/w),
so we have the case

    max(wmin, hmax*w/h), hmax

and since hmax*w/h is below wmin, the final result is

    wmin, hmax

which is much closer to a proportional scaling than

    wmax, hmax

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

If someone had asked whether CSS3 would allow one to set underlines
and overlines separately, would that have been considered relevant
enough to put in CSS2.1, too?

>># depending on the baseline alignment of the fonts.
>>
>>What does this mean?
> 
> I don't understand what is unclear about this.

The fonts aren't being aligned. The glyphs are. So either you're
talking about the baseline alignment of the glyphs, or you're talking
about baselines defined in the font--or maybe something else, I don't
know.

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

I suggest you read that again. "The content height of contained boxes"
is not the same as "the content height". The content height of contained
boxes could be more or less than the content height of their container.
If you mean content height, write content height. If you mean the border-
box height of the contained boxes, then write that.

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

Are you saying that you don't want to make this reflect Appendix E?

"This may cause inlines on subsequent lines to paint over the
  inlines of previous lines." -- this at least doesn't imply that
there's a difference in how backgrounds and text are layered.

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

So, you're saying the working group agreed to a root inline for the
purposes of text-decoration, but not for the purposes of vertical
alignment, and because they couldn't agree whether or not they
disagree in general, they decided not to edit the Anonymous Inlines
section to explain how anonymous inlines are created?

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

Thanks for the reply, Ian. It is always appreciated. :)

~fantasai

[1] fantasai. "[CSS2.1] Visual formatting model details", www-style@w3.org
       (2003-11-03).
       message-id: <3FA4B003.5080204@escape.com>
     http://lists.w3.org/Archives/Public/www-style/2003Nov/0003.html

Received on Wednesday, 4 February 2004 03:14:32 UTC