W3C home > Mailing lists > Public > www-style@w3.org > February 2009

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

From: Håkon Wium Lie <howcome@opera.com>
Date: Sun, 8 Feb 2009 20:03:07 +0100
Message-ID: <18831.11371.45794.457701@opera.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: www-style@w3.org

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/

  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.

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

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

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

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

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

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

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

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

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

Thank you for your review.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Sunday, 8 February 2009 19:03:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT