Re: [css-page] properties that only apply within the page context

On Sat, Mar 21, 2015 at 5:40 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> There are a few properties defined in css-page that are intended to be
> used only in @page rules: size, marks and bleed.  These are all defined
> with a line in their blue property definition boxes that says
>
>   For:  @page
>
> Does that line have any normative requirements behind it, or like an
> “Applies to” line does it just informatively describe where the property
> can have an effect?
>
> I ask because I’m not sure whether size, marks and bleed should parse in
> non-@page contexts and be stored on declarations.  For example:
>
>   p { size: landscape; }
>
> Should the property be exposed on the rule when inspecting it with the
> CSSOM?
>
> Another question is whether these properties should be usable within
> @supports rules and passed to CSS.supports.

That's actually a descdef table; the For line specifies what at-rule
the descriptor is for.  (This is necessary, because descriptors aren't
required to be globally unique; different at-rules can use the same
descriptor name for completely different purposes.)

This implies that 'bleed'/etc is a descriptor of the at-rule, not a
property.  Per <http://dev.w3.org/csswg/css-syntax/#declaration>,
declarations are usually descriptors when inside of at-rules, and
properties when inside of qualified rules (style rules).

The implications of each possibility are:

# If they're descriptors
* They don't show up in the gCS()/etc results for normal elements.
* The inheritance behavior needs to be defined in reasonable detail,
rather than relying on the cascade.  (This isn't hard to do.)

# If they're properties
* They show up in gCS()/etc for all elements.
* Inheritance is "free"
* The page becomes an element in the element tree; is basically a
pseudo-element that has a weird at-rule syntax for legacy reasons.

Current implementation is weird.  According to dauwhe, 'bleed'/etc
don't show up in the OM for elements in Prince.  In both Firefox and
Chrome, they show up but always return the empty string, even if you
explicit set it on their inline style.  (Implementation status
interferes with this a bit, but both browsers at least implement
'size', so you can use that in tests.)  Note that "empty string" is
very different from "undefined", which is what you get for
non-existing properties.

So, we could probably go either way.  I don't have a strong opinion on
which, tho I slightly prefer descriptors, just for general consistency
with how at-rules work.

~TJ

Received on Wednesday, 25 March 2015 22:37:59 UTC