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

Hi Anton,

See my comments below. I have used ellipses to reduce the response size.

From:  Anton Prowse <prowse@moonhenge.net>
Date:  Tue, 12 Jul 2011 12:28:58 -0700
To:  "www-style@w3.org" <www-style@w3.org>
Cc:  Adobe Systems <vhardy@adobe.com>, Alex Mogilevsky
<alexmog@microsoft.com>
Subject:  Re: [css3-regions] Comments on Editor's Draft


[...]

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

OK, that's what I expected the answer to be.  However, whilst I agree
with (and planned to suggest) Alex's subsequent recommendation that the
child combinator (>) be used instead of the descendant combinator, even
then I'm cautious about this approach.

>>[VH] I generated confusion here because I meant to use the child
>> selector, not the descendant selector. As discussed in the other email
>> with Alex, there is a model for what it means to move the children to
>> 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).

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


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

Indeed, using your above way of thinking, this would be achieved as
follows:

#article {
        content: from-flow(article)
}
#article > * {
        flow: article
}
#elsewhere {
        flow: article
}

Note that because there is no flow-order property, whether the content
from #elsewhere comes before or after the children of #article depends
on whether #elsewhere precedes or follows #article.  This lack of
control may or may not be a serious problem depending on how important
you think the use case is.

>> [VH] So far, I have not seen a use case where a flow-order would be
>> needed, but may be it will come up.


>> [...]

>> 2.4.2 (Positioned flow) suggests otherwise, that in fact there are
>> multiple flows:
>
> 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?

No worries, my point (namely that 2.1 appears to suggest otherwise) was
missed but your answer above is exactly what I was looking for!

>> [VH] ok, good :-)

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

Sure.  I won't take these editorial issues further until the spec has
progressed to LCWD!  I just needed to get enough clarification in order
to understand the model.

>> [VH] fair enough. But for the record, your comments, editorial or not,
>> are welcome any time, even before LCWD.


[..]

>>
>> 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.
>
> Can you point to the definition of 'container' in CSS 2.1 you
> are referring to (9.2.1?) ?

Yes, 9.2.1.  Note that the definition there is specifically of a _block
container_, ie a box that contains (only) blocks(*). There is no
explicitly defined notion of other types of containers in CSS21
(although of course a table box is an example of such from CSS21).  So
the point I was making is that at some point in the future the more
general term "container block" will need to be defined.  For the time
being (since this is mainly an editorial issue) I'm just going to assume
some reasonable definition of container block for the purposes of this
spec.

(*) Or alternatively, ironically enough, a block container can be a box
that doesn't contain *any* blocks.  I was never too happy with the
"block container" terminology!

>> [VH] Actually, I would really like to try and nail this type of issue
>> early.
>> The flow property is defined to apply to any element and this is
>> inconsistent
>> with the definition of region in 2.2 and 2.1. The core idea is that the
>> content of
>> the element is coming from a flow, instead of the children, and that
>> the content is
>> laid out like other (children) content would normally be.
>> I'll work on this with Alex and I'll rework 2.1 and 2.2.


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


>> [VH] Actually, there are two ways to look at it (I think) and
>> initially, I had the same
>> view you present. An absolutely positioned element would go into the
>> 'positioned' flow of
>> the element defining the containing block. However, Steve made the
>> argument that we could also
>> model it where there is a positioned flow is all container elements and
>> that they all position into
>> their containing block. So for example, if you have:

>> <div style="position: absolute" id="containingBlockElement">
>>      <div id="a"><p id="p1" style="position: absolute" /></div>
>>      <div id="b"><p id="p2" style="position: absolute" /></div>
>> </div>

>> They p1 is in the positioned flow of "a", p2 is in the positioned flow
>> of "b" and both "a" and "b"
>> layout their positioned element relative to the box of
>> "containingBlockElement".
>>
>> I do not have strong feelings for how this gets modeled. I can see
>> either ways of looking at it I think.


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

Hmm, actually I was already assuming that "element" encompassed
pseudo-elements (as per CSS21).  What I was really querying was whether
it were possible or useful to devise a way for a flow to be associated
with a box which didn't arise directly from an element (eg an anonymous
block box).  Of course, we would need to come up with a way of assigning
a flow to that box.

>> [VH] Ah, I see. I do not have a use case for this, so I think we are ok
>> without it.


>> [...]

> I did not understand what you meant by incorrect reasoning.

The reason given in 5.2.2 for why a column cannot be a region is that
css3-multicol does not specify a selector for column boxes.  However,
2.2 defines a region to be an element that generates a block container
box, and so, in fact, the technically correct reason is that a column
box is not generated by an element.  (The fact that there is no selector
is not directly relevant, although of course that fact is precisely what
lies behind your chosen definition of region in the first place.)  This
is just an minor editorial detail, to be revised in some future WD.

>> [VH] ok.


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

No.  But I think (a) also has use cases.  On the other hand, I think I
agree with your implicit argument that in the most common cases authors
would want the containing block to be established by the region
containing the abspos; possibly it would be annoying to have to set
position:relative on the region every time just to achieve that.

>> [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.

Would you or Alex mind shedding some light on this?

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


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

> Regarding the float part, it means that floats defined in the
> parent content impact the flow in the region.

So you mean that normal CSS21 behaviour is observed in the vicinity of
the float; for example, the float doesn't impact the margin box of the
region, but the region's inline content flows around the sides of the
float.  That is, the second clause of the quoted sentence is redundant
(and somewhat confusing!).  I'm guessing that the point you were really
trying to make is that a region does not necessarily establish a new
block formatting context.

>> [VH] There are two different issues, let's look at each in order.
>>
>> 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.
>>
>> 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?


>> 3.6 (The @region rule):

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

Ah yes, I follow you.  The two rule sets that make up the latter pair
are certainly not equivalent, for example, since the first matches a 'p'
that's found in region X whilst the second only matches a 'p' that's
found in region X and which is also a document descendant of the element
that establishes region X.

>> [VH] yes.

Thanks again for your thorough comments, keep them coming! :-)

Cheers,
Vincent

Received on Thursday, 14 July 2011 20:45:28 UTC