Re: [CSS2.1] Visual formatting model details

Ian Hickson wrote:
> On Wed, 4 Feb 2004, fantasai wrote:
>>>>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).

Oh, sorry; I meant s/the other/these/. And also s/between/among/ and
s/constraints/constraint/.

Like this:

    "The following constraint must hold among the used values of
     these properties:"

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

Then say that where it's clear the sentence applies to the
whole process, not the "finding the preferred width" part.
And don't tell me it's clear, because you yourself said it
was clear that it applied only to the preferred width
calculation:

   Ian Hickson:
   > fantasai:
   > | CSS spec:
   > | # CSS 2.1 does not define the exact algorithm.
   > |
   > | -> CSS 2.1 does not define the exact algorithm for finding preferred
   > |     widths.
   >
   > That's clear (IMHO) from the fact that that is what is being discussed.

>>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 only two variables in any case: target width and target
height. Two-dimensional bar graphs will do. I'll draw them for you,
if I must. But first try reading this explanation of the problem
statement and then going back over the part where I run it through
the algorithm.

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

The key to making sense of this is thinking of "hmax/h" as the
*ratio of change* used to reduce the height down to its maximum
(and likewise for "wmax/w"). In English, the statement is

   1. The width is greater than the max-width. (It needs to be
      reduced.)
   2. The height is greater than the max-height. (It also needs
      to be reduced.)
   3. The height is proportionally more over its limit than the
      width is. (It needs to be reduced more.)
   4. Reducing the width by the same proportion as the height's
      reduction brings it lower than the min-width.

If you want to look at this visually, make (or visualize) two
bar graphs: one for the width and one for the height. Mark the
current width and height, their maximums, and their minimums.
You'll have to change the target width/height lines 8 times for
the list so make it erasable/movable. (You won't have to change
it at all once you've drawn it for the table.)

http://lists.w3.org/Archives/Public/www-style/2004Feb/0001.html

As for non-drastic changes, trying to make a change to that list
that's there is much more likely to introduce errors. A single
change means you have to review the entire list. Each pass requires
so much meticulousness to work through, and checking the list
requires multiple passes. Why would you want to review /that/?
Go review the table. It's nice and simple. *Every* different case
is represented separately and clearly. You don't have to run the
algorithm on every permutation of ratios you can think of and hope
you guessed them all.

(And if you're daunted by the sheer amount of HTML coding needed
to HTMLize it, I'll code it for you.)

>>>># 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 think you mean "depending on the baseline alignment of the em boxes".

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

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

~fantasai

Received on Wednesday, 4 February 2004 23:39:20 UTC