- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Oct 2022 21:33:06 +0000
- To: public-css-archive@w3.org
I'm fine in theory with the "implicit `& {}`"` thing, but it's inconsistent with some existing at-rules: in particular, `CSSPageRule` is the one place we currently have that can mix arbitrary declarations with at-rules, and it has both `.style` and `.cssRules`. On the other hand, it *is* true that the use of .style on CSSFontFaceRule, and probably on CSSPageRule, was a legacy mistake; they have a very restricted set of declarations they allow, and should have used individual JS properties per declaration, like CSSCounterStyleRule or CSSFontFeatureValuesRule. Sigh. We also have one related issue, which is how we'll represent nested rules in style attributes (assuming we do that in the future). The `el.style` attribute just *is* a CSSStyleDeclaration, so there's no CSS*Rule to hang a `.cssRules` off of. *Ideally*, we'd have the same API shape as normal style rules. This suggests we might want to proactively move normal nested rules to hang off of CSSStyleDeclaration. If we did so, then our rules would be: * For normal style rules, you access properties on `.style`, and nested rules on `.style.cssRules`. * For attribute styles, you access properties on `.style`, and nested rules on `.style.cssRules`. * For at-rules, aside from a few legacy ones, you always access their contents as `.cssRules`, including nested properties. Non-property declarations are always accessed as similarly-named JS properties (aside from the legacy ones). -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7850#issuecomment-1291167636 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 25 October 2022 21:33:08 UTC