RE: [css-regions] Comments

It is hard to tell who said what in this thread… I can comment though that I too is not a fan of the idea of using z-order to make decisions about text wrap.

This needs to be considered in the context of where these wrap decisions need to be made. I am assuming the main reason for wrapping is floats or page floats (even if simply rectangular the problem is the same).

We will eventually (I hope soon) define page floats in more detail, what positioning is applicable to them and what flows they are allowed to affect. At that point I think the answer to this question will be obvious. And before that I am not sure we have a problem, or do we?

Alex

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Brad Kemper
Sent: Thursday, March 10, 2011 6:16 PM
To: David Hyatt
Cc: robert@ocallahan.org; Jacob Refstrup; www-style@w3.org; agourdol@adobe.com
Subject: Re: [css-regions] Comments

On Mar 10, 2011, at 3:08 PM, David Hyatt <hyatt@apple.com<mailto:hyatt@apple.com>> wrote:

On Mar 9, 2011, at 9:58 PM, Robert O'Callahan wrote:


On Thu, Mar 10, 2011 at 12:30 PM, Jacob Refstrup <jrefstrup@apple.com<mailto:jrefstrup@apple.com>> wrote:
When an box is determining it's text-wrap path it will use it's interior wrap path but also consider any exterior wrap path for boxes that are in front of it in Z-order (within the current stacking context).

Currently in CSS z-order does not affect layout, and in Gecko we don't determine z-order until paint time, so I would prefer not to see any new requirement that z-order affect layout. Maybe you could use document order instead?

There are times when a drop cap or illumination or graphic to start a paragraph would want to be positioned so that it juts up into a previous paragraph to wrap around it a bit (doable in inDesign or QuarkXpress). So xyz positioning with wrapping would be pretty ideal, and document order not so much.

We were attempting to avoid introducing new properties for stacking and ordering, but if z-index can't be used, it may be unavoidable.

There are two features that we wanted to support here.  The first is the ability to choke the propagation of the exterior wrap paths outwards.

Do you mean that there would be some distance between the path/alpha edge and items that wrap around it? Could we use 'margin' for that (a margin that followed the path)? Or are you talking about something else?


 We had the thought that using stacking contexts might be a convenient way to do this.  The second feature was an easy way of determining whether you are affected by an exterior wrap.  We thought z-order would be convenient.

I think so too. Perhaps one region with exterior wrap could be pushed away from another region with exterior wrap if they are on the different z-indexes, Otherwise union them into one region wrap shape if they are on the same z-index.

I do think document order might be an acceptable solution, but we'd still need a solution for not propagating wraps out through ancestors.  This could be done with a new CSS property if stacking contexts are not considered acceptable,

Are stacking contexts off the table? How strongly does ROC feel about that?


but I'd love to have a heuristic for doing this (in the same way we just have default rules for margins propagating out for collapse).  We might be able to do something simple like state that if you have any normal flow content that exterior wrap paths don't propagate outwards.  This allows positioned images with wraps to be grouped inside another positioned containing block while still propagating the wraps outwards.

dave
(hyatt@apple.com<mailto:hyatt@apple.com>)