Re: [css3-regions] Comments on Editor's Draft

Hi Christophe,

On Jul 26, 2011, at 3:36 AM, Christoph P�per wrote:

> Vincent Hardy:
>> Hi Christoph,
>>> 
>>> This would not be the case if named flows were only possible with explicit, selector-based �CSS regions� (and not with implicit, node-based �DOM regions�), whether they be anonymous,
>>> 
>>> A, B, C {content: to(B), none;}
>>> @region {content: from(B); foo: bar;}
> 
> Here there are three grouped element selectors, �A, B, C�, that push their content into the named flow �B�. The first rule then also explicitly removes that content from the DOM nodes A, B and C by using �none� � this might happen by default.
> 
> Then an anonymous region is specified, i.e. there is no identifier directly follwing �@region�, which pulls in the content from the named flow �B� (and also applies some other value, �bar�, to a random property, �foo�).
> 
> I chose the flow name �B� to show that the namespaces of markup language elements or DOM tree nodes and that of CSS flows are completely distinct.

ok.

> 
>>> or named regions,
>>> 
>>> A, B, C {content: flow(B), none;}
>>> @region B {foo: bar;}
> 
> The first rule is the same as above, just using a different naming convention[1], and � using the current ED, almost � the snippet is the same as:
> 
>  A, B, C {flow: B;} 
>  @region B {content: from-flow(B); foo: bar;}
> 
> This time the region is not anonymous, but named �B�. In this suggested model, although the namespaces of flows and regions are separate in principle, any named region automatically pulls content from a flow of the same name.

ok.

> 
>> I did not follow your example. What I meant was:
>> 
>> #A, #B, #C {flow: myFlowName;}
>> #B {content: from-flow(myFlowName);}
>> 
>> creates a circular dependency.
> 
> I know. You�re using here what I called �implicit, node-based DOM regions�.
> 
> I tried to suggest that the second rule should never be possible, because nodes should not be able to pull arbitrary flows, only purely CSS-based ones � using �@region� � should do that. Document nodes should only support anonymous flows that contain their DOM descendants only:
> 
>  #B {display: region /* not actually a valid value,
>                         but a placeholder for �grid� etc. */;}
>  #A, #B, #C {flow: myFlowName;}  
>  @region foo {content: from-flow(myFlowName), from-flow(secondFlow);}
>  @region {content: from-flow(thirdFlow);}
> 
>  <x id=A>
>    <y id=B><z id=C/><z id=D/></y>
>    <y id=E/>
>  </x>
> 
> would work and had this �region/flow tree�, assuming �foo� is large enough to contain all in �myFlowName�:
> 
>  foo (named region)
>    myFlowName (named flow)
>      x#A (anonymous default region)
>        _ (anonymous default tree flow)
>          � (y#B was here, but is now in a different flow)
>          y#E (anonymous default region)
>      y#B (anonymous display-induced region)
>        _ (anonymous default tree flow)
>          � (z#C was here, but is now in a different flow)
>          z#D (anonymous default region)
>      z#C (anonymous default region)
>    secondFlow (named flow)
>      � (empty)
>  _ (anonymous region)
>    thirdFlow (named flow)
>      � (empty)
> 
> Please note that in this model the root(s) are regions and every region contains 0�n flows (nothing else) and every flow contains 0�m regions (nothing else).
> 
> [1] I tried to develop a model for all possible flow/region variants in <http://lists.w3.org/Archives/Public/www-style/2011May/0382.html>, but recently discovered that I missed some.

Yes, I remember that discussion.

To get to your example, here is how it would work in the current spec.:

#A, #B, #C, #secondFlow {flow: myFlowName;}
#F {content: flow-from(myFlowName);}
#G {content: flow-from(thirdFlow);}

<x id="A">
    <y id=B><z id=C/><z id=D/></y>
    <y id=E>
</x>
<x id="secondFlow">..</x>
<z id="F"></z>
<z id="G"></z>

The differences with your examples are:

a. only a single flow can be added associated with a region. I think it is more common to want to concatenate multiple elements into a flow and then associate that flow to a chain of regions than to have multiple flows that are associated with a single region. So the revised example above appends 'secondFlow' to the end of 'myFlowName'

b. the examples use elements as regions.

Cheers,
Vincent

Received on Tuesday, 2 August 2011 18:35:31 UTC