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

On 11/6/12 1:10 PM, "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com> wrote:

>I have some fairly random editorial comments and some of them were
>raised in the past:

Thanks again for your read-through. I've taken all of your suggestions
with these exceptions:

>
>  # <ident>
>  #
>  # The element is taken out of its parent's flow and placed into the
>  # flow with the name Œ<ident>ı.
>
>This sentence, as well as the the restriction that 'flow-into' doesn't
>apply to ::before and ::after, tricks me into thinking that 'flow-into'
>might be element-level manipulation and a decendant element of 'display:
>none' can show up in a CSS Region when set with 'flex-into'.
>
>s/element/box/ might be better (Really?) but if this is too apparent to
>other readers, I can retract this comment.

This is currently vexing me. Named flows *are* very much like
element-level manipulation, particularly when you consider these sentences:

---
The structure of a named flow is equivalent to the result
   of moving the elements to a common parent. The visual formatting model
   uses the relationships between elements in the named flow structure as
   input, rather than the elementsı original positions.
---

I think this does imply that an element with a display:none ancestor
pulled into a named flow by itself would be displayed in its region
fragment(s). But I'm not sure whether that's a good result.


>
>  # Note 3
>  #
>  # table > * {flow-into: table-content} ...
>
>I'd say this is a bad example, at least for authors. The fact that
>descendant combinator is bad for 'flow-into' can be explained with a
>case that's more common and doesn't involve anonymous table objects...

Accidentally invoking table fixup was the point of the example. Do you
have a preferred alternative to use?

>
>  # 3.2.1. Cycle Detection
>  #
>  # The dependency graph consists of edges such that:
>  #
>  # * Every named flow depends on its elements where the value of
>  # Œflow-fromı computes to an <ident> .
>  # ...
>
>s/flow-from/flow-into/?

No, in this case it's meant to be flow-from. It's named flows containing
regions (created with flow-from) that need to be evaluated for cycles.

>
>  # 3.5. The @region rule
>  #
>  # The Œ@regionı rule consists of the keyword Œ@regionı followed
>  # by a selector and a block of style rules.
>
>Am I right that the block of style rules can't contain ::before and
>::after? But I am not really getting the model, so..

You should be able to use ::before and ::after style rules in an @region
block.

>
>  # Example 4
>  # ...
>
>I don't understand the picture. Why is there blue border under paragraph
>p_1? Isn't div div_1 the parent element of both paragraph p_1 and
>paragraph p_2? Is this what's supposed to happen if 'div {...}' is 'div
>{ border: blue;}'? If so, please just expand 'div {...}'.
>
>The remaining wording is just quite confusing and I can't tell if it's
>the fragments or elements that match selectors.

I agree. I've added an issue to rework the example with actual style
changes to be reflected in the illustration.

Thanks,


Alan

Received on Wednesday, 14 November 2012 23:49:38 UTC