-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-page] [css-variables-2] Allow use of css-variables in page contexts #4761
Comments
The reason I like this is it can be done by extending an existing, well understood part of CSS to offer a great deal of new functionality with no new syntax, and virtually no learning curve. Simply insert the page context as an ancestor for variable inheritance after the root element. This wouldn't work for everything, of course - most obviously you couldn't expect However, for a suitably limited list of properties, it offers great things: :root {
--cols: 2;
}
@page :first {
--cols: 1;
}
div {
column-count: var(--cols);
} @page :left {
--radius-right: 50%;
--radius-left: 0;
}
@page :right {
--radius-left: 50%;
--radius-right: 0;
}
.box {
border-top-left-radius: --radius-left;
border-bottom-left-radius: --radius-left;
border-top-right-radius: --radius-right;
border-bottom-right-radius: --radius-right;
} |
I'm not sure whether it provoked @faceless2's post or if this is just serendipity, but Prince XML recently announced that they will be supporting CSS variables (tweet, release notes):
I don't have any more details, but I'd guess that includes setting variables ( I assume that it doesn't address this specific issue (having other contents inherit or evaluate variables set in the page context) since there's no clear cascade rule for that yet. |
Pure serendipity! I hadn't seen that at all. Yes, the big question is whether @page can set variables as well as use them, and if so, how they propagate. |
@page inheriting variables from the root: sounds good and reasonable, I'd be happy to support that. Elements inheriting variables from the @page they find themselves on: hm, quite a bit more concerned about this. My big issue is how elements act when they break across pages; do they just get the value of the first page they're on? |
Considering the goal of the original proposal, the answer is no they don't - the fragments would be styled individually. In particular the "one column on first page, two on subsequent pages" would involve styling the fragments. That case keeps coming up, so as this is a bit of a blue sky issue I think it's worth trying to solve for that case here. But yes, it's a non-trivial change. Fragment styling is already being considered in css-overflow-4. |
Propagating an old idea of Shinyu Murakami from the mailing list to Github issues, because I think it's the kernel of a great idea. I want to make sure it's available as a starting point for discussion.
The intended goal is to allow some page-based variation of fragments, of the type commonly requested in print workflows, eg:
Original email (and his followup):
https://lists.w3.org/Archives/Public/www-style/2013Sep/0046.html
https://lists.w3.org/Archives/Public/www-style/2013Sep/0292.html
Hello,
I would like to propose another approach: Use CSS Variables with @page :left/:right.
An example:
The problem here is that the
var(foo)
cannot refer the custom property 'var-foo' value set in the @page context according to the current spec.We need to allow this usage, or to define another notation to refer the custom property values set in the @page context, e.g.:
Here the from-page-context() function retrieves the property value that the argument matches the property name, which can be custom (var-*) or normal properties, e.g.:
The concept of the from-page-context() function is similar to the
from-page-master-region()
function defined in the XSL-FO, although this XSL-FO's function only accepts very limited properties, and no custom properties, for now.Regards,
Shinyu Murakami
Antenna House
The text was updated successfully, but these errors were encountered: