W3C home > Mailing lists > Public > www-style@w3.org > July 2011

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

From: Christoph Päper <christoph.paeper@crissov.de>
Date: Tue, 26 Jul 2011 12:36:13 +0200
Message-Id: <5CF86235-0A19-45AE-9658-56EF476591B5@crissov.de>
To: "www-style@w3.org Style" <www-style@w3.org>
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.

>> 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.

> 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/>

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.

PS: I would really appreciate it if you could follow the usual conventions for quoted text and remarks to it, because it’s sometimes hard to differentiate your text from that of previous contributors.
Received on Tuesday, 26 July 2011 10:36:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:55 UTC