[css3-regions] Comments on Editor's Draft

I've just been reading through the Regions proposal.  The underlying 
idea feels rather natural.  However, I couldn't grasp some significant 
aspects of model.

Before we get to those, though, I want to bring up a couple of general 
things that occurred to me early on:


Is it possible for an element to be both a region and to be added to a 
named flow?

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

#sidebar {
 content: from-flow(sidebar);
}

#article would be a region element whose visual contents come from a 
flow named article but whose document children (and indeed itself) 
belong to a flow named sidebar which renders those elements.

That would mean that the #article principal block box would be flowed 
out by #sidebar principal block box (and any positioning etc of #article 
would be with respect that that location).


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!  Yet adding a 
region's own content to a named flow that that's flowed into the same 
region isn't so strange an idea:

<div id="article">
 <p>text</p>
</div>

I might want to flow *extra* content from elsewhere into the #article 
box in addition to its own document content.  To do this I would have to 
add its own document content to a named flow, along with the extra 
content.  The problem is that I don't want to add #article *itself* (ie, 
the container) else we get the infinite loop above.


The underlying difficulty seems to be that, when assigning an element to 
a named flow, we don't get the choice of whether the element and its 
children are in the flow or whether just the children are in the flow.

This also likely means (depending also on the answers to the above 
questions) that it's not possible for an element to define a region and 
have its own contents flowed into another region.  For example, I might 
only want the children of #article to be shoved into a different region, 
whilst leaving #article itself alone (perhaps to be used as a region or 
perhaps to be used for layout in some other way).  I'm concerned that 
this will cause authors to use "wrapper divs", which is kind of thing 
that we're hoping the CSS3 layout specs will relieve us from.


Now to my other points.


Flows
-------

2.1 (Named flows):

   # the absolutely positioned elements are part of a special flow 
(called positioned flow)
   # which is subject to a special layout by its container box (i.e., 
its container box positions it
   # into the containing block's box

2.4.4 (Generated flow):

   # pseudo-elements [under certain conditions] create a generated flow 
which they format
   # visually.

Is there just one positioned flow and just one generated flow, or does 
each abspos give rise to a new (anonymous) positioned flow, for example? 
  If there's just one, then it doesn't seem to be conform to the usual 
behaviour of a flow defined elsewhere in the proposal since the 
positioned flow would cleverly break into different regions without any 
regions-related machinery defining the break points.

2.4.2 (Positioned flow) suggests otherwise, that in fact there are 
multiple flows:

   # An absolutely positioned element is placed into the positioned flow 
of its container. The
   # container positions this element into its containing block.

If 2.4.2 is correct then the sentence quoted above from 2.1 is 
confusingly worded.  What we have is some ancestor container box of an 
abspos (as opposed to the principal block container box generated by the 
abspos) taking responsibility for positioning the specific positioned 
flow formed or contributed to by the abspos element, and said container 
box positions that flow into the abspos element's containing block.

2.4.1 (Normal flow) says:

   # In the CSS formatting model, elements are by default placed in the 
normal flow of their
   # container. Also by default, a container element gets its content 
from its normal flow.
   # This means that by default, a container element will visually 
format its children elements
   # and will be the only container associated with its normal flow.
   #
   # Note that floats and relatively positioned elements, in this model, 
are part of the same
   # flow of content and flow into the same container but are positioned 
in different ways.

I imagine that it is widely-held that there is just one normal flow in 
CSS21 and that it is associated to some higher abstraction (perhaps the 
viewport) rather than to some element.  The proposal now appears to be 
saying that *every* container box has an associated normal flow 
(although elsewhere the proposal refers to an apparently singular normal 
flow).  Why is this necessary for the regions model?  Is it directly 
related to the behaviour of the 'content' property?

Note that section 2.1 itself seems to think that there is just one 
normal flow, although it says

   # [...] there is a notion of flow containing a sequence of elements 
and there is a notion of
   # (block) container box into which the elements flow.

which, I suppose, could equally well be talking about any of multiple 
normal flows assigned to containers.


2.4.2 (Positioned flow) says:

   # If a container has children in the normal flow and in the 
positioned flow, it applies
   # different positioning schemes to each flow.

Whatever the container box is (see above), the interesting thing is that 
it may be assigned multiple flows, which may be handled differently. The 
positioned flow is obviously a bit special, but what happens if multiple 
named flows are assigned to a single region?  How do they compete?  For 
example, what happens if a region with content (ie a region which 
implicitly has normal flow children) is assigned a named flow? Or is it 
the case that a region can only be assigned at most one positioned flow 
and one non-positioned flow?


Editorial note: I think 2.4 (The Visual Formatting Model and Flows) 
should be combined with 2.1 (Named flows) or at least directly follow it.


Container boxes
--------------------

2.1 says:

   # [...] there is a notion of flow containing a sequence of elements 
and there is a notion of
   # (block) container box into which the elements flow.

I'm not sure that the container box referred to is really a block 
container block.  Indeed, at the end of the section, examples of a 
container's layout scheme are the normal layout (block and inline 
formatting), table layout, and multi-column layout.  Yet whilst a table 
box (as opposed to table wrapper box) and a multicolumn box are indeed 
containers in the sense that they define a layout scheme for children, 
neither of them are *block* container boxes as defined by CSS21.  So 
"container" is being used in a more general sense in the proposal than 
in CSS21.

On a related note, 2.4.2 (Positioned flow) says:

   # An absolutely positioned element is placed into the positioned flow 
of its container. The
   # container positions this element into its containing block.

However, the abspos element's containing block isn't necessarily 
established by its nearest ancestor block container box, so it's not 
clear which container box is referred to in 2.1.  Quite possibly it's 
supposed to be the box which establishes the containing block.

Back to 2.1:

   # A flow gets formatted visually when associated with one or several 
elements' container
   # box(es)

This seems reasonable (under the wider definition of container).  It's 
not clear why these more general container boxes are required to arise 
from an element though, although that could be made true if such 
containers were assigned a corresponding pseudo-element in the case 
where there is no corresponding document element.

The constraint is reinforced in the proposed definition of a region:

   # A region is an element that generates a block container box and has 
an associated
   # named flow

Here, as above, candidates for regions are explicitly restricted to 
elements; but furthermore they are restricted to elements which 
themselves generate a container box.  This immediately rules out columns 
of a multicolumn element (as stated in 5.2.2 albeit with incorrect 
reasoning), since columns don't arise directly from an element.  [Given 
that the proposal talks a lot about multicol, it took me a while to 
realize that multicol doesn't itself conform to the regions model 
(despite motivating it) since, whilst it does amount to a flow into 
various areas (columns), it's not a flow into *regions*.  (It would be 
good to change that word in 2.3.4.)]

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.


Technical details
---------------------

3.1 (The ‘flow’ property):

   # The containing block for absolutely positioned descendants of an 
element with a
   # specified flow is the region into which the element is rendered.

Really?  That means it's no longer necessary to add position:relative to 
"layout cells" as is common practice in CSS21-era float-based layouts 
for example.  Of course, it also means that you can't "break out" of the 
region and do abspos'ing with respect to some ancestor positioned 
element.  Is this change from CSS21 justified, bearing in mind that you 
/could/ manually add position:relative to the region if desired?


   # All the elements participating inside a named flow are rendered as 
children of an
   # anonymous block that spans across all the regions associated with 
the specified named
   # flow.

I'm not sure what this means, nor what the technical role is of this 
anonymous block.


   # Regions create a new stacking context, but inherit the floats that 
are already defined by
   # the parent context.

I don't understand what that means, and the following Example didn't help!


   # For an <iframe>, an <object> or a <embed> element, the ‘flow’ 
property has a different
   # behavior. The effect is similar to turning the ‘display’ property 
on the element to ‘none’
   # while moving the root element of the referenced document to the 
named flow.

This seems a bit dubious!  What happens to the UI that would ordinarily 
correspond to the element?


3.2 (The ‘content’ property):

   # none
   #    For ‘::before’ and ‘::after’ pseudo-elements, the pseudo-element 
is not generated. For
   #    other elements, the element will not get any content for its 
visual formatting. If the
   #    children of the element are not directed to a flow referenced by 
another region, then
   #    they are not visually formatted. An element with its value set 
to ‘none’ is said to be
   #    disconnected.

But it's not the element itself that is disconnected; rather it's the 
content of the element that is disconnected from the element.


Under all values of 'content' other than none and normal, it's not 
specified what happens to normal flow descendants.  Are they not 
rendered (ie disconnected)?


3.6 (The @region rule):

   # the ‘::region-lines’ pseudo-element can be used to select the 
inline content of an
   # element that falls into a particular region

What's the use case for this pseudo-element?  Does it exist to correct 
for the fact that, if an element is split across regions, it will not be 
subject to region styling in any of the regions it is part of?  If so, 
it seems odd that one could target the inline content but not the 
element itself... although thinking about the difficulties surrounding 
complex styling of the two halves of a split element, perhaps the 
proposal's suggestion of restricting ::region-lines to the same set as 
those available on the :first-line is the best that can be hoped for.

And aren't the following two snippets more or less equivalent (excepting 
specificity) for limited properties that are valid for ::region-lines?

@region <region1_sel> {
 ::region-lines {...}
}

@region <region1_sel> {
 <region1_sel> {...}
}

In more generality, are the following two equivalent (excepting 
specificity)?

@region <region1_sel> {
 p {...}
}

@region <region1_sel> {
 <region1_sel> p {...}
}


I'm looking forward to following the progress of this module!

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Wednesday, 6 July 2011 20:01:29 UTC