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

On Nov 4, 2013 5:08 PM, "Alan Stearns" <stearns@adobe.com> wrote:
>
> 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
>
Alan's proposals still seem very reasonable especially if you could box in
and limit a v1 a bit.. I'm still kind of hoping that we can move forward on
_something_ in this space - if not this, how about a fairly concrete
alternative?  Any chance this topic can be cage matched, er, discussed at
tpac?