- From: Christoph Päper <christoph.paeper@crissov.de>
- Date: Sat, 6 Aug 2011 17:35:18 +0200
- To: "www-style@w3.org Style" <www-style@w3.org>
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