RE: [css3-regions] content:flow-from(flow) and ::before/::after

Hi Vincent,

I think we may be again looking at two different kind of regions (linked and not linked), and each kind may call for a different preference in setting content.

As generated content is currently defined, before, after are inserted inside the element, and element's own content is replaced with value of 'content' property:

With style like this

div::before { float:right; content:before }

div::after { float:left; content:after }

div { content:"replacement content"; }

a div with any content

<div>

   ...anything...

</div>

Is treated as if it had this

<div>

   <before>

          before

   </before>

   Replacement content

   <after>

          after

   </after>

</div>

Then the element has to apply its normal processing model and layout to render content as if it was its own. In this example made ':before' a right float and ':after' a left float just for fun, but is doesn't create any unusual complications, result will be same as with same properties on content.

Now, if we want to do the same with a region, we'll get two cases:


1)      Singular region

div::before { float:right; content:before }

div::after { float:left; content:after }

div { height:auto; content:flow-from(flow1); }

                it would be reasonable to expect that the flow content simply replaces the original content and then processed together with before/after


2)      Linked region

div::before { float:right; content:before }

div::after { float:left; content:after }

div { width:100px; height:100px; content:flow-from(flow1); }



here,

*         concatenating before/after with flow content is not possible,

*         before/after need to be ignored (as in your option 4),

*         or flow container needs to become an anonymous block that is laid out with before/after.

Any of the above is possible to define, but it's complicated (mixing GC with flow seems the most complicated).

"option 4" seems to be the most feasible, although the effect of GC properties can get funky:


*         if content is set to "flow-from()", :before/:after have no effect

or if we wanted the singular region to still take GC

*         if content is set to "flow-from()" and 'height' is not 'auto', :before/:after have no effect

that really sounds like a property that is misused for purely syntax purposes...

I still favor a separate 'flow-from' property, with a meaning that is notably different from GC when applied to linked regions.

Down side is that the use case (1) above won't work... but we have already stated an intent to add a more universal mechanism to create block pseudo elements - as in grid cells or slots. That seems to be a more promising approach here too...

Alex


From: Vincent Hardy [mailto:vhardy@adobe.com]
Sent: Monday, August 01, 2011 1:41 PM
To: Alex Mogilevsky; www-style@w3.org
Subject: Re: [css3-regions] content:flow-from(flow) and ::before/::after

Hi Alex,

My comments below.

From: Alex Mogilevsky <alexmog@microsoft.com<mailto:alexmog@microsoft.com>>
Date: Tue, 26 Jul 2011 12:18:55 -0700
To: "www-style@w3.org<mailto:www-style@w3.org>" <www-style@w3.org<mailto:www-style@w3.org>>
Subject: [css3-regions] content:flow-from(flow) and ::before/::after

I think there is a problem with using "content:flow-from()" to put named flow into a region.

Whatever property is used for "flow-from", it is actually doing two things:

1)      Makes the element a region

2)      Identify the named flow to flow from.
If there was "display-inside:region" it could be used as an explicit trigger. We set display type implicitly but the result is same - element's nature changes when  it becomes a region.

Now, the meaning of 'content' is literally placing content inside an element, not changing the element otherwise.

Consider this:

#region { content:flow-from(foo); }
#region::before { content:"before")
#region::after { content:"after")

The flow "foo" may start at this region, or it may continue from elsewhere (possibly interrupted in the middle of an element, inside a table, or in a thick bottom border).

What is supposed to happen?

I think the generated content spec is very clear about it. It should have exactly same result as actually placing the pseudo-elements in content:

                <div id="region">
                                <span>before</span>
                                ... portion of named flow that fits in this region ...
                                <span>after</span>
                </div>

Now, the element is a region, which means that it completely disregards its own content and replaces it with the named flow:

                <div id="region">
                                ... portion of named flow that fits in this region ...
                </div>

that would be the effect when set on a regular dif. However if the div is a flexbox, "content:flow-from" will be ignored and befor+after will merge into one anonymous flex item:

                <div id="region" style="display:flexbox">
                                <span>before</span>
                                <span>after</span>
                </div>

This makes the definition of "content:flow-from" self-contradictory, or at least underderfined.

Ways to fix it:

1)      Define that "content:flow-from" (when it applies) discards "::before" and "::after"

2)      Define that "content:flow-from" doesn't change the parent element but instead inserts an anonymous region block

3)      Use a different property - "flow-from". It doesn't need to have priority over 'content' because dom content of a regin is  ignored


>> [VH] I think there is another way to look at it and have another option:

4) ::before and ::after address a pseudo-element that is distinct from the element itself. Setting 'content:flow-from()' on the element does not impact the element's pseudo-element ::before and ::after just like removing all the children from an element using the DOM API will not impact the element's ::before and ::after.

While I agree that content:flow-from() differs from the other values for content in that it grabs a fragment from the flow and not a specific content set, I suggest we stick with the resolution from the group and use option 4). What do you think?

Vincent