Re: [css3-gcpm] How to create running elements

2009/2/11 Tab Atkins Jr. <jackalmage@gmail.com>

> On Tue, Feb 10, 2009 at 5:22 PM, Håkon Wium Lie <howcome@opera.com> wrote:
> >
> > Giovanni Campagna wrote:
> >
> >  > >  > As I said, I don't think that supporting "move-to: <identifier>
> <keyword>" +
> >  > >  > "content: pending(<identifier>)" (one property, two keywords, one
> functional
> >  > >  > notation added to existing property) is much more costly than
> "position:
> >  > >  > running(<identifier>)", "content: element(<identifier>)", "float:
> >  > >  > to(<identifier>)", "content: from(<identifier>)" (four addition
> to existing
> >  > >  > properties). In addition, you have two namespaces, that means two
> hash
> >  > >  > tables (instead of one) holding the identifiers and consuming
> memory.
> >  > >
> >  > > What do implementors prefer?
> >  > >
> >  > I don't know. Let's wait for an implementor feedback.
> >
> > I discussed this with an implemntor today, Michael Day of YesLogic. He
> > suggested using the 'float' property. So, it seems we have three
> > proposals for how to express running elements: 'float', 'position' and
> > 'move-to'.
> >
> > Let's look at a use case: how to move the 'title' element into a
> > running header. GCPM currently suggests (A):
> >
> >  title { position: running(header) }
> >  @page { @top-center { content: element(header) }}
> >
> > There is also a proposal to introduce a new property (B):
> >
> >  title { move-to: header running }
> >  @page { @top-center { content: pending(header) }}
> >
> > We cold use 'float' instead of 'position' (C):
> >
> >  title { float: running(header) }
> >  @page { @top-center { content: element(header) }}
> >
> > Or, perhaps, come up with new functional names that work better with
> > 'float' (D):
> >
> >  title { float: to(header) }
> >  @page { @top-center { content: running(header) }}
> >
> > One difference between (D) and the other examples is that the
> > recipient flags that the element should be running (as opposed to just
> > shown once). I think this is a better place to do it.
> >
> > I think I have a slight preference for D. As stated before, I don't
> > like to introduce new properties unless necessary and I don't think
> > it's necessary in this case.
> >
> > What do other people think?
>
> I've refamiliarized myself with this issue, reading all the modules I
> know of that deal with moving content around (GCPM, GRCM, Template
> Layout).  My conclusion is: I don't care what property we use.  ^_^
>
> What I want is simply for all the methods of moving elements around to
> harmonize.  We have running elements using one method (position with a
> running() value), named flows using another (float with a to() value),
> footnotes using yet another (float with a 'footnote' value), GRCM's
> content moving using the move-to property, and template layout with
> single-letter position values.
>
> This is ridiculous.  I think it is more than possible for us to pull
> all of these together (1) without losing any power and (2) without
> gaining significant complexity.
>
> The concept of 'named flows' seems to be what we want.  You tell an
> element to move into a named flow, and you pull it out later.  This is
> a simple concept, and it allows for specialization at the correct
> place - the destination.
>
> So, proposal.  We embrace named flows.  I don't care what property we
> use to activate this, but I'm partial to position (float really
> shouldn't be overloaded any further...).  Use a functional value to
> eliminate ambiguity, perhaps "position: into(name-of-flow)".  A named
> flow works exactly like a FIFO - you shove elements in one end, and
> they come out the other end.  You can provide multiple names here, and
> the element gets placed into all of them (this becomes important
> later).

Am I the only one who cares that position is referenced in many CSS modules,
that would instantly break as soon as we add this new position value? Or
should all elements in named flows treated as positioned elements?
Or instead can position become a shorthand for position-model: static |
relative | absolute | fixed and position-flow: [flow(<identifier>) |
slot(<identifier>)]+ like what they had to do with display: => display-model
+ display-role in the Template Layout module and overflow: => overflow-x +
overflow-y => overflow-style-x + overflow-style-y + overflow-policy-x +
overflow-policy-y in the Box Model and Marquee modules
(better to have two syntaxes for template layout slots and named flows,
although they may seem similar)

>
> At the destination, we use the content property, as this at least is a
> consistent point between the various mechanisms.  GCPM's running()
> value had the right idea with the ability to specify what you want out
> of the flow.  This will let us extend the property easily as we come
> across new situations.
>
> Let's call it "content: flow()".  Takes one or more arguments.  The
> first is the name of a named flow, the rest are specifiers.  (This may
> not end up being necessary, and we can simplify it to just 2
> arguments, with the second one being optional).
>
> By default, with no specifiers, a content:flow() grabs the entire
> value of the named flow so far, emptying the flow out.
>
> The specifiers are as follows:
> running - specifies that this content pull does *not* remove the
> element(s) from the named flow.  They remain to be used by later
> content pulls.
>
> remove - the default, and the opposite of running.  The element(s) are
> removed from the flow by the content pull.
>
> single - specifies that you want only a single element from the flow,
> rather than the entire thing.
>
> multiple - the default, and the opposite of single.  The content pull
> grabs the entire contents of the flow.
>
> start-on-page, first-on-page, last-on-page, first-on-page-except -
> these provide similar functionality to the corresponding values in
> GCPM.  They target segments of a flow that have occurred within the
> same page.  Unless otherwise specified, whenever these are used the
> running and single specifiers are also in effect.
>

Is it like flow(<ident>[, <specifier>]*), that is any number of specifiers,
any order, any combination?


>
> This accomplishes what currently exists in named flows, running
> elements, and GRCM's move-to.  You have to be able to push an element
> into multiple flows to ensure that any normal flow() behavior (just
> moving elements around on a page) doesn't interfere with page-based
> flow()s.  What's more, it becomes *very* necessary if we want to use
> this for footnotes and endnotes, possibly at the same time!  Just push
> an element into the footnote flow, and empty it out in the footnote
> area at the bottom of the page.  At the same time, push it into the
> endnote flow, and empty that out at the end, so you have references on
> the page and an index of all references.
>
> Thoughts?  Too complex?  Doesn't hit necessary cases?
>
> ~TJ
>

I think it is as complex as the current model, but it finally unifies a lot
of different thoughts and proposals. I like it!

Giovanni