You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-cascade-5] Cascade Layers need CSSOM support #6576
This is not entirely trivial. Since we have two types of @layer rules, the empty statement and the block rule, do we want the same interface for both of them, or different interfaces?
I don't have a strong preference. Just putting the options here for discussion.
If we use different interfaces, the following seems pretty straightforward:
If we use the same interface, it would probably be like
[Exposed=Window]
interface CSSLayerRule : CSSGroupingRule {
readonly attribute CSSOMString name;
readonly attribute boolean isEmptyStatement;
unsigned long insertRule(CSSOMString rule, optional unsigned long index = 0); // Is this the correct syntax for override?
};
We need to override CSSGroupingRule.insertRule() so that it throws an exception when called on empty statements.
I think we should make them separate objects, since they have quite distinct data models - one vs N names, child rules vs not. They're the same name for authoring convenience, but that doesn't need to translate to them being the same object type.
Yup, that's what I meant by "one vs N names". @xiaochengh's example supports that, it just exposes the N names as a single CSSOMString rather than as a list of them.
On the other hand these interfaces are pretty useless anyway so I'm equally fine with a generic object that exposes nothing but cssText and the tree structure.
Activity
xiaochengh commentedon Sep 3, 2021
This is not entirely trivial. Since we have two types of
@layerrules, the empty statement and the block rule, do we want the same interface for both of them, or different interfaces?I don't have a strong preference. Just putting the options here for discussion.
If we use different interfaces, the following seems pretty straightforward:
If we use the same interface, it would probably be like
We need to override CSSGroupingRule.insertRule() so that it throws an exception when called on empty statements.
tabatkins commentedon Sep 3, 2021
I think we should make them separate objects, since they have quite distinct data models - one vs N names, child rules vs not. They're the same name for authoring convenience, but that doesn't need to translate to them being the same object type.
emilio commentedon Sep 3, 2021
I'd prefer not having two interfaces for this, fwiw... Also, for the
@layer a, b, c;case we need a sequence of names, not just one name, right?tabatkins commentedon Sep 3, 2021
Yup, that's what I meant by "one vs N names". @xiaochengh's example supports that, it just exposes the N names as a single CSSOMString rather than as a list of them.
anttijk commentedon Sep 4, 2021
Having two separate interfaces might actually make sense as there is nothing that can be shared.
CSSImportRule also needs an extension.
emilio commentedon Sep 4, 2021
Yeah, I guess that's fine / alright, specially given we've given up on making
CSSRule.typereturn something meaningful for these.anttijk commentedon Sep 4, 2021
On the other hand these interfaces are pretty useless anyway so I'm equally fine with a generic object that exposes nothing but cssText and the tree structure.
emilio commentedon Sep 6, 2021
That'd be totally ok for me too.
Bug 1729330 - Add a simple CSSLayerRule implementation. r=smaug
emilio commentedon Sep 8, 2021
FYI. Not ideal, but I needed some OM support to make DevTools etc work in Firefox.
What I did for now is implementing it as:
Where
cssRuleswill return null for statement layers. Again, probably not ideal, it was just the easiest to implement.19 remaining items
[css-cascade-5] Define CSSOM Layer APIs #6576
mirisuzanne commentedon Nov 16, 2021
@anttijk @xiaochengh @emilio let us know if the edits in 6e8482b satisfy the question here.
foolip commentedon Nov 22, 2021
For ease of review, that's https://drafts.csswg.org/css-cascade-5/#layer-apis.
xiaochengh commentedon Nov 22, 2021
b7c7a15 lgtm
xiaochengh commentedon Nov 24, 2021
Wait, there's one last thing missing: We need to be able to distinguish whether a CSSImportRule is unlayered or in an anonymous layer.
How about making
layerNamenullable (readonly attribute CSSOMString? layerName;), so that it returnsnullwhen the rule is not layered?[css-cascade-5] Make CSSImportRule.layerName nullable #6576 (#6849)
style: Add a simple CSSLayerRule implementation
style: Add a simple CSSLayerRule implementation
Bug 1729330 - Add a simple CSSLayerRule implementation. r=smaug