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

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).

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.


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

Received on Wednesday, 11 February 2009 05:24:55 UTC