- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2023 23:53:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Multiple stylesheets per file`, and agreed to the following:
* `RESOLVED: Accept @sheet with URL fragment referencing rule. Exact details to be in the Cascade spec`
<details><summary>The full IRC log of that discussion</summary>
<dael> TabAtkins: There have been a few requests in this space before. Various reasons why you might want a bunch of independant stylesheets and ship as one file. Reduce costs, benefit from compression. Want custom components that relate.<br>
<dael> TabAtkins: Prop in this thread to allow this in CSS. Initial approach focused on JS imports but varient later<br>
<dael> TabAtkins: Prop is a new @ rule @sheet that takes a stylesheet and a name. Syntax inside @sheet is that of a top-level stylesheet. If you use the top level stylesheet directly you only get unnamed sheets. Can access named sheets with fragment on URL<br>
<dael> TabAtkins: When importing or @import you can use the fragment and we'll interpret as a sheet name and grab that one sheet from the larger sheet<br>
<dael> TabAtkins: I think convenient and minimal way to address use case. Thoughts, objections, questions?<br>
<Rossen_> q?<br>
<dael> plinss: What if you have top level entities that aren't @sheets<br>
<dael> TabAtkins: They're part of the top level sheet<br>
<dael> plinss: @sheets are just rules to top level stylesheet?<br>
<dael> TabAtkins: Could go either way. Either OM reflects normally and things in @sheet don't apply or a new list that exposes. Both sound plausable<br>
<dael> plinss: If you use a top-level sheet nested sheets are ignore?<br>
<dael> TabAtkins: Yep<br>
<dael> plinss: Okay. in general in favor<br>
<Rossen_> ack fantasai<br>
<dael> fantasai: Why wouldn't you apply all by default and than option to not apply? I feel like if I was pulling a sheet and it had a bunch of rule expect all to apply<br>
<dael> TabAtkins: Could go either way. I think it makes sense if write as independent so you don't intend them to be used together. But I don't think anything wrong with allowing them to be used together. not sure how parsing of namespace applies in the same sheet<br>
<dael> fantasai: You have ability to apply 2 already. Apply all is extension of that<br>
<dael> TabAtkins: namespace rules should only be sheet they're in<br>
<dael> TabAtkins: Related, any context in the outermost sheet like fontfaces shouldn't apply to the ones inside b/c otherwise it's unpredictable. That leads me to confusing to all apply<br>
<dael> fantasai: I don't think so. It's like I concat a bunch of sheets. That's the premise you started with. @fontface is not to a single sheet. Only namespace is file scope<br>
<dael> plinss: Concerns if we allow all by default you have reules, @sheet, more rules and then you have conflicts where you've got same specificity and what wins. You could end up with situations that surpsise. I'm fine to explore<br>
<dael> TabAtkins: We have limits for that specificity reason. You need to allow imports in @sheet and that introduces that ability we disallowed<br>
<dael> plinss: We'd need to give it more thought<br>
<dael> fantasai: Could just make it invalid<br>
<dael> fantasai: If you have a style rule or @media that's not allowed before @import and you put an @import it's ignroed. We could put that @sheet after something is ignored. If it's out of place it's ignored.<br>
<dael> TabAtkins: That means you can't use @import and @sheet unless it's the first @sheet unless you load independently<br>
<dael> plinss: Clarification, it sounds like you're saying @import @sheet rules @sheet and the first @sheet would be in top level but second wouldn't?<br>
<dael> fantasai: 2nd is invalid<br>
<dael> plinss: Would be ignore<br>
<dael> plinss: Second is I presume @import in the nested sheets that's a fragmenet of the other sheets would work regardless of where it shows?<br>
<dael> TabAtkins: Inclined to say yeah. need to do cycle checking<br>
<dael> plinss: Then you could always say we don't by default but you can import them into the top<br>
<dael> TabAtkins: That makes sense. That's pretty good. WOuld avoid my issues b/c your imports would be loaded as sep. stylesheets at top level<br>
<PaulG> q+<br>
<dael> plinss: Right @import #foo and than #sheet foo and the sheet is hoisted in as a separate document<br>
<TabAtkins> @import "#foo"; @sheet foo {...}<br>
<dael> Rossen_: Is this something that we can summarize as a resolution?<br>
<dael> TabAtkins: Resolve to accept @sheet with URL frag referencing rule. Exact details to be in the spec<br>
<Rossen_> ack PaulG<br>
<dael> PaulG: Coming from outside I think my confusion would be with layers and how this differs. Can layers be used instead of sheets to achieve the import mechanic? My concern is there is two syntaxes doing similar things<br>
<dael> fantasai: Layers effect how rules cascade. Not so much about organizing the style where it is in a file. They change presedence of rules. THis is eq. of @import where you can include rules from one file to another<br>
<dael> TabAtkins: Solely a bunching helper as opposed to layers which impact cascade<br>
<dael> PaulG: Is the concern there when you bring in stylesheet 1 and 2 they can conflict between rules?<br>
<dael> TabAtkins: They do. You can import with a layer to order them and that works here<br>
<dael> PaulG: Not clear on what's being solved for. Purely the addressing of the rules by file orgnization?<br>
<dael> TabAtkins: If you have need for several distinct sheets like custom components in HTML but you don't want n different requests, this solves that problem<br>
<dael> PaulG: Okay, thank you<br>
<dael> plinss: JS import would like you import one of the nested sheers<br>
<dael> TabAtkins: Right<br>
<dael> Rossen_: Prop Resolve to accept @sheet with URL frag referencing rule. Exact details to be in the spec. Additional thoughts or objections?<br>
<dael> TabAtkins: I'm guessing this goes into cascade?<br>
<dael> fantasai: That's what it feels like<br>
<dael> RESOLVED: Accept @sheet with URL fragment referencing rule. Exact details to be in the Cascade spec<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-1498299448 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 April 2023 23:53:14 UTC