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