- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Feb 2021 23:41:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade] Cascade layers need an import syntax`, and agreed to the following:
* `RESOLVED: Cascade layer imports is done using @import followed by URL followed by layer declaration`
<details><summary>The full IRC log of that discussion</summary>
<Rossen_> Topic: [css-cascade] Cascade layers need an import syntax<br>
<myles> ScribeNick: myles<br>
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5681<br>
<myles> miriam: We have this in the spec as an option for how you write the @layer rule. You can include a URL in the layer. In @layer, and it it works similar to an import. But there have been questions about whether we should instead extend the existing import to allow layer names, or even come up with a 3rd option.<br>
<myles> miriam: A new import layer rule that is different from @layer or @import.<br>
<myles> miriam: What's in the spec now is @layer can take a URL.<br>
<Rossen_> q?<br>
<myles> Rossen_: ok.<br>
<myles> Rossen_: Is that the current proposed syntax... do you just want feedback from the group?<br>
<myles> miriam: Some people had a preference for extending @import. I don't have strong feelings on this. I think it works nicely to keep it all in @layer. We'll need to allow @layer before @import because it's important that layer names are able to be established early.<br>
<bkardell_> I also don't have strong feelings, but I like @import'ing being import I guess<br>
<myles> Rossen_: How does @layer differ from @import?<br>
<myles> miriam: @layer imports a stylesheet into a layer. It allows you to add layering while you're imorting<br>
<myles> fantasai: @import doesn't establish any layers. It just puts rules into the stylesheet as if they are inlined. @layer creates a layer for things inside it, but doesn't inline them. In theory we can say @layer can take @import inside the nested block, but then you have to deal with the fact that @import has to be the first thing in the stylesheet, so it's complex. So the syntax should be "this statement creates a layer and imports a stylesheet into<br>
<myles> it" as if it was @layer with an @import inside it.<br>
<Rossen_> q?<br>
<myles> fantasai: do we use @import with extra syntax? Or do we allow @layer to take a URL instead of a block of rules.<br>
<emilio> q+<br>
<jensimmo_> q=<br>
<jensimmo_> q+<br>
<myles> florian: Sticking to @layer is better. 3 variants: @layer name;, @layer layername {...}, @layer layername url. There is symmetry between 3 variants.<br>
<myles> florian: It's self-contained and clean.<br>
<bkardell_> q+<br>
<Rossen_> ack emilio<br>
<myles> emilio: would that layer syntax have the same restrictions as @import? For appearing before other rules?<br>
<myles> fantasai: yes.<br>
<myles> emilio: *not* doing that means we have to teach prescanners.<br>
<myles> fantasai: It's defined as it has the same placement as @import.<br>
<Rossen_> ack jensimmo_<br>
<myles> emilio: it's ok then<br>
<myles> jensimmo_: It's convenient for authors to put it anywhere, though<br>
<myles> fantasai: @layer name {...} can go anywhere. @layer name url can only go at the top.<br>
<myles> jensimmo_: @layer name url might not need restrictions, which would be valuable<br>
<myles> astearns: Maybe we should use @import for that case, then, to make the restrictions simpler<br>
<myles> fantasai: We already have precdent for putting @layer anywhere. IT's just the one with {} can go anywhere. I'm leaning to have all 3 have the saem syntax for consistency. Because otherwise we would have 2 placement rules, which would be weird.<br>
<Rossen_> q?<br>
<myles> bkardell_: i don't understand something.<br>
<fantasai> s/{} can go anywhere/{} can only go after any importing rules/<br>
<myles> bkardell_: In "other options" there is @layer reset with a nested import. Does emilio's comment mean it's not possible?<br>
<myles> emilio: Please let's make it not possible<br>
<myles> bkardell_: Let's remove that as an option then<br>
<myles> bkardell_: So the options are using @layer or using @import. that's it.<br>
<myles> bkardell_: I'd like @import to be about importing, and having a special version of import which can also create a layer. But I don't have strong feelings.<br>
<Rossen_> q?<br>
<Rossen_> ack bkardell_<br>
<myles> fantasai: This is a naming discussion.<br>
<myles> Rossen_: Yes and but it feels like a bit more. @import is already rather understood and well-used by the community.<br>
<myles> Rossen_: Having yet another mechanism to import seems odd.<br>
<myles> florian: We're having yet another mechanism to import anyway. We're just discussing syntax.<br>
<myles> Rossen_: Explicitly yes.<br>
<astearns> either one is fine by me - slight preference for @import<br>
<myles> Rossen_: Alright, so. Let's try to move this forward and get to a conclusion. Most people were in favor of @layer. A few who prefer @import to be used for import: namely: bkardell_ and Rossen_ . But for me it's just a preference; I can live with @layer.<br>
<myles> bkardell_: You articulated the way i feel. I feel like people understand the limits of @import, and we have machinery to do those limits already. Playing into that is goodl.<br>
<myles> emilio: Another benefit of @import is we don't have to come up with OM thing to hold stylesheets. I lean toward re-using @import<br>
<myles> astearns: We need OM changes anyway<br>
<myles> emilio: We need to change the conditon. We have a proposal for @import-supports. So we need to expose that "import conditoin" or "import layer" but that seems like an easier change than exposing a CSS layer rule that may have a URL or not, and may have an inner block or not, or inner stylesheet or not.<br>
<myles> Rossen_: That was the motivation behind my preference as well. They have the same behavior from importing POV. In the future, when we extend @import, we have to make a parallel change in something else too.<br>
<myles> emilio: That's a good point. We have proposals for @import-cross-origin to maek cross-origin requests. WOuld be good to not duplicate<br>
<myles> TabAtkins: I agree, and am strongly for using @import.<br>
<jensimmo_> q+<br>
<myles> florian: There are variants. @import layer (name url). Or @import url as layername. Which is more readable, but couldn't deal with unnamed layer (unless we add a new keyword meaning "import as unnamed") which wouldnt' mean "import into the layer named 'unnamed'" but instead "import into unnaemd ...."<br>
<argyle> https://github.com/w3c/csswg-drafts/issues/5681#issuecomment-755513963<br>
<myles> Rossen_: what are you talking about<br>
<myles> florian: Una suggested something that seems both more readable and not working in the unnamed layer case.<br>
<florian> @import layer reset url(reset.css);<br>
<florian> @import layer(reset) url(reset.css);<br>
<florian> @import url(reset.css) as layer;<br>
<Rossen_> q?<br>
<argyle> `@import reset from url(reset.css) as layer;`?<br>
<myles> jensimmo_: There are 2: one is to add another keyword or whatever it's called to the import statement to say which layer it goes to, and the other which is about nesting @layer reset (@import url). I keep going back and forth. THere's something about how clear it is that you start a layer, when you define a layer, you import a stylesheet. THat's appealing. But I also understand the keyword would still work well.<br>
<Rossen_> ack jensimmo_<br>
<myles> jensimmo_: I'm leaning toward nesting.<br>
<myles> Rossen_: Now we're swinging the other way.<br>
<Rossen_> @import layer reset url(reset.css); @import reset url(reset.css) as layer; @import layer(reset) url(reset.css);<br>
<myles> fantasai: My preference would be for whatever syntax we choose to have the word "layer" in there somewhere. We need a way to have unnamed layers for parallelism. MOst of the parameters for our @import rules come after the @import rules (conditions, parsing) is a little bit open-ended. It might make more sense to do this before the URL and it also brings up tot he front and makes it obvious "we are making a layer with this URL". SO my preference is<br>
<myles> one of the earlier options.<br>
<myles> Rossen_: I pasted the 3 variants that are in the issue.<br>
<myles> jensimmo_: por que no los dos?<br>
<myles> Rossen_: <lists the 3 options verbally><br>
<myles> emilio: Can we add a 4th one? @import url something something layer(something)<br>
<myles> emilio: reasoning: that's how the extra things to @import work already. like media queries.<br>
<myles> fantasai: THat would parse as an invalid media query, and it would get imported anyway whether or not you support layer<br>
<Rossen_> @import url(reset.css) as layer(reset)<br>
<myles> emilio: We have that issue for the proposed @supports function, right. I'd like to have the mandatory parts at the front, like @import url, then the optional stuff like the conditions<br>
<myles> Rossen_: where does the @support go in this case.<br>
<astearns> what was the 'both' you were asking about, jensimmo_ ?<br>
<fantasai> https://www.w3.org/TR/css-cascade-4/#conditional-import<br>
<myles> emilio: I think we resolved on this at the end, but it's not in the spec. It goes where the media query goes. Which is weird cause you text can mean either<br>
<myles> Rossen_: Without dumping the whole issue into this one, wasn't the issue to have @supports evaluated so you're not hitting the network? The current solution is to have @supports at the end?<br>
<fantasai> https://www.w3.org/TR/css-cascade-4/#at-import<br>
<myles> emilio: yes. We added an @supports function.<br>
<fantasai> Current syntax is @import [ <url> | <string> ]<br>
<fantasai> [ supports( [ <supports-condition> | <declaration> ] ) ]?<br>
<fantasai> <media-query-list>? ;<br>
<jensimmo_> Could we do `@import layer(reset) url(reset.css);` AND `@import url(reset.css) layer(reset) ;` AND @layer reset {<br>
<jensimmo_> @import url(reset.css); }<br>
<myles> emilio: With the function syntax it's possible. You just determine if it's this function or not, and if it's not, then assume it's something else.<br>
<myles> jensimmo_: What is the precise syntax for namign the layer? I like haivng layer() and reset. THat would allow us to use layer with 2 parens and no name and leave it blank to do what fantasai was metnioning to assign it to a named layer without it being too messy. And having the name of the layer an argument to a function, it might not matter which name comes first<br>
<myles> jensimmo_: I also was trying to say, would it be possible to do an import statement with a way to namet eh layer *and* CSS does both so authors cna pick which ever way they want to do it, or and the nested @layer { @import ... }<br>
<Rossen_> q?<br>
<Rossen_> ack f<br>
<florian> q+<br>
<myles> fantasai: My concern with the nested one is you'd be tempted to put declarations there. IN theory you could do that once, but then you coudln't put further @import rules. So then you 'd have @layer blocks which don't include any declarations, and if you do, then it becomes invalid, so it will be confusing. I dont' want to give the author the impressino they can put rules in the block. they can't do that.<br>
<TabAtkins> @import currently has a req that it comes first in a file, which lets impls pretend that the imported files are ordered fully before its importing file (they dont' have to track nesting of imports for purpose of figuring out source order of declarations)<br>
<Rossen_> ack f<br>
<myles> florian: Assuming we go with @import, esp. for extension ability. It shouldn't be after the rule. Because it's syntactically ambiguous with media queries. We don't want something to parse both as a layer and as a media query, that's bad<br>
<myles> emilio: we already do that with supports, right?<br>
<fantasai> Also, everything after the URL is currently a condition. This isn't a conditional.<br>
<TabAtkins> @layer { @import} doesn't impose this restriction.<br>
<myles> emilio: fantasai pasted the supports syntax now. It would only be ambiguous if you add a layer() function into media queries. but not otherwise<br>
<myles> florian: But supports and layer are conditional things, they belong in roughly the same place, so i'm still uncomfortable with thtat, but less so<br>
<myles> emilio: I don't mind much either way. It would be slightly nicer, given all browsers have bespoke @import preload parseing, and scan for literally "@import string" and then preload that, I would be slightly happier if we didn't have to add harder parsers, because that code is pretty ugly already.<br>
<myles> emilio: I don't know.<br>
<myles> Rossen_: Let's try to resolve.<br>
<fantasai> Wouldn't you want your speculative loader to parse conditions on the @import?<br>
<myles> Rossen: Let's try to record a resolution here. It will be easier to revisit the specific syntax of where the layer declaration goes if we're not happy with it later, but at least it seems we're all leaning toward where the declaration goes with @import.<br>
<myles> Rossen: emilio, your proposal is @import url layerstuff?<br>
<myles> emilio: <silence><br>
<myles> Rossen: Is that something we can start working with?<br>
<myles> s/emilio: <silence>/emilio: yes/<br>
<emilio> fantasai: yeah, that is right (I think right now we just don't preload conditional stuff)<br>
<jensimmo_> @import url(reset.css) [layer stuff];<br>
<myles> RESOLVED: Cascade layer imports is done using @import followed by URL followed by layer declaration<br>
<jensimmo_> @import url(reset.css) layer(reset) ;<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5681#issuecomment-777868916 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 11 February 2021 23:41:06 UTC