Re: [CSS2.1] Visual formatting model details

On Wed, 4 Feb 2004, fantasai wrote:
>
> Oh, sorry; I meant s/the other/these/.

Yes, I assumed that; it still doesn't make any more sense to me than the
current text. In fact to me "these" is more confusing, since the
properties haven't been named yet.

Either way, this is IMHO a trivial problem of little consequence.


> And also s/between/among/ and s/constraints/constraint/.

This was already in the issues list.


>>>>># 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.
>
> Then say that where it's clear the sentence applies to the whole
> process, not the "finding the preferred width" part.

The bit that is undefined is the "finding the preferred width"s part. I
don't see the problem here. Mozilla uses a different definition of
"preferred minimum width" than the spec (one that is not constant).

In any case I'm not convinced your dscription of the "improved" definition
is actually better, since it implies discontinuities in the width. I would
rather Mozilla implement the algorithm as described in the spec.


>>> 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...)
>
> Five dimensional? You really are making this way too complicated.

There are five variables. That means five dimensions, no?


> There are only two variables in any case: target width and target
> height.

There are five: w, h, wmin, wmax, and hmax.


> Two-dimensional bar graphs will do.

You solve inequalities with line graphs, not bar charts...


> Here's the problem statement:
>   1.  w > wmax
>   2.  h > hmax
>   3.  hmax/h > wmax/w
>   4.  w*hmax/h < wmin

Yes, I understand the maths fine, what I would like to see are values for
those variables that actually demonstrate the problem, such that we are
able to write a testcase.


>>>>># 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?
>
> They differ from aligning the "font". The font is the data that define
> a typeface. You're not talking about the alignment of the data, you're
> talking about the alignment of the symbols "stamped out" by that data.

I'm talking about the alignment of the data. The "em square height of the
font" is a font metric. The "baseline alignment of the font" is a font
metric. This seems like plain english to me...


> I think you mean "depending on the baseline alignment of the em boxes".

This seems like a very pedantic edit request for something which does not,
to me, seem to be misinterpretable (that is to say, all the
interpretations that aren't self-contradictory result in the same
semantics). The spec says:

# Note that this may be larger than any of the font sizes involved,
# depending on the baseline alignment of the fonts.

The baseline alignment of the fonts is the data in the fonts that
specifies how glyphs in the fonts are baseline aligned. How is it wrong?


>>> 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.
>
> If there wasn't, then I'm guessing there will be, because I did bring
> it up...

Your request was accomodated by changes to other sections, I believe.


>> In any case, the text-decoration text has now been slightly edited so as
>> to avoid (we think) this problem.
>
> Has it also made clear what text-decoration is supposed to do when
> defined on a block or were the parts relating to that also excised?

It has been made clear (we think).

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

Received on Thursday, 5 February 2004 10:37:47 UTC