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

Hi Anton,

Thanks for your careful review, it is really helpful. Sorry for the late answer, I was out last week. I assume your comments are based on the July 1rst version, is that right?

I have included my responses/comments/questions below,  prefixed with [VH].

@alex: Anton has a question about iframe/embed/object that I think you would address best.

Cheers,
Vincent

From: Anton Prowse <prowse@moonhenge.net<mailto:prowse@moonhenge.net>>
Date: Wed, 6 Jul 2011 13:00:19 -0700
To: "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>>
Subject: [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).

[VH] Yes, that would be possible.


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.

 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.

[VH] See my response below.

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.

[VH] With the proper CSS selector, we can move either the element or just its children into 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.

[VH] It is possible if you move the children to the flow separately from the parent.

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.

[VH] In the proposed model, there is one positioned flow per container. The first sentence of 2.4.2 was intended to capture that:

# An absolutely positioned element is placed into the positioned flow of its container.

Likewise for the generated flow.

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.

[VH] Hum.. this is the section I was just quoting. As I wrote, it was intended to say there is one positioned flow per container, but you understood this differently. Could you say what gave you that understanding?

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.

[VH] In the proposed model, the container box is associated with the positioned flow and lays out the content of that flow into the appropriate containing block. It is not the containing block that takes over the flow. Note that this section is proposing consistent model for flows and explain how positioned content can be modeled with flows. It has no impact on how regions themselves work.

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?

[VH] As I mentioned above, this section proposes a unified model for content flow and containers, which is why there is this definition of normal flow.

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.

[VH] 2.1's goal is to explain what exists in CSS 2.1 (no effort was made to align the 2.1's :-) and introduce the notion of named flows by drawing a parallel with the other 'flows' that CSS has. In this model, there is a notion of container, there is a notion of flow (normal, named or positioned for example) and there is a layout that happens.

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?

[VH] Conceptually, we could imagine mutliple flows with different positioning schemes because CSS already allows that with the normal flow and the positioned flows. But with the syntax proposed, it is not possible to assign multiple named flow to a region. We are trying to always keep the behavior similar to having crafted the content so that each region actually had the desired sent of elements from the flow as children.


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.

[VH] I agree it should move up. I am thinking may be right after 2.2 ('Regions')


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.

[VH] Can you point to the definition of 'container' in CSS 2.1 you are referring to (9.2.1?) ?

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.

[VH] 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).

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.

[VH] I agree. The wording should be more generic and not restricted to elements. It should use the term pseudo-element. The section on grid layout should make that clear, but the wording should be tightened up.

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

[VH] I think this reflects the recent change in the spec. Originally, the intent was to ask that column-boxes be addressable as pseudo-elements and be allowed to be regions. However, the WG has decided to not go that way and the section was modify to just say that multi-column boxes are not addressable and therefore cannot be made regions. I did not understand what you meant by incorrect reasoning.

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.

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?

[VH] The options we considered were:

a. do not alter the containing block definition. In that case, it means that it would have been defined by the containing block of the element in the flow, which may be totally unrelated.
b. defined as in the draft.

Do you think we have other options?

   # 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!

[VH] This means that regions are 'rendered as a group' and that the 'rendered region' is then composited with the rest of the document. Regarding the float part, it means that floats defined in the parent content impact the flow in the region.

   # 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?

[VH] I will let Alex respond to this.

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.

[VH] Yes, I agree. I will change the last sentence.

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)?

[VH] Yes, that was the intent and wording is missing.

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.

[VH] Exactly.

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

[VH] Well, the @region <region1_sel> is avoiding having to redefine what the descendent selector is. Because if we said that "<region1_sel> p" selected a p that is in region_1, then we would use the descendent selector syntax and bend what a descendent is. So it 'scopes' the selectors but does not modify the selector syntax or definition.

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

[VH] Thank you very much for your careful review of the specification.

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