Re: [CSS2.1] Visual formatting model details

Ian Hickson wrote:

> On Thu, 5 Feb 2004, fantasai wrote:
> 
>>>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).
>>
>>I don't understand how making the "preferred minimum width" variable
>>can give you Mozilla's rendering.
> 
> Just define the preferred minimum width as the width Mozilla achieves.

That's like saying "define the preferred minimum width (used to calculate
the shrink-to-fit width) as the shrink-to-fit width".

>>>In any case I'm not convinced your dscription of the "improved" definition
>>>is actually better, since it implies discontinuities in the width.
>>
>>I don't understand what you mean by "discontinuities in the width".
> 
> Take your example below and slowly increase (or decrease) the width of the
> containing block. Does the inner block width snap? If so, there are
> discontinuities.

Ah, I see what you mean.
It's rarely an issue, though. Most people don't have gradually
resizing boxes as layout elements, and I think the benefit of
having that unbalanced extra space sqeezed out in common cases
outweighs the possible annoyance by the "discontinuities" in this
edge case. Note that the text itself will always snap; it's only
the box edges that can move smoothly (and if there's no inline
content, those won't snap either).

>>3. hmax/h > wmax/w
>>                         wmax      w
>>|-------------------------+-------+--------> width
>>             hmax                  h
>>|-------------+-------------------+--------> height
> 
> That's hmax/h < wmax/w.
...
> Thus those numbers don't work.
 >
> This is the problem I am having with your issue here. I don't disbelieve
> there is a problem. I just haven't been able to come up with the numbers
> that actually fit the criteria you specify.

You're right, as usual. *bows* My point got lost in translation, heh.
Substitute "h/hmax > w/wmax" for "hmax/h > wmax/w". And thanks for
being so patient. :)

> When I say I want to visualise this I actually mean I want to create a
> test case and see it for myself using real CSS and real browsers, not that
> I have any trouble with the maths.  The problem is that while it is
 > sometimes possible to come up with cases that mathematically are indeed a
> problem, sometimes those cases are only relevant when you start invoking
> negative numbers or imaginary numbers.

I'm not entirely sure how one would create a CSS test case that demonstrates
how scaling by one proposed algorithm is better than scaling by another.
I could write you a testcase that shows the final result of each algorithm
so you can compare, if that's what you mean...

~fantasai

Received on Thursday, 5 February 2004 20:33:37 UTC