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


From: Alex Mogilevsky <<>>
Date: Tue, 12 Jul 2011 02:45:43 -0700
To: Adobe Systems <<>>, Anton Prowse <<>>, "<>" <<>>
Subject: RE: [css3-regions] Comments on Editor's Draft

I have also added a few notes, with [am]


Is it possible for an element to be both a region and to be added to a
named flow that is then assigned to that same region?

#article {
        content: from-flow(article);
        flow: "article";

This would mean that article somehow contains itself!

[VH] Setting the 'flow' property on '#article' moves it to the named flow where it is concatenated with other content (that have their 'flow' property set to the same named flow.

Then, the 'content:from-flow(<flow-name>)' property specifies that #article is a region and should pull its content from the given named flow. So if the flow contains A, B and C, we could represent the flow as:

A -> B -> C

if B now gets content from the flow, that means that it would potentially need to layout itself. That does not work and we should mention in the spec that it is an error. But moving the _content_ of B to the named flow and then using that content (the case you mention below) would work:

#B * {
      flow: article;

#B {
      content: from-flow(article);

The flow is now:

A -> B's children -> C

and there is no issue with having B layout some, all or none of its children along with some of A/C.

[am] you probably want to use a child selector for that purpose

                #B > * { flow:article }

>> [VH] Yes, you are correct, this is what I meant (a child selector, not a descendant selector). My bad.

The descentdant selector “#B * {flow:article}” is still valid though, so the spec needs to explain what exactly it means. For example, if HTML inside B has a table, then table, rows and cells all individually have “flow:article”, it probably means that the flow gets an empty table followed by empty rows, followed by table cells (which will eventually get wrapped into an anonymous table. It doesn’t make much sense to do, but I think that is what is going to happen.

>> [VH] Yes, this is what would happen.


Note that the definition doesn't rule out the multicol element itself
(assuming the wider definition of container); presumably if the multicol
element is itself a region then any flow associated to it fills all
columns and cannot be managed on a column-by-column basis.

[VH] Yes.

[am] what happens if a multicolumn element becomes a region it is ambiguous so far. I think it stops being multicolumn but simply becomes a container. But it is not what is implied here, is it? It sounds potentially useful, and also potentially complicated to implement…

>> [VH] You are correct, this is not what I was implying. I was suggesting that the attached flow is subject to the layout of the container it is attached to, I.e., multi-column in this case.


Received on Wednesday, 13 July 2011 20:52:40 UTC