Re: [css-gcpm] String-set issues

Dave Cramer wrote:

 > >  >  3. 'string-set' only gets the text of the element. I would think
 > >  >  there are times when it would be useful to get all the content
 > >  >  nodes, including links, bolds, small pictures, spans with class
 > >  >  names, etc.
 > >
 > > Yes, this is what running elements are for.
 > >
 > >    https://books.spec.whatwg.org/#running-elements
 > 
 > Running elements are limited in that they only move elements, rather
 > than (possibly) copy them. In many cases this would require duplicate
 > markup.

Yes. Duplicate markup isn't ideal. However, for running headers -- where
elements tends to be small -- it's not that big of an issue. Copying
elements is nice, but it raises some concerns.

I've sketched a solution here:

  https://books.spec.whatwg.org/#placement-policy
 
 > I've found at least seven proposals for moving document content into
 > page margin boxes (here with ultra-minimal examples)
 > 
 > A. string-set and string(), which as we've mentioned are implemented
 > by Prince and AntennaHouse, and have been in GCPM3 forever:
 > 
 > h1 { string-set: foo content() }
 > @top { content: string(foo) }
 >
 > 
 > B.  Running elements, which have been implemented by Prince (not sure about AH):
 > 
 > h1 { position: running(foo) }
 > @top { content: element(foo) }

Also supported in AntennaHouse, here's a test document with renditions:

  https://books.spec.whatwg.org/#running-elements

 > C.  Another syntax proposed by Bert Bos:
 > 
 > h1 { running: foo }
 > h1:running { /* format copied element independent of original */ }
 > @top { content: element(foo) }
 > 
 > 
 > D.  flow, which has also been implemented by Prince:
 > 
 > h1 { flow: static(foo) }
 > @top { content: flow(foo) }
 > 
 > 
 > E.  Brad Kemper's proposal from this thread:
 > 
 > h1 { copy-into: foo }
 > @top { content: foo }
 > 
 > 
 > F.  GCPM4 proposal using CSS Regions:
 > 
 > h1 { flow-into: foo; flow-policy: persist }
 > @top { flow-from: foo }
 > 
 > Some of these proposals, like running elements and flow, don't support
 > copying. I think a minimal set of requirements is
 > 
 > [1] Retain internal structure of element (like italic inside head, or MathML)
 > [2] Avoid duplicate markup
 > [3] Provide mechanism for inserting commonly-used non-document
 > content, like dates and filenames

The env() function did dates and URLs:

   http://www.w3.org/TR/2010/WD-css3-gcpm-20100608/#running-headers-and-footers

 > [4] Allow independent styling of copied content
 > [5] Provide way of selecting which instance of element is used on a
 > given page (as first/start/last/first-except tries to do)

Nice, and ambitious, list. You also want a switch to clear other
content, or add itself to it, no?

 > Bert has lots of ideas at
 > http://www.w3.org/Style/2013/paged-media-tasks#running-headers-and-footers-there-are-tw
 > 
 > Thanks,
 > 
 > Dave

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Monday, 24 November 2014 21:22:59 UTC