Re: [css3-regions] miscellaneous comments (mostly editorial)

(12/12/04 6:19), Alan Stearns wrote:
> After a bit of thinking, I'm now sure that this is not a good result,
> and the rest of the specification is clear that named flows are not
> equivalent to DOM manipulation (particularly in how the 'flow-into'
> property does not affect the CSS cascade). Descendant elements of
> 'display:none' should not be visually formatted, even if they are
> pulled into a named flow.

This matches WebKit's current behavior. Both behaviors would be fine by
me for now as long as the intended behavior can be easily read from the
spec.

> So the first sentence I quote above is overreaching. What I was attempting
> to do is cover anonymous box construction in cases where the sequence of
> elements in a named flow would require something different than the
> sequence in the normal flow (such as the "table * {flow-into:
> table-content} declaration in Note 3).
> 
> What if I remove that sentence, changing the paragraph to:
> 
> ---
> Elements in a named flow are sequenced in
>    document order. The visual formatting model
>    uses the relationships between elements
> in the named flow sequence as input,
> rather than the elements' original positions.
> ---

This seems better, except that I am not sure if the use of the word
"element" is right here. This is also related to my original suggestion:
s/element/box/ in

 # <ident>
 #
 # The element is taken out of its parent's flow and placed into the
 # flow with the name Œ<ident>¹.

. But then I think all sorts of wordsmithing here don't help much here
and I think you might want to consider writing this in an algorithmic way:

  1. Generate non-anonymous boxes
  2. Apply 'flow-into'/'flow-from' to the non-anonymous boxes
  3. Generate anonymous boxes.


Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/

Received on Tuesday, 4 December 2012 10:01:10 UTC