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

Hi Anton,

From: Anton Prowse <prowse@moonhenge.net<mailto:prowse@moonhenge.net>>
Date: Sat, 23 Jul 2011 14:30:29 -0700
To: "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>>
Cc: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>, Alex Mogilevsky <alexmog@microsoft.com<mailto:alexmog@microsoft.com>>
Subject: 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.

>> [VH] ok.

[...]


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

> [VH] Yes, exactly.

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.

>> [VH] I need to scratch my head about this a little more.


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

>> [VH] ok.


# 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),


>> [VH] Yes, if you mean that the existing CSS equivalent of the above example would behave as I was describing.

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.

>> [VH] We felt that there was a need to explain, as in the example above, that the floats affect flow content that has been positioned in region but do not affect flow content before it is positioned. I guess that may be an overkill because it is pretty obvious since the flow is not visually formatted before it is laid out in regions. Still, I would propose having something on that topic (see below).

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

>> [VH] What about:

"Regions create a new stacking context. Floats or other exclusions (reference to the CSS Floats/Exclusions spec) impact the content laid out in regions."

Cheers,
Vincent