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

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

> Also sprach Giovanni Campagna:
>
>  > I recently came into the CSS Generated Content for the Paged Media and
> found
>  > some strangeness comparing between Generated and Replaced Content and
>  > Generated Content for the Paged Media.
>
> 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/

>
>  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!
(and maybe we should find a new editor for that module, the current one is
involved in many projects at the moment)

>
>  > css3-content. introduces footnotes with the "::alternate" pseudo-element
> for
>  > the note itself, "::alternate::marker" for the footnote call, with the
>  > "footnote" content keyword and the "move-to" property, adding a
>  > "content:pending(footnotes)" on the @bottom-left page margin box. This
> also
>  > works well with endnotes and section-notes, and it relatively easy to
> write
>  > down:
>  >
>  > example:
>  >
>  > <p>My content. <span class="note">my note</span></p>
>  > with the following CSS:
>  > .note {
>  > content: footnote;
>  > }
>  > /* this implies:
>  > .note::alternate {
>  > move-to: footnotes;
>  > content: contents;
>  > }
>  > .note {
>  > counter-increment:footnote;
>  > } */
>  > and the following addition to UA defaults:
>  > @counter footnote super-decimal;
>  > @page {
>  > @bottom-left {
>  > content:pending(footnotes);
>  > }
>  > }
>  >
>  > If you want end notes instead of footnotes, just change the content
> value.
>  >
>  > If you want custom notes, just ensure that ::alternate is generated and
>  > contains the correct content.
>  >
>  > css3-gcpm instead uses the "::footnote-marker" and "::footnote-call"
>  > pseudo-elements, with the "footnote" float keyword, while for the other
>  > types of notes uses the "to()" functional notation in float and "from()"
> in
>  > content.
>  >
>  > example (same content as above):
>  > .note {
>  > float:footnote;
>  > }
>  > /* this implies:
>  > .note::footnote-call, .note::footnote-marker, @footnote page area
>  > */
>  >
>  > on the other side, for endnotes and section-notes it is more difficult
> as
>  > every property has to be set separately.
>
> 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. But it is probably just
a syntax issue: ::alternate vs the element itself, the element vs
::note-call / ::footnote-call, ::alternate::marker vs ::note-marker /
::footnote-marker, the latter seems to be only for notes (instead named
flows are useful when ever you need to reorder the DOM)

>
>  > In addition to this new pseudo-elements, syntaxes, values and properties
>  > that Paged UAs must implement (and that are not needed, since the same
>  > effect can achieved with the different properties). Therefore I propose
> that
>  > the whole section about footnotes in css3-gcpm be reduced to the
> addition of
>  > "@footnotes" and footnotes magics. Also the section on named flows
> should be
>  > dropped in favour of the move-to property.
>
> I'm open for changes to the draft, but I don't think it should be
> dropped in favor of GRCM. First, GRCM isn't implemented by anyone and
> isn't maintained at this point. The good parts -- and there are many
> -- have been imported into GCPM.

Is GCPM implemented? If yes, where?

>
> 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? In addition, some magic refer to the
@footnote area, which is a different feature (we may need it even if we
decide to keep the GRC model)

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

>
>
>  - GCPM can pull elements from other parts of the document (by way of
>   a link) and can turn these elements into footnotes

I'm not asking to drop the complete GCPM and the target-* properties are
surely useful. Just drop the properties that are defined in both module.

>
>  > The latter leads me to the running header. Can those be achieved without
>  > adding a new "position" value? Position should express the positioning
>  > model, not where the element is actually position, and in many places
>  > "positioned elements" are those which have a position different than
> static:
>  > this would break it.
>
> 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.

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

>
>  > Other changes that I would like to propose:
>  > 1) named strings are defined in two modules, with different syntaxes (in
>  > particular about the page-policy property)
>  > I think they're useful also outside of the Paged Media, so they should
> be
>  > inside css3-content
>
> Do you have a used case outside of paged media?

Currently no. You may leave those only to paged media, and that would not
change too much to me. Just drop @string from GRC and I will anyway be able
to use it in a non paged media, since I expect it to be implemented also in
"screen-centric" UAs (they have to print, after all)

>
>
>  > 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.
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
This way you don't need two pseudo-elements for right and left and you can
for example style lines in alternated colours.

>
> Thank you for your review.



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

Giovanni