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

Re: [CSS2.1] Visual formatting model details

From: fantasai <fantasai@escape.com>
Date: Thu, 05 Feb 2004 13:12:58 -0500
Message-ID: <402287AA.5090408@escape.com>
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.


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

   |---------------------------------+--------> width
   |---------------------------------+--------> 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
   |---------------------------------+--------> height

2. h > hmax
                           wmax      w
   |-------------------------+-------+--------> width
   |---------------------------------+--------> 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.

Received on Thursday, 5 February 2004 13:14:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:11 UTC