- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Oct 2021 22:15:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Cascade Layers need CSSOM support`, and agreed to the following:
* `RESOLVED: Prop: We will have 2 separate objects; one for rules w/o a block and one for rules with a block`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Cascade Layers need CSSOM support<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/6576<br>
<dael> miriam: A few options shown in the first ocmment on the issue. Discussion about 2 objects or 1 single. If 2 one is for empty layer rules and the other for layer rules with something<br>
<dael> miriam: Don't have an opinion, if anyone does love for them to speak up<br>
<dael> astearns: Looks like people in issue are saying whatever<br>
<dael> miriam: Seems no strong preference. A little sense of it's not useful but needed<br>
<dael> astearns: That 2 objects are needed?<br>
<dael> miriam: That some resolution is needed. But not particularly useful either way<br>
<heycam> q+<br>
<dael> fremy: Maybe idea for simlied. @layer a with no rule and @ layer b with no rule and you don't need one or the other. Then it's only one type of rule. I don't write these, but maybe an idea?<br>
<astearns> ack heycam<br>
<astearns> q?<br>
<dael> heycam: With a single interface...perhaps issue with both approachs...a bit weird if insert and remove rule can change the type. Maybe argument for one interface<br>
<fremy> was suggesting maybe considering `@layer a, b, c` syntactic sugar for `@layer a{} @layer b{} @layer c{}` then you only have one type of rule<br>
<dael> heycam: I see suggestion from xiao was throw exception when insert called on rule without block. I guess need inverse as well<br>
<fantasai> note that @layer b {} is not valid before @import, but @layer b; is<br>
<dael> astearns: Have not thought much but slightly more in favor of single interface that could expect both and lets you go back and forth between<br>
<dael> heycam: Reasonable for author to say start with a layer that has no block and then want to, in cssom, add children?<br>
<fremy> @fantasai: ah, ok, then that doesn't work. except if we change it to allow @layer {} before import but not allow it to have rules in it?<br>
<dael> heycam: If we want to allow that I guess the single interface makes more sense. Else no way to preserve object identity. Perhaps that's not reasonable<br>
<astearns> ack fantasai<br>
<TabAtkins> q+ to talk about syntax mismatch<br>
<dael> fantasai: The @layer rule with a block that accepts style ruels is not allowed before @import but is allowed after<br>
<dael> fantasai: There's several different syntax restrictions<br>
<dael> fantasai: I do think heycam suggestion makes sense. Likely authors will want to add and remove rules from @layer. If converting from being a block ro not I'm not sure, but adding to an empty block I can imagine<br>
<dael> fantasai: There's complication there about being before or after @import<br>
<dael> heycam: Symantically important to allow @layer block before @import?<br>
<dael> fantasai: Yes b/c layered in order of apperance. If importing rules that define appearance it matters. Layers with same name combine.<br>
<dael> fantasai: If you want rules before the @import you can add the layer and have it appear before @import<br>
<astearns> ack TabAtkins<br>
<Zakim> TabAtkins, you wanted to talk about syntax mismatch<br>
<dael> TabAtkins: fantasai covered some of this, but more syntactic mismatch. @layer that doesn't have block allows comma sep. list but with block is only 1 name.<br>
<dael> TabAtkins: Closely related but syntax is difference. If allowing to modify they need to be 2 objects<br>
<dael> astearns: For blockless do we need object to represent that or multiple blockless each with one name<br>
<dael> TabAtkins: Don't have precedent for single rule expanding to multiple. Not impossible, but prefer avoid<br>
<dael> astearns: Sounds to me like need 2 objects, one for blockless and one for block<br>
<dael> astearns: Other comments on just that? Then figure out mutability and errors. Single or 2 objects. Anyone continuing to argue for single?<br>
<dael> astearns: Prop: We will have 2 separate objects; one for rules w/o a block and one for rules with a block<br>
<dael> astearns: Obj?<br>
<dael> RESOLVED: Prop: We will have 2 separate objects; one for rules w/o a block and one for rules with a block<br>
<dael> astearns: Object with a block we should be able to add. For blockless should we add an error or should it not have methods?<br>
<dael> TabAtkins: Won't have methods. No child or insert rule<br>
<dael> astearns: miriam anything else on this? Or should we go with resolution and see what we need on future calls<br>
<dael> miriam: Nothing else<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6576#issuecomment-937246847 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 October 2021 22:15:16 UTC