- From: fantasai <fantasai@escape.com>
- Date: Thu, 05 Feb 2004 13:12:58 -0500
- To: www-style@w3.org
Ian Hickson wrote:
>>>>>># 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).
I don't understand how making the "preferred minimum width" variable
can give you Mozilla's rendering.
> 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".
> I would rather Mozilla implement the algorithm as described in the spec.
Why?
If I have lines broken like this:
_____________________________________________
| Containing Block |
| |
| random text with short words and |
| somereallylong wordslikethese |
| whichcausethelinestobe quiteshort |
| |
wouldn't you want the box shrink-wrapped to
____________________________________________
| Containing Block |
|................................... |
|:random text with short words and : |
|:somereallylong wordslikethese : |
|:whichcausethelinestobe quiteshort: |
|................................... |
instead of
____________________________________________
| Containing Block |
|.............................................|
|:random text with short words and :|
|:somereallylong wordslikethese :|
|:whichcausethelinestobe quiteshort :|
|.............................................|
?
>>>>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.
Oh, bother. I kept thinking of w, h, wmin, wmax, and hmax as
constants. But you're right, they are variables. I didn't
pay attention to that since I was treating it more as a logic
puzzle than a numerical puzzle.
>>Two-dimensional bar graphs will do.
>
> You solve inequalities with line graphs, not bar charts...
Think outside the coordinate plane.
This is a very simple problem to visualize. We'll draw
width and height independently. Each one is represented
by a one-dimentional graph:
|------------------------------------------> width
|------------------------------------------> height
We'll draw arbitrary lines for w and h.
w
|---------------------------------+--------> width
h
|---------------------------------+--------> height
For simplicity, I'm scaling these so, visually (but
not necessarily numerically), w = h.
Furthermore, the points marked below represent the
relative positions of the values, not their actual
numerical values, so that this is generalizable to any set
of input that meets the problem statement's constraints.
Now, lets draw the other values.
1. w > wmax
wmax w
|-------------------------+-------+--------> width
h
|---------------------------------+--------> height
2. h > hmax
wmax w
|-------------------------+-------+--------> width
...............hmax..............h
|---------------------------------+--------> height
3. hmax/h > wmax/w
wmax w
|-------------------------+-------+--------> width
hmax h
|-------------+-------------------+--------> height
4. w*hmax/h < wmin
wmin wmax w
|------------------+------+-------+--------> width
hmax h
|-------------+-------------------+--------> height
There is the problem statement, represented visually.
The goal of the algorithm is, visually speaking, to pick
one point on each line such that
a) the points are within their respective min/max constraints
b) given that, the points define a line as perpedendicular
as possible to to the two axes
b) given that, the points are as close to w/h as possible.
Do you want me to run this through the text-based algorithms
for you so you can (literally) see what's going on?
(If you still think an edit to the list will be less work
than reviewing the table, say yes, and I will draw for you
all 9 graph(s) for the list and all 1 graph(s) for the table
so you will have a better basis for comparison.)
>>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.
w = 100a
h = 100b
hmax = 70b
wmax = 90a
wmin = 80a
a = units for width
b = units for height
They don't have to be the same units.
~fantasai
Received on Thursday, 5 February 2004 13:14:39 UTC