Re: [css3-gcpm] Incompatibilities with css3-content

Also sprach Giovanni Campagna:

 > > Yes, there are some differences. Note the dates, though:
 > >
 > >  CSS3 Generated and Replaced Content Module
 > >    W3C Working Draft 14 May 2003
 > >    http://www.w3.org/TR/css3-content/
 > 
 > Actually 22 January 2008
 > http://dev.w3.org/TR/css3-content/

Indeed, it has been imported into dev. It doens't seem like anyone has
been working on it, though.

 > >  CSS3 module: Generated Content for Paged Media
 > >    Editor's Draft 8 January 2009
 > >    http://dev.w3.org/csswg/css3-gcpm/
 > >
 > > That is, GRCM is dormant, while GCPM is actively developed.
 > 
 > Well, hurry then!

At this stage, GCPM is mostly feature-complete and we are awaiting
implementation experience. 

 > Is GCPM implemented? If yes, where?

Prince (http://www.princexml.com) and AntennaHouse
(http://www.antennahouse.com/) both support GCPM, in parts.

Roughly speaking, both implementations support GCPM up to, and
including page floats (section 19), except section 7, 8, 9, and 17.
Implementations are progressing rapidly, though.

 > > It's quite easy to create endnotes in GCPM:
 > >
 > >   .note { float: to(endnote) }
 > >
 > > To number them, you would use a counter:
 > >
 > >   .note:before { content: counter(endnote) }
 > >
 > > I don't see how this is difficult. Or, am I misunderstanding what you
 > > are trying to say?
 > 
 > Endnotes in GRC are as easy as footnotes (just one content), endnotes in
 > GCPM require explicit counters and pseudo-elements.

Note, however, that GCPM supports the pulling of endnotes into
footnotes. This way, documents can have endnotes in legacy
screen-based presentation, while they can be turned into footnotes in
print-based presentations. Legacy browsers (IE) don't support
generated content anyway, so the benefit of switching from endnotes to
footnote withough having to set counters and such has limited value.

 > > The differences are:
 > >
 > > - GCPM offers both a generic model for moving elements (like
 > >   GRCM does, but with slightly different names) and a specific
 > >   one for footnotes. The specific method is necessary as the
 > >   formatting of footnotes sometimes needs som heuristics. (This
 > >   is described in the "Footnote magic" section.)
 > 
 > If heuristics can be applied to float:footnote; they can also be applied to
 > content:footnote, cannot they?

Maybe. However, if you add magic to the GRCM model, you only have a
magic mode. GCPM has two mechanisms -- one magic, and one generic --
so that magic can be contained.

 > >  - GCPM reuses property names more than GRCM does. For example,
 > >   'float' is used instead of 'move-to'. I think it best to reuse
 > >   properties whenever possible and 'float' was chosen after a long
 > >   debate.
 > 
 > Why do you think so?

Because, for every element you need to store the set of properties and
values. New properties means more memory usage. 

 > I do think the opposite: many CSS modules make assumptions about the values
 > of properties (an element with a computed value for float different from
 > none is a flow root for example). The implementation cost of adding the new
 > value "to()" to float seems very similar to the implementation cost of
 > adding the "move-to" property, since they do the same thing.

New values also have a cost, but lower than properties, it seems. 

Futher, having several properties in the same area means that you have
to describe how to combine them. By using the same property, you can
avoid some of the complexity.

 > > You can invent a new property, but that has a cost an implementors
 > > tend to object. Reusing 'position' is a pragmatic choice. 'Position'
 > > is already used to express to very different concepts -- relative
 > > positioning and absolute positioning -- so I think it's ok to use it
 > > for running headers and footers.
 > 
 > No. Position is used to express only one concept: what "top" / "left" /
 > "bottom" / "right" mean: nothing, an offset, a position relative to the
 > first positioned ancestor, a position relative to the viewport / page. In
 > addition, the same remarks as float apply: some modules rely to specific
 > values of position and this would break them.

Your argument isn't unreasonble, and I'm not necessarily strongly
opposed. However, by adding a new property instead of reusing
'position', you need to describe what 'position' means when your new
property is used. And, you need to convince implementors that a new
property is better than reusing an old one.

 > >  > I think that adding a keyword to move-to is what we need:
 > >  > move-to: <identifier> once;
 > >  > means elements are appended to the <identifier> and then removed when
 > >  > processing pending() (like footnotes and named flows)
 > >  > move-to: <identifier> running;
 > >  > means that the current elements replaces the content of <identifier> and
 > > it
 > >  > is not removed when inserted with pending() (so it may be inserted an
 > >  > arbitrary number of times)
 > >
 > > That could work.
 > >
 > > I don't think it's any more intutive and it adds the cost of an extra
 > > property. However, if implementors think it's worth changing I will
 > > not object.
 > 
 > 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?

 > >  > 2) hypenation is in the scope of Text module (just copying may be fine)
 > >  > 3) we have a ::line-marker and 4 ::line-number pseudo-element: I think that
 > >  > one of two proposal should be removed
 > >
 > > There should only be one model, yes. The model presented in GCPM is
 > > only a sketch, but it addresses a common scenario: that line numbers
 > > are only shown on every x lines. This seems useful, no?
 > 
 > Before I read GCPM, I thought that line numbering was for programming code
 > (and in that case you need every line), but actually it can be used for
 > poetry for example.

Yes.

 > Well... what about a ::line(an+b) pseudo-element? (where an+b is the syntax
 > for :nth-child and :nth-of-type selectors)
 > ::line(an+b)::after = ::line-number-right
 > ::line(an+b)::before = ::line-number-left

I assume your proposal is on the left hand side of the '=' sign?

I'd prefer to use only one pseudo-element to express this. How about:

  ::line-before(an+b) { content: counter(line) } /* say */
  ::line-after(an+b)  { content: counter(line) } /* say */

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

Received on Monday, 9 February 2009 17:58:21 UTC