Re: [css3-regions] flow-into: <ident> content-only

On 4/8/13 11:52 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Mon, Apr 8, 2013 at 10:54 AM, Rossen Atanassov
><Rossen.Atanassov@microsoft.com> wrote:
>> As specified the current 'flow-into' property takes an element out of
>>its flow and places it into a flow with a given 'ident'. However, there
>>are use cases where the element is not needed as part of the redirected
>>flow but its content only. I'm proposing that we achieve this by
>>extending the current '<ident>' value with an additional, conditional
>>'content-only' value. In other words, the 'flow-into' property values
>>will be changed to:  [<ident> content-only?] | none | inherit.
>>
>> One more aspect which is worth nothing here is that keeping the
>>behavior mutually exclusive will result in less confusion - you either
>>get the element or its content. Otherwise I can see cases where the
>>element is placed in a flow A and then a different rule places its
>>content into a flow B... would flow A have the element only or its
>>content duplicated as well etc..?
>
>Alternately, rather than special-casing Regions here, we can just use
>the "display-box: contents" value in the Display draft.  Same effect,
>but more general.
>
>~TJ

The only problem with display-box:contents is that you're throwing away
the element's box. One of the use cases I'm thinking of for a content-only
mode is to use the element's box as a region in that flow's region chain.
It's a bit easier to explain if I change what Rossen proposed to a
separate flow-content-into property (there is another reason I think these
should cascade separately that I'll get into farther down).

Say we have a new property called flow-content-into with an initial value
of none, and we add a new initial 'auto' value to flow-from which computes
based on the computed value of flow-content-into. Now you can style an
element like this:

#an-element {
  flow-content-into: named-flow;
}

And absolutely nothing changes (the element is a region for the named flow
consisting of its contents). Why would you want to do this? Well, now you
have a named flow and you can use 'flow-from:named-flow' on other boxes to
add regions to the region chain. And if you had two or more elements that
you wanted to chain together, you could use:

.some-content-elements {
  flow-content-into: joined-flow;
}

This would create a region chain consisting of all of the elements
matching .some-content-elements, with their concatenated contents flowing
through the chain. No extra boxes would need to be defined.

This can also dovetail nicely with overflow:fragments. You can consider an
overflow:fragments element as creating a region chain for an 'anonymous'
named flow consisting of its contents. This works well for some cases
where all of the fragment boxes can be children of the same parent, but if
you wanted to add a box somewhere else in the document's structure, you
could use this new property to give the flow a name, and then use
flow-from somewhere else:

#overflow-fragments-element {
  overflow: fragments;
  flow-content-into: fragmented-flow;
}
#some-other-box {
  flow-from: fragmented-flow;
}

Lastly, the reason I think flow-into and flow-content-into should be
different properties is that I might want to create a nested region
context. In order to do this while using the content elements' boxes, I
need a way of expressing this:

.inner-region {
  flow-into: outer-flow;
  flow-contents-into: inner-flow;
}

This would create a region chain out of inner-region elements who would
house their inner-flow content, but the regions are placed in an
outer-flow fragmentation context.

Thanks,

Alan

Received on Monday, 8 April 2013 19:48:06 UTC