- From: MURAKAMI Shinyu <murakami@antenna.co.jp>
- Date: Fri, 13 Sep 2013 09:07:20 +0900
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Lea Verou <lea@verou.me>, Simon Pieters <simonp@opera.com>, Brad Kemper <brad.kemper@gmail.com>, Alan Stearns <stearns@adobe.com>, www-style list <www-style@w3.org>
Håkon Wium Lie <howcome@opera.com> wrote on 2013/09/12 15:58:57 > Also sprach Tab Atkins Jr.: > > > >> article::page(left) p > > > > This is not possible AT ALL if ::page() is a pseudoelement, as > > > elements cannot be nested in pseudoelements: “the pseudo-element > > > must appear after the compound selector that represents the > > > subjects of the selector” [1] > > > > We're removing that restriction. It made some sense for the 2.1 > > pseudo-elements, but makes less and less as we move into the future. > > Indeed. But we need to figure out how to resolve inheritance -- will > it still be based on a 'fictional' tag sequence? > > http://www.w3.org/TR/CSS2/selector.html#first-line-pseudo I don't understand well the idea of the nesting in the page pseudo-elements, article::page(left) p { text-align: left; } If the p element spans pages, the fragments can have different styles? If so, the result will be same as the following? article p::page(left) { text-align: left; } And the difference between the page pseudo-elements and the proposal of the nesting in the @page rules are only syntax and have same functionality? @page :left { { article p { text-align: left; } } } The @page rules can have not only :left and right but also :first, :blank and page names. the pseudo-elements page() notation can have these too? I am worried that the spec will be very complicated (I don't think I can implement), or not very complicated but very restricted (e.g., fragments cannot have different style). I proposed an alternative idea: http://lists.w3.org/Archives/Public/www-style/2013Sep/0046.html We need only two things: - custom properties (CSS Variables) - the from-page-context() property function This mechanism will be much simple and easy to implement to our formatter (AntennaHouse). The custom properties (CSS Variables) spec is already in the Last Call stage. We need only to add the from-page-context() property function to the CSS spec. Example: @page :left { var-align: left; var-radius: 2em 0.5em 0.5em 2em; color: blue; } @page :right { var-align: right; var-radius: 0.5em 2em 2em 0.5em; color: green; } article p { text-align: from-page-context(var-align); border-radius: from-page-context(var-radius); color: from-page-context(color); } The property function from-page-context() retrieves the property value that the argument matches the property name on the page-context, which can be custom (var-*) or normal properties. The from-page-context() value must be evaluated at each fragment and the layout will be changed when the element spans multiple pages. This processing will be not very complicated in most cases, but probably some restrictions will be needed, e.g., changing the 'display' property value at page breaks will make the behavior complicated but I don't think we must support that. Changing computed property values by fragment is much easier than changing whole style rules, no need to repeat the cascading process, and that will be useful enough. Of course, we have to define the from-page-context() value at the root element to avoid the circular problem, Tab wrote: > This makes sense, though it adds some complication. Pages inherit > from the root element, so something like ":root { color: > from-page-context(color); }" is circular. We could define that the > function returns the initial value of the property on the root element > to avoid this, of course. Thank you, Shinyu Murakami Antenna House
Received on Friday, 13 September 2013 00:07:55 UTC