Re: [css3-regions] writing mode and directionality for flows

Hi David, Alex,

On 8/15/11 1:02 PM, "David Hyatt" <hyatt@apple.com> wrote:

>On Aug 14, 2011, at 2:09 PM, Alex Mogilevsky wrote:
>
>> Considering that in paged media first page is the ICB, first region
>>will be ICB too (right?), then it would be reasonable to expect that
>>root writing mode is that of the first region element.
>> 
>
>I assume it would be something like that. I do wonder how fixed
>positioned elements placed into a flow are supposed to work though. Do
>they get sliced up into the regions, or should we just say that
>-webkit-flow does not apply to fixed positioned elements? I'm inclined to
>just say that -webkit-flow doesn't apply to fixed positioning.

As I pointed out in my previous email, our current thinking is to align
with http://www.w3.org/TR/css3-page/#page-box-page-rule. So the
'flow-into' property (this is the new name btw, as per the last F2F),
would apply to absolutely positioned elements and they would be positioned
relative to the first region box that would be the initial containing
block for the flow.

>
>I think we may need to formalize the notion of a containing block that
>represents the flow itself before it's sliced up into all the regions.
>Then the portion of that strip that is placed into the first region would
>be the "ICB" for absolute positioned descendants, etc.
>
>Once you have a formal notion of this single "flow thread" that goes
>through all the regions and that is itself a block, then I think some
>definitions become simpler/more obvious. For example you can see clearly
>that you desire one default pagination direction, i.e., one single way of
>making the slices in the strip, either top to bottom in horizontal-tb,
>right to left in vertical-rl, or left to right in vertical-lr.

There was a discussion about this recently (see [1]) where we ended up
agreeing to not formalize it this way because it seemed to be an
implementation issue, not a spec. issue. Would you agree?

>
>I also think if we're willing to give up certain features, e.g., variable
>width paginated blocks, we could come up with simpler ways to handle
>variable width regions, such as just supporting it on lines rather than
>on blocksŠ. for example by imagining that narrower regions have synthetic
>floats introduced along their edges that lines would avoid. This would
>allow you to still have the notion of a single flow thread that has the
>same width across all regions, and lines would fit within narrower
>regions because of these synthetic floats we put in.  Lots of stuff would
>still work (lines would look good, text-align would work, etc.), but then
>some things would not, e.g., expecting a block with a border to actually
>have different widths if paginated across a region.

This is quite a fundamental change to what we have currently. And the
behavior would be surprising for borders, even for blocks that are not
split across regions, because if we have say, a right float to adjust the
region size and there is a border on a paragraph that fits in the region,
the content will flow to the size of the region but the border (assuming
the content is larger) will not show on the right edge (if clipped) or
continue beyond the region to the right (if we were to not clip).

While I understand this may simplify our implementation, the user
behavior, for borders, seems difficult to justify.

It seems to me that if we are going to do paged media where pages may have
different sizes or orientation, we will have to address the problem of
splitting blocks across regions of different widths there.

Kind regards,
Vincent

[1] Thread ending at:
http://lists.w3.org/Archives/Public/www-style/2011Aug/0161.html

Received on Tuesday, 16 August 2011 20:40:05 UTC