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

2009/2/9 Håkon Wium Lie <howcome@opera.com>

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

I meant, hurry with GRC.

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

I'm very happy of this. "Luckily", the main point of this discussion (named
flows) are not implemented yet.

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

You can still have .note::alternate { content:target-pull(attr(href,uri));
}
(and anyway the implementors, at least now, are not browsers, they're pdf
creators and formatters)

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

You can contain magic to the footnote keyword in to content:property (that
in turn triggers a lot of defaults around the element), while leaving
.note {
counter-increment: my-node;
content: counter(my-node,super-decimal);
}
.note::alternate {
display:list-item;
content:contents;
move-to: my-node-bucket;
}
.note::alternate::marker {
content: counter(my-node,super-decimal);
}
#my-notes {
content: pending(my-node-bucket);
}
without any additional magic applied.

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

How much memory does a new property need?

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

Well, in this case, you may just say that the user agent (after finding the
specified values of various properties) must act as if the element was part
of the DOM in the point where it was inserted.
This is what you have to say in any case for the property to integrate with
the other, for example inside a table, a block must be wrapped into an
anonymous table-cell, in turn wrapped into an anonymous table-row, part of
an anonymous table-row-group.

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

See above: just act if the element was part of the dom in the insertion
point. You already need it: what about a floated running header?
And note the fact that position different than static or relative, is
assumed to be absolute or fixed in various specifications.

>  > >  > 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?
>
I don't know. Let's wait for an implementor feedback.


>  > >  > 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 */
>
Well, the proposal was the ::line(an+b) itself, that could in turn be
combined with ::after and ::before to create line markers. But it is useful
also on its own: alternate line background, for example, or indentation more
complex than just for ::first-line, things like "each third row indented".
With ::line-before / ::line-after, the difference from the current proposal
is just an+b.

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