Re: Exposing Fundamental Primitives (was: [css-regions] Named Flows, Elements and Box Generation)

On 10/29/13 12:14 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>On 10/29/13 11:24 AM, "L. David Baron" <dbaron@dbaron.org> wrote:
>
>>On Tuesday 2013-10-29 11:14 -0700, Tab Atkins Jr. wrote:
>>> On Mon, Oct 28, 2013 at 6:18 PM, L. David Baron <dbaron@dbaron.org>
>>>wrote:
>>> > I don't think "expose" is what regions is doing here.  This isn't a
>>> > pre-existing primitive.  Sure, you can make it a new primitive and
>>> > rebuild other things on top of it -- but that doesn't make it the
>>> > thing they were built on before, nor does it make it the right
>>> > primitive to build them on (which I don't think it is).
>>> 
>>> Well, right now we've got at least two things (multicol and paged
>>> displays) that do "flow content between separate boxes", and a bunch
>>> more planned/discussed things that are similar, such as grid-cell
>>> chaining, footnotes, etc.
>>
>>That doesn't contradict what I said, nor do I disagree with it.
>>(Same for your third paragraph.)
>>
>>> It seems like Regions is an underlying primitive here, as it exposes
>>> the "flow between boxes" ability, and the "arbitrarily move a box into
>>> another location".  I'm not sure how to expose these types of things
>>> to authors otherwise.
>>
>>I disagree with the "is an underlying primitive" statement.  You can
>>make it into one by rebuilding other things on top of it, but that
>>doesn't mean it currently is one.
>>
>>> In general, it seems like things that use those two abilities will
>>> become more common over time, rather than less.  We don't want to have
>>> to be the gatekeepers that define every new bit of functionality
>>> before authors can use it - that just means CSS continues to grow, and
>>> do it slowly, forever.  We should be exposing this or something like
>>> it, so authors can invent their own abilities and we can clean up
>>> afterwards with simpler, more efficient sugar on top of it for common
>>> things.
>>
>>Agreed, but I think the underlying primitives we expose to do that
>>should actually be more like primitives -- they shouldn't involve
>>things like implicit multi-pass layout (which isn't in the things
>>you cite that are built on top of them).
>
>Please note that multi-pass layout is only required IF there is a region
>that is sized by its content AND that region is not the last region in the
>chain. There are plenty of places for optimization in the actual
>implementation - the spec takes the conservative route and describes the
>worst-case scenario an implementation needs to support. Section 7.3
>encourages optimizations, and note 12 allows for even more complicated
>layout steps if an implementation wants to go down that path.

This thread died out, but I'd like to revive it and see if there's any
more clarity we can find here.

A higher-level feature does not necessarily need to use all of the
capabilities of a lower-level feature. One of the current characteristics
of multicol is columns of the same height and width. This allows for
easier fragmentation strategies than a scheme that lets height and width
vary. When you have a region chain with boxes of a definite width and
height, the regions processing model should be single-pass layout. CSS
Regions does not describe everything in multicol - there's no column
balancing, for instance. But you can think of column balancing as
providing a definite height input for a region chain.

When the ::column() pseudo-element is implemented, if we allow height:auto
on columns, we'll be in the situation that brought about the two-pass
layout path described in the regions processing model. So current multicol
fragmentation can be explained and exposed by a subset of region
fragmentation and CSSOM, and future extensions to multicol fragmentation
can still be explained by what we've defined in CSS Regions. I think the
same is true of overflow:fragments boxes.

If a lower-level feature has capabilities we choose not to expose in a
higher-level feature, that doesn't necessarily disqualify the lower-level
feature as a building block for the higher-level one. The extra
capabilities do need to be justified, though. I think the height:auto use
case is a reasonable justification for two-pass layout, both for basic
region chains and for future extensions to other fragmentation features.

Thanks,

Alan

Received on Monday, 4 November 2013 22:08:02 UTC