W3C home > Mailing lists > Public > www-style@w3.org > February 2004

Re: [CSS2.1] Visual formatting model details

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 4 Feb 2004 15:01:27 +0000 (UTC)
To: fantasai <fantasai@escape.com>
Cc: www-style@w3.org
Message-ID: <Pine.LNX.4.58.0402041310140.9089@dhalsim.dreamhost.com>

On Wed, 4 Feb 2004, fantasai 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.

No, figuring out whether it should be changed was.


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

"these" doesn't really work here IMHO (and is no more readable than
"other", again IMHO).


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

To be honest, at this stage we are not concerned with fixing hypothetical
problems. If there are real errors then we can look at fixing them, but if
the working group continues to rearrange text in some quest to get the
perfect prose, we'll never publish, which would be even less useful than
having a buggy spec.


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

Noted.


>>># CSS 2.1 does not define the exact algorithm.
>
> 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.

CSS 2.1 does not define the exact algorithm.


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

Yes but the proof reading for those changes has already happened.


> Consider the case where [ratio problem]

Could you propose a less drastic change to the spec which still solves the
problem? (I tried to visualise the case you mentioned, but couldn't solve
your inequalities in my head and didn't have five dimensional paper at
hand to graph them to determine a solution, which makes it hard to
understand exactly what case you are solving...)


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

Maybe. That wasn't ever really discussed, at least not to the same extent
as the above case.


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

How do the two cases differ? Whether it is baseline aligment of glyphs, or
the baseline metrics in the font, the point is the same.


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

It turns out this was fixed at some point anyway.


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

I'm saying the real explaination is in appendix E, and so long as this
text doesn't contradict it, there's no problem.


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

The current text doesn't imply anything to do with backgrounds. It just
doesn't mention them. Please don't try to read between the lines in specs,
take them literally. When one second guesses normative prose, one is much
more likely to find errors that aren't really there in the first place...


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

Correct.


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

I don't think there was any formal decision not to edit that section.
In any case, the text-decoration text has now been slightly edited so as
to avoid (we think) this problem.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 4 February 2004 10:01:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:26 GMT