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

Vincent Hardy:
> Christoph Päper:
>> 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
> 
> #F {content: flow-from(myFlowName);}
> #G {content: flow-from(thirdFlow);}

These rulesets should not work in my opinion (as stated above). 

We can avoid cycles if “content: flow-from(foo)” only works within ‘@region’, not everywhere.

Can you think of a valid usecase where current

  foo {flow: bar;}
  baz {content: flow-from(bar);
    /* position, size etc. */}

could not be rewritten as 

  foo {flow: bar;}
  baz {content: none;} /* usually unnecessary */
  @region quuz {
       content: flow-from(bar);
    /* position, size etc. */}

? Note that you would still have flows without using ‘@region’: With ‘initial’ styles you have one anonymous flow (or chain of flows), foo→bar→baz→quuz, in

  <foo><bar><baz><quuz/></baz></bar></foo>

and when adding

  foo, baz  {position: static;}
  bar, quuz {position: absolute;}

you have two anonymous flows, :root→foo and :viewport→(bar→baz)→quuz, or three anonymous flows, :root→foo, :viewport→bar→quuz and bar→baz, if you analyze it differently. If I’m not mistaken there is currently no way to make that foo→baz and bar→quuz, i.e. remove children from, but keep grandchildren in the normal “descendant” flow.

> a. only a single flow can be added associated with a region.

That is a sound choice for now, since that restriction can be lifted in a later level of the module.

> b. the examples use elements as regions.

It is a cleaner design if you don’t need arbitrary markup elements, but can do regions completely in the stylesheet instead.

Received on Saturday, 6 August 2011 15:36:04 UTC