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

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.

Thanks,

Alan

Received on Tuesday, 29 October 2013 19:15:29 UTC