RE: [css3-floats][css3-exclusions] priorities and alternatives

± From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of L. David Baron
± Sent: Monday, August 01, 2011 4:00 PM
± 
± I see work on css3-floats [1] / css3-exclusions as diverting energy away from the layout problems that we 
± urgently need to address.

I certainly agree that UI should be high priority. I am not sure how to compare making CSS capable of representing high end document layout (or just common book layout) - where CSS is a prominent language for documents, yet not much substantially new has changed there in last 10 years...

± I also think css3-floats is taking the wrong approach to what it is
± doing:  it is building on concepts (such as absolute positioning) that are already known to be 
± problematic in terms of producing layouts that don't respond well to changes in device size and other 
± device characteristics.  I think many of the examples highlighted as things that can be done with this 
± specification are things that it won't do a good job at when faced with different devices.  For example, 
± placing pull-quotes in the middle of pages using absolute positioning will lead, after reformatting for a 
± different device, to some of those pull-quotes overlapping or flowing around each other on the same page.

What we refer to as "css3 floats" is a combination of several features (exclusions, position and to some degree regions). We have initially referred to the combined functionality as "positioned floats" -- misleading naming (I am glad we are moving away from it), which incorrectly suggests that new float behavior is built on top of absolute positioning.

The new spec drafts are actually structured in a way that allows for clean definition of some parts of the functionality while resolution of hard issues is happening at its own pace:

* CSS3 Exclusions define how content wraps around shapes. That works the same way regardless of how those shapes got to wherever they are. 
* CSS3 Positioning adds a small number of new ways to position things (currently only "position:page"). Those doesn't need to apply to floats, it is an extension to positioning anything.
* CSS3 Floats (not written yet) will ultimately target more advanced positioning options (including processing model and float collisions). 

Specifically Exclusions define wrapping behavior that will work with or without absolute positioning. If/when we have float placement that is more adaptive, that will produce better experience, Exclusions will not need to add anything to work with it.

One approach that would be very different is to have exclusions apply only to positioning schemes that were not possible before (and not apply at all to absolute). I think that is what you are trying to promote. 

It's been on my mind for long time too and here is why I don’t think it helps much:

* any new positioning scheme must include "top of current page". Making that happen involves solving hard problems of circular dependencies, potentially multiple passes and optimizations to avoid horrible performance loss
* any new positioning scheme should be available for out-of-flow (just like absolute) - if there is a use case for a float somewhere, there will be a use case for a transparent overlay at the same spot.
* if the new scheme is completely unrelated to existing positioning, we will have yet another way to do what absolute positioning does, with large overlap.
* at the same time current positioning model is well understood, including hard cases in pagination - a lot of "model completeness" tax has been paid already.

Of course I can see advantages in favoring a new model too:

* new scheme can make some difficult corner cases impossible (such as a float at "bottom:0" in a shrink-to-fit container), it can also forbid unneeded use patterns that are very bad for performance (position to previous pages)
* new scheme can discourage non-adaptive positioning

On the balance, I think it is worth considering something new, when we'll see it we'll know if it's good. I believe however that taking advantage of existing positioning for breadth of known use cases, and *adding* fine control for "center on page" or "adjust with column" is more productive...

± During the meeting in Seattle, I agreed (under some pressure) to describe an alternative to css3-floats 
± that I would prefer that would address its use cases described in [2] (though I'm far from convinced of 
± the need for use case #2, and I don't address it).
± 
± The alternative I would like would be the combination of:
± 
±  * the 'wrap-shape', 'wrap-image', 'wrap-margin', and
±    'wrap-padding' features from css3-floats (or something like them)
± 
±  * a new property for additional float placement types similar to
±    the 'wrap-type' from css3-floats or the float types from
±    css3-gcpm [3], which allows:
±     * floats being placed some percentage of the way across their
±       container, with flow on both sides of them, but otherwise
±       similar to the current folat model
±     * floats at or near the beginning of a multi-column element
±       being placed on a column boundary (both sides of which have
±       their contents *after* the float)

These are good requirements/use cases. Let's explore how it's done in our current model and can we do better.

In addition to requirements, I would really like to see a list of specific problems with CSS2.1 positioning that you want to avoid. I think I know what they are, but having a list would help validate each approach.

± 
±  * a general mechanism for content reordering to address cases where
±    the floats are at a point in the content that doesn't match where
±    they ought to be positioned

I can read this in two ways. It is possible to optimize layout for backward positioned floats (it's possible to find and exactly place some of them if they don't have 'auto' position). Or it could mean that use of 'auto' is not allowed or something to that effect - that I think would take away a lot of power of anchoring figures.

± (Though they're not mentioned in the use cases list, I did here some mention of page floats as a use case 
± -- i.e., floats to the top or bottom of a page.  If that's a use case, I think the correct way to address 
± it is via a page float mechanism designed for exactly that
± -- figures that are pulled out of the text and float to the top or bottom of an appropriate page, with 
± collision handling that pushes them to the next page.)

I really wish we could define collision resolution options together with exclusions. It will be coming, getting to a complete floats model. It is generally understood what it can be like though, so we can make good progress on non-colliding floats first.

± That said, as I said above, I think this is lower priority than user interface layout features.

No reason to argue with that. We'll keep working on both though, because we want to...

Alex

Received on Wednesday, 3 August 2011 18:20:45 UTC