[css-page] [css-variables-2] Allow use of css-variables in page contexts

[faceless2]

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:

• switching from single column to two column after the first page
• changing border-radius values depending on whether the page was left or right

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:

  @page :left {
    var-foo: 2em 0.5em 0.5em 2em;
  }
  @page :right {
    var-foo: 0.5em 2em 2em 0.5em;
  }

  div {
    border-radius: var(foo);
  }

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

  div {
    border-radius: from-page-context(var-foo);
  }

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

  @page :left {
    color: blue;
    var-foo: 2em 0.5em 0.5em 2em;
  }
  @page :right {
    color: green;
    var-foo: 0.5em 2em 2em 0.5em;
  }

  div {
    color: from-page-context(color);
    border-radius: from-page-context(var-foo);
  }

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

[faceless2]

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 page: var(--page) to inherit from the @page rule, but there are plenty of others you would consider excluding from using the page-context for inheritance (display, break-before, position spring to mind).

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;
}

[AmeliaBR]

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

Prince 13.1 adds support for CSS variables in @page rules and margin boxes; changes the @page rules to inherit from the document root element;

I don't have any more details, but I'd guess that includes setting variables (--space: 20px) in the page context and using variables set for the page or for the document root element (margin: calc(3 * var(--space))).

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.

[faceless2]

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.

[tabatkins]

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

[faceless2]

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.