[css-page-3] Should `@page` declarations be hoisted?

[cdoublev]

Current version of Chrome and FF hoist declarations in @page:

const sheet = new CSSStyleSheet
sheet.replaceSync(`

  @page {
    @top-left {
      content: "green";
      color: green;
    }
    color: red;
  }

  style {
    @media {
      color: green;
    }
    color: red;
  }

`)

sheet.cssRules[0].cssText; // @page { color: red; @top-left { ...; color: green; } }
sheet.cssRules[1].cssText; // style { @media { color: green } color: red; }

If I am not mistaken, @page (with no page selector) and margin rules have the same specificity. So this might be unexpected, like in style rules.

Should they be wrapped in CSSNestedDeclarations whose style attribute is a CSSPageDescriptors?

[bramus]

Should they be wrapped in CSSNestedDeclarations whose style attribute is a CSSPageDescriptors?

Seems like a good idea in order to make behavior consistent / predictable.

/ping @andruud

[cdoublev]

@font-feature-values and @function also take declarations and rules as their block contents, but there is no corresponding interface inheriting CSSStyleDeclaration. I guess hoisting declarations is inappropriate in @function.

So the question might be whether CSSNestedDeclarations.style should exist or not.

[andruud]

cc @mstensho

I agree that not hoisting would be more consistent, especially if it actually matters for the behavior.

but there is no corresponding interface inheriting CSSStyleDeclaration

I do think we're going to need a CSSFooDeclarations for any @foo that accepts declarations in its block contents, exposing just the descriptors that are relevant for that at-rule.

I guess hoisting declarations is inappropriate in @function.

Definitely inappropriate. It's currently specced to use CSSNestedDeclarations, but it doesn't actually work well due to style being the wrong type, as you mentioned.

[mstensho]

It doesn't matter for the behavior. Note that the spec recommends that @page declaration be placed before any margin rules, though.

https://drafts.csswg.org/css-page-3/#margin-at-rules

Page-margin boxes are created by margin at-rules inside the page context. Authors should put these rules after any declarations in the page context as legacy clients may not handle declarations after margin at-rules correctly.

As such, it makes slightly more sense to hoist, than not to hoist. But it shouldn't matter. Specificity isn't an issue here, since what's in @page and what's in @top-left addresses different boxes (page box vs. page margin box).

@page properties apply in the page context, which acts as a parent of any page margin contexts (which are defined by property declarations inside page margin rules). A page margin context may inherit properties from a page context, which in turn may inherit from the document root element.

See https://drafts.csswg.org/css-page-3/#page-model and https://drafts.csswg.org/css-page-3/#page-properties

[cdoublev]

It does not matter for the rendering behavior as long as conditional rules are not allowed in @page, which might be useful to avoid repeating multiple @page rules for different conditions:

@page {
  @media print and (width > 21cm) {
    margin: 3cm; /* Applies only if declarations are hoisted */
  }
  margin: 1cm;
}

Now this can remain unspecified and change later if conditional rules are allowed, which would only change the CSSOM behavior.