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

On 14/07/2011 15:44, Vincent Hardy wrote:
> On 12/07/2011 14:28, Anton Prowse wrote:
>> On 11/07/2011 20:46, Vincent Hardy wrote:
>>> On 6 Jul 2011 13:00:19 -0700 Anton Prowse wrote:
>>>> 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.
>>> With the proper CSS selector, we can move either the element
>>> or just its children into the flow.

>> The first thing that came to mind was the issue of specificity. If a
>> child #C of #B were also placed into a named flow, we'd need to be
>> careful to avoid that the rule for "#B > *" override the rule for the
>> child:
>> Bad:
>> #C {flow: sidebar}
>> #B > * {flow: article}
>> Good:
>> #B > * {flow: article}
>> #C {flow: sidebar}
>> Perhaps this is an acceptable and expected situation, but both my
>> authoring experience and my language design instinct make me uneasy
>> about using things like "> *". It feels... kludgy (and indeed only works
>> in this case because you've explicitly defined the model so that named
>> flows are populated in document tree order).
> Yes, the can be surprises with specificity, but I think this is
> common with the rest of CSS. As you say, there is a model for moving
> things to named flows so if a rule does apply (the one with the
> higher specificity), then we know what happens. I think authoring
> guidelines  may help having fewer surprises.

I would like to explore the idea of introducing some sort of modifier 
which would say whether its the whole element or just the element's 
children which get added to the flow.  (This would bypass the 
specificity problem.)  Happily, Alex raised precisely that approach in a 
later post, so I'll follow up there.

>>>> 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.
>>> The proposed model is that the flow is attached to the
>>> container element which lays out its positioned flow into the
>>> containing block, as per the CSS 2.1 definition of containing block
>>> (10.1).
>> OK, so I think this means that the container of interest for an abspos
>> element is the box which establishes the containing block for the
>> abspos. That container then lays out its positioned flow into said
>> containing block (which is a rectangle based on the dimensions of the
>> container's own box model components).
> Actually, there are two ways to look at it
> [...]
> I do not have strong feelings for how this gets modeled. I can see
> either ways of looking at it I think.

Indeed.  OK, I'll leave it to you to mull over!

>>>> # 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.
> The spirit of this is to have a simple model for how margins and
> paddings apply and collapse because they find themselves in a block. If
> all the content in the flow is inline, then it also provides a model for
> the layout of the flow (again, a single block) is laid out across the
> regions.

I think I was thrown off by your use of the word "spans".  If I 
understand you correctly, you don't mean _visually_ spans the regions; 
rather you mean an anonymous block wrapper that breaks into multiple 
anonymous block wrappers, one inside of each region to which the flow is 

I'm still not sure that I understand the need for it though.

<div id="region-1" style="content:flow-from(foo)"></div>
<div id="region-2" style="content:flow-from(foo)"></div>
<span style="flow:foo">I flow into multiple regions</span>

Here, the inline content flows into both regions, just as if the mark-up 
had been:

<div id="region-1""><span>I flow into </span></div>
<div id="region-2"><span>multiple regions</span></div>

The container forming the region already takes responsibility for 
generating anonymous block boxes if necessary, since anything that can 
be achieved using CSS Regions could also be achieved using different 
mark-up (such as above) so any awkward case (eg loose inline content 
sitting inside tables) should already have well-defined behaviour in CSS 
(eg table fix-up algorithm).

I didn't understand your reference to margin and padding, but the issue 
of margin collapsing is an interesting one.  Do we need regions to 
necessarily establish a block formatting context?  I would suggest not, 
and that margins coming from a named flow should potentially collapse 
(under normal CSS21 rules) with the region's own margins (just as if the 
contents of the flow were the actual contents of the region element). 
Again, I don't see how the anonymous block helps here.

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

> For the stacking context, regions bring something that is novel. An
> element may be split across multiple regions and these regions may
> be made to overlap. So we can get in situations where the fragments
> of the element can overlap each other. The element has a single
> z-index, and the question becomes how do we decide in which order the
> fragments are rendered? We could have decided to use the
> 'content-order' of the region the fragment falls into. However,
> making the region create a new stacking context gets us back to a
> model where an element never overlaps itself. So this explains the
> first part about stacking context.

Indeed, the painting model is interesting in the case of regions. Making 
each region form a stacking context certainly avoids some difficult spec 
work (eg if the content-order of regions that don't form stacking 
contexts is different from their document order, the overlapping of the 
flow content that they contain might not correspond to how the region 
boxes themselves overlap).

>>>> # Regions [...] 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 the floats, it may be suprefluous to specify that the floats
> impact the content of the regions like they would for regular other
> region siblings.
> The statement was trying to avoid confusion in a case like this:
> <style>
>          #region1, #region2 {
>                  content: from-flow(data_flow);
>          }
>          #data {
>                  flow: data_flow;
>          }
> </style>
> <div id="container">
>          <div id="float1"></div>
>          <div id="region1"></div>
>          <div id="region2"></div>
> </div>
> <div id="float2"></div>
> <div id="data">
>          <p>This paragraph is affected by float1</p>
> </div>
> In this scenario, 'float1' would impact the content of region1 and
> region2, but 'float2' would not impact the content of 'data' (because
> it is flowed into region1 and region2). Does that clarify the
> wording?

It clarifies what you intend (namely, existing CSS behaviour), but it 
doesn't clarify the wording!  I think you should just drop the second 
clause, since it really is superfluous (and to me it raises doubts 
rather than allays them).  If CSS21 or whichever float spec supercedes 
it fails to adequately explain when a float impacts content that would 
be flowed next to it (and CSS21 does indeed try to define "next to" 
quite carefully) then that should be fixed in those relevant specs.

If we must say something in this spec, then I'd definitely prefer going 
with the word "impacts" rather than "inherits".

Anton Prowse

Received on Saturday, 23 July 2011 21:31:06 UTC