- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Tue, 21 Feb 2012 10:02:26 +0100
- To: Brad Kemper <brad.kemper@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>
Le 21/02/2012 09:00, Brad Kemper a écrit : >> The semantics would be similar to regions, but there is a syntax >> problem to disambiguate @page properties and type selectors. >>> >>> This is a big feature, and I wouldn’t want it to delay what is >>> already in css3-page (especially margin boxes.) So how about this >>> keeping full selectors for level 4? > > I don't see how it could be bolted on later without at least making > allowances for it now. I don't think you could have 'a:link' (an > element and a pseudo-class) in the same place where you could have > 'color:green' (a property and value). I think the way to disambiguate > would be to not have properties directly within @page, but rather > have a selector to set the page box. I think :root could work, but if > that is problematic, then maybe just ':page'. Margin boxes were added just fine in the middle of @page. We can add anything at any time, as long as it does not start with an IDENT token (that would be a property name) or one of the 16 at-keywords for margin boxes. Of course selectors can start with an IDENT so some kind of marker would be needed. But that can happen at any time. > Also, I share Håkon's feeling that regions should not proceed too far > without giving more thought to how they can be used without > requiring markup for each region box (ie, I'd say generate > pseudo-elements that could be regions instead). Similarly, I think > regions, pages, page masters, overflow:paged, and columns all need to > be considered together, in terms of how they can and should affect > each other, and how consistent they are, or could/should be, at > solving the same sort of problems. It doesn't seem right for regions > to be fast tracked possibly ahead of pages with the ability to style > individual region content differently without giving a similar > ability to pages. There is certainly use cases for that power to be > in pages. In fact, the purpose of regions is to be able to do > magazine-like layouts. Magazine layouts are very much layouts of > multiple pages. How can we consider linking regions without > considering how to link them from one page to the next with different > page designs? That should really be something that css3-page is ready > for. I'd rather that happen now than later. I understand that these should be considered together but I don’t know how stable/ready the whole thing. The current css3-page on the other hand adds margin boxes and page counters. These have been a WD for a long time and have many (at least partial) implementations. Here are a few: http://weasyprint.org/#sample-output (this one is mine) http://www.princexml.com/doc/5.1/page-headers-footers/ http://www.tufat.com/docs/html2ps/compatibility.css.3.html http://www.antennahouse.com/CSSInfo/css_reference.html#css-property-conf-rule http://www.realobjects.com/products/pdfreactor/demos-docs/sample-documents/page-layout-samples/ http://flyingsaucerproject.github.com/flyingsaucer/r8/guide/users-guide-R8.html#xil_40 http://blog.tallcomponents.com/2011/03/css3-page-counter.html I’m sure more careful googling can turn up more. Though not remotely as much as web browsers and not in the same contexts, these implementations *are* in use. Almost all of them have unprefixed WD features. The spec needs polish in corner cases (and probably a new algorithm for Margin Boxes Variable Dimension, but that’s another story) but I think it is relatively stable. > Adding selectors inside @page is not that much more to consider. It > should be no worse than @region, or of selecting descendants of > :first-line. Choosing a marker to disambiguate the syntax can be pretty quick, but spec’ing precisely how the cascade and layout work is another story. But again I don’t know stable ready it is in the Regions spec. I think that selectors3 do not allow selecting descendants of :first-line (Pseudo-elements are only allowed at the end of a selector.) Is that in selectors4? > My @slot goes further, but it is not much more than what > we have with ::before and ::after, or with margin boxes, except to > have an arbitrary number of them per paged page, and let them use > 'flow-from'. This sounds interesting, but please let margin boxes progress without attaching new features to the same spec. Do that in level 4 or in another module like GCPM does. Regards, -- Simon Sapin
Received on Tuesday, 21 February 2012 09:03:01 UTC