Re: [css3-gcpm] New Editor's Draft

On Sat, Mar 1, 2014 at 9:40 PM, Håkon Wium Lie <howcome@opera.com> wrote:
> Dave Cramer wrote:
>
>  > A new editor's draft of GCPM is available at [1].
>  > [1] http://dev.w3.org/csswg/css-gcpm/
>
> This is good work, I'm happy to see newfound energy for this inside W3C.
>
>  > 1. Running Headers and Footers
>  > ---------------------------------------------
>  >
>  > The 'string-set' property's content-list now includes an
>  > 'attr(<identifier>)' value, so that attribute values may be used as
>  > text in running heads. This has been implemented by AntennaHouse
>  > and Prince.
>
> Nice to see interoperability here. I'm not sure one needs to add the
> 'attr()' syntax explicitly, though -- it should be automatically
> allowed.

Yes.  In fact, none of the functions need to be explicitly allowed,
since they all represent <string>s.  Just define the syntax as a
<string> and you're golden.  (But maybe have a note that certain
functions are probably useful to use, so that people realize they can
use attr()/counter()/content().)


>  > The CSS3 Page Module defines page pseudo-classes for first, left,
>  > right, and blank @pages. A major goal of GCPM is to extend this to
>  > allow the selection of any document @page. The previous draft of
>  > GCPM used the page-group property and the nth() selector to do
>  > this. A page group is essentially all the pages generated by an
>  > instance of an element (often a section or div), when that element
>  > uses a named page (what desktop publishing people would call a
>  > master page):
>  >
>  > section.chapter {
>  > page: body;
>  > page-group: start;
>  > }
>  >
>  > Prince and previous versions of GCPM used page-group: start to
>  > change the behavior of the :first page pseudo-class, so that it
>  > would select the first page in the page group instead of the first
>  > page of the document. In the above example, @page body:first would
>  > select the first page of every chapter, which is really useful.
>  > But this changes the meaning of :first, which was defined in CSS
>  > 2.1.
>
> I'm nut sure it changes anything, it just describes what happens when
> :first is combined with a named page. Like:
>
>   @page chapter:first { .. }
>
> This is useful and the syntax is intuitive. And it is interoperably
> supported by Prince and AntennaHouse:
>
>   http://www.wiumlie.no/2014/tests/books/page-group-first-pr.html
>   http://www.wiumlie.no/2014/tests/books/page-group-first-ah.html
>   http://www.wiumlie.no/2014/tests/books/page-group-first.html

As we've discussed before, this interpretation of the syntax is
fundamentally incompatible with the semantics of Selectors.  Each
simple selector is a filter, and none of the filters are allowed to
refer to the currently-matched elements.

You could have a pseudo-class that selects the first page with a
particular name, or the first page of a named run, but that won't have
quite the same semantics as a naked ":first" does today.  Or you could
make :first functional, so that :first(chapter) is the first "chapter"
page, but :first by itself is just the first page of the document.

There are several viable solutions that maintain the semantics of
Selectors, but keeping it as currently implemented is not one of them.

~TJ

Received on Monday, 3 March 2014 19:26:39 UTC