Re: [csswg-drafts] [css-page] Should page descriptors support `!important`? (#5970)

The CSS Working Group just discussed ``[css-page] Should page descriptors support `!important`?``, and agreed to the following:

* `RESOLVED: The stuff inside @page or @margin rule are descriptors but act like properties for behavior and cascade`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-page] Should page descriptors support `!important`?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5970<br>
&lt;Rossen_> q?<br>
&lt;dael> emilio: I noticed when reviewing patches for page descriptors the whole thing is a mess in all browers.<br>
&lt;dael> emilio: @page maybe is only one with keyframes. It's messy. Spec is confused about what's a descriptor. Can we define what cascade features work on @page and which do not<br>
&lt;dael> fantasai: I don't think keyframes cascade in same way. They have properties but I don't think they participate<br>
&lt;dael> fantasai: For @page rules they are supposed to cascade. Spec was written before variables so doesn't take that into account. Seems useful for those to work.<br>
&lt;dael> fantasai: They're all descriptors. They should behavior like regular properties including supporting !important. They cascade as properties with their own selectors and obey origin so no reason not to support<br>
&lt;dael> fantasai: Useful to support variables, should inherit from root and that's new<br>
&lt;dael> TabAtkins: agree<br>
&lt;dael> fantasai: Main thing I'm concerned about is there are descriptors that apply which are not regular properties. Not like you can just say just like an element, there's special stuff. But they should behave like properties, just not allowed in normal elements<br>
&lt;dael> emilio: Way all browsers imp afaict is making page descriptors css properties. Means blink and wk accept size in regular style blocks which is bad. So we should probably define these descriptors to be like css properties but that they can't be parsed in style blocks. I agree<br>
&lt;dael> Rossen_: Sounds like we are in agreement. What's the proposed resolution?<br>
&lt;dael> fantasai: 2 resolutions. 1) The stuff inside @page or @margin rule are descriptors but behavior like properties for behavior and cascade<br>
&lt;dael> fantasai: 2) Variables are also accepted and they inherit from root element<br>
&lt;dael> fantasai: root to @page<br>
&lt;dael> emilio: Precedent for that? backdrop doesn't<br>
&lt;dael> TabAtkins: backdrop is just a pseudo element<br>
&lt;dael> emilio: Similarities. custom properties work in ::backdrop. Page being over root...I guess same for tables<br>
&lt;dael> fantasai: Useful because then you get the fonts and such<br>
&lt;dael> TabAtkins: Colors especially<br>
&lt;dael> TabAtkins: backdrops quickly, they're on particular elements<br>
&lt;dael> emilio: Don't inherit from them<br>
&lt;faceless2> q+<br>
&lt;dael> TabAtkins: Okay. That's an exception<br>
&lt;dael> emilio: Inherit from root has another issue<br>
&lt;dael> emilio: Relative to font size and relativeness. Fine with this, but not how browsers behave. Browsers and some print UAs take @page into account for MQ. This introduces a cycle<br>
&lt;dael> emilio: Totally fine b/c I think we shouldn't take them into account. Maybe we can resolve they support properties for not and mabye move inherit from root to another issue<br>
&lt;Rossen_> ack faceless2<br>
&lt;dael> faceless2: I wanted to say pages inherit from root works well for counter. No other way to do it. To my mind it's right way to do it<br>
&lt;dael> emilio: Fine with that, but people want @page size to influence MQ which sounds gnarly<br>
&lt;dael> TabAtkins: True<br>
&lt;dael> TabAtkins: Leave variable open and resolve on rest?<br>
&lt;dael> Rossen_: Yeah<br>
&lt;dael> Rossen_: The stuff inside @page or @margin rule are descriptors but act like properties for behavior and cascade<br>
&lt;dael> RESOLVED: The stuff inside @page or @margin rule are descriptors but act like properties for behavior and cascade<br>
&lt;dael> Rossen_: And we'll discuss more intention for variables and bring it back<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5970#issuecomment-780728177 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 17 February 2021 17:41:18 UTC