- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 17:23:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Proposal: CSS @sheet`, and agreed to the following:
* `RESOLVED: Add kurt as editor of css-cascade`
<details><summary>The full IRC log of that discussion</summary>
<emilio> slides: https://docs.google.com/presentation/d/1zE9NgFltry9Qor6ajT695wZiN74zEpydtc1oEbzlhOw/edit#slide=id.p<br>
<emilio> kschmi: justin proposed this in 2020<br>
<emilio> ... great discussion in 2023 where there was a resolution to add it to css-cascade<br>
<emilio> ... and we have some suggestions to expand it<br>
<emilio> ... so I want to touch on those<br>
<emilio> ... quick recap<br>
<astearns> new explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtSheet/explainer.md<br>
<emilio> ... main initial goal is bundling<br>
<emilio> ... non-obvious is that this is not obvious but this helps compression rations<br>
<emilio> ... if you can combine more things into one file dictionaries you get more hit<br>
<emilio> ... some testing gives 0.4% compression improvements, so not massive but not nothing<br>
<emilio> ... the important thing I want to go through is that there's a solution for sharing inline styles with declarative shadow DOM<br>
<emilio> ... core concept was resolved in 2023<br>
<emilio> ... where we allowed to reference fragments<br>
<emilio> ... not yet in the cascade spec<br>
<emilio> ... so that was the original proposal<br>
<emilio> ... so you have an `@sheet` block with an identifier and you can import them with a constructable stylesheet<br>
<emilio> ... so that's kinda the bundling scenario. The CSS bits are a pre-requisite<br>
<emilio> ... but we can't get the JS part until CSS adds the syntax<br>
<emilio> ... so `<link rel=foo.css#fragment>` and also `@import`<br>
<emilio> ... so it can cache the file and only make one request<br>
<emilio> q+<br>
<emilio> ... hasn't been spec'd yet, but I think that's worth doing independently<br>
<emilio> ... but the extension is why doesn't this work for same-page URL<br>
<noamr> q+<br>
<emilio> ... so plain fragments would work on inline styles<br>
<fantasai> scribe+<br>
<bramus> scribe+<br>
<astearns> ack emilio<br>
<fantasai> emilio: 2 things that come to mind<br>
<fantasai> emilio: 1. Why is this CSS-specific, in the sense that other resources ... including fragments and stuff<br>
<fantasai> emilio: This introduces quite a divergence in how we interpret URLs<br>
<fantasai> emilio: What you're proposing feels a bit weird because a plain fragment URL usually references the same document<br>
<fantasai> emilio: I guess we do have some precedent for some fragment-only URLs being a bit special<br>
<fantasai> emilio: One thing I'm concerned about, how does this behave-- if a browser doesn't implement it, the browser pulls the whole stylesheet and ignores it<br>
<matthieud> q+<br>
<fantasai> emilio: it would import nested stylesheets<br>
<fantasai> emilio: feels like a more explicit mechanism here would be nice, but maybe we can live with this?<br>
<fantasai> emilio: I'm a bit worried about feature detection and fallbacks<br>
<fantasai> scribe-<br>
<astearns> q+ justin<br>
<astearns> ack noamr<br>
<miriam> We allow `supports()` in imports<br>
<bramus> noamr: When i see the # i expect it to be an id<br>
<bramus> … mixes html and css too much<br>
<bramus> … would prefer so,meting that has a sheet attr on link<br>
<bramus> … and other modifier to import, we have one for layer<br>
<bramus> … in general would be careful to use hasehs for sth that is not dom id<br>
<bramus> … confuses things<br>
<florian> q?<br>
<bramus> kurt: fragment already acceptd in prior discussion<br>
<bramus> … mgiht need to be revisited<br>
<bramus> … if fragment does work, much like acnhors you dont need a URL it means local<br>
<florian> q+<br>
<bramus> … this is building on that<br>
<bramus> … there’s a precedent: if there is no file assume it is in the same doc<br>
<bramus> … only thing doing that is anchors, which is excepction to a lot of things<br>
<bramus> … if we do revisit fragment for this scenario, then we need to revisit for this<br>
<bramus> … other syntax or attr … would feel inconsistsent to not do this<br>
<bramus> noamr: wnated to say that it is different<br>
<bramus> … fragmetns and svg clip path and shapes – there are precedents but they refer to the dom id<br>
<bramus> … no prob with multidoc<br>
<astearns> ack dbaron<br>
<bramus> dbaron: from a URL design perspective the meaning of a fragment is generally specific to the mime-type of th resource<br>
<fantasai> +1 dbaron<br>
<bramus> … the idea that in a css file to refer to an @sheet can be sensible<br>
<justinf> +1 as well<br>
<bramus> … and in an HTML file they already refer to IDs and we should be very careful about changing that<br>
<bramus> … I could imagine with an @sheet inside a style element, and then use the id of the style element<br>
<justinf> fragments without a preceding URL refer to something in the HTML document already<br>
<bramus> … one of the design principles here is the meaning of fragment in a URL is specificy to the mime-type<br>
<emilio> q+<br>
<bramus> kurt: makes sense<br>
<bramus> … we do have a .css file in this example<br>
<bramus> … but there is HTML and there is a mismatch witht he mimetype<br>
<ydaniv> q+<br>
<bramus> … great point<br>
<noamr> +1, exactly, I have no problem with it inside CSS files<br>
<astearns> ack matthieud<br>
<bramus> matthieud: answer for emilio about old browser<br>
<bramus> … that dnt udnerstand @sheet<br>
<castastrophe> q+<br>
<bramus> … how to resolve the rules inteh block<br>
<emilio> ... So re. what happens for all browsers, are we going to lose all the rules<br>
<bramus> … same solution with @layer can be applied<br>
<emilio> ... but we could make like @layer where anything after is considered part of it<br>
<emilio> ... so this looks a lot about @layer<br>
<emilio> ... just with no notion of priority\<br>
<fantasai> emilio: Concern is not only with what's in the block<br>
<bramus> emilio: concern is not only what happens with contents of the blocks but older browser dont have concept of importing parts of a stylesheet<br>
<bramus> … external parts would apply<br>
<bramus> matthieud: doesnt work for ???<br>
<bramus> emilio: but doesnt work for link either<br>
<ydaniv> q-<br>
<emilio> s/???/@import<br>
<astearns> acj justinf<br>
<emilio> ack justin<br>
<emilio> justinf: Wanna comment on the fragment thing<br>
<matthieud> I would have like an answer about the @layer vs @sheet though ?<br>
<emilio> ... has been touched that the impolicit URL is the HTML document url<br>
<emilio> ... being able to do about dom vs. stylesheet<br>
<emilio> ... on the DSD case there could be multiple sheets<br>
<emilio> ... and in order to do this we have to have a central resource<br>
<emilio> ... and I'd be a bit wary of this<br>
<emilio> ... there's also a question of external stylesheets with nested @sheets<br>
<emilio> ... it's something I'd want to avoid, we're trying to avoid global resources like custom element names or what not<br>
<emilio> ... so I wouldn't add another one<br>
<astearns> ack florian<br>
<emilio> florian: narrowly on this specific slide, as long as @sheet is something that exists I agree it'd be nice to use it on inline styles<br>
<noamr> For the `#` - it can be `#:~:sheet=the-sheet-name` like text fragments<br>
<emilio> ... slightly more generally I think this is quite complex and we need to move into the discussion of what this does for shadow dom<br>
<emilio> ... yeah it's convenient to have one file with preprocessing<br>
<emilio> ... http/2 deals with some of the multiple request complexity<br>
<astearns> ack emilio<br>
<justinf> for shadow DOM basic bundling is sufficient, IMO<br>
<florian> s/use it on inline styles/use it on inline style elements<br>
<emilio> ... so outside of shadow dom I don't see a lot of use for this<br>
<bramus> emilio: agree with florian that main use case feels … basically about shadow dom. if you have no, you can bundle and call it a day<br>
<bramus> … want to try a counter proposal tha tmight work<br>
<bramus> … and doesnt need to add anything new<br>
<bramus> … except 1 thing<br>
<bramus> … what you really want is @import but without separate request to import into shadow dom<br>
<bramus> … talked about removing constructbile stylesheet restircition in adoptable ones<br>
<bramus> … if you have data-uri @import that you could import into SD you kinda get this behavior<br>
<bramus> … not user friendly, but if use case is bundlers then they can prolly manage<br>
<bramus> … idea would be to get the @import stylesheet and shadowroot.adopted.push(…)<br>
<bramus> … and if you dont want that to aply to the doc, you could isable with a non-mathcing media in the elem<br>
<justinf> q+<br>
<bramus> … we have a lot of similar pieces that would be nice<br>
<bramus> … if use cases are narrow, e.g shadow dom and bundling<br>
<bramus> … then you might be able to get away with this<br>
<bramus> … has that been explored?<br>
<bramus> q?<br>
<justinf> isn't that unwinding the whole proposal, including the previous resolutions?<br>
<emilio> yes<br>
<astearns> ack castastrophe<br>
<justinf> `@sheet` seems a lot simpler than data URI and changes to import to me<br>
<emilio> castastrophe: just a question, trying to picture things in the design systems space<br>
<emilio> ... how would you import multiple sheets, multiple `<link>` or `@import`?<br>
<emilio> kschmi: yeah you'd need multiple sheets or @import or both<br>
<astearns> ack justinf<br>
<emilio> justinf: Responding to emilio or florian... The basic @sheet to me is very simple<br>
<emilio> ... there's no way currently to include an inert chunk of CSS<br>
<emilio> ... turns out you can with @supports<br>
<emilio> ... but @import + data uri + ... feels a lot more complex than @sheet<br>
<emilio> ... The additional complexity is adding ways to reference these from inline styles<br>
<emilio> ... I don't think that complexity applies to that part of the proposal<br>
<emilio> FWIW `@import url("data...") not all;` doesn't seem /terribly/ complex to me<br>
<emilio> kschmi: so re. shadow dom<br>
<justinf> but then you need that `@import()` to 1) be inert, and 2) be importable as a separate sheet<br>
<emilio> ... current mechanism are duplicate `<link rel>` or inline styles or script-based adoptedStyleSheets<br>
<emilio> ... so for declarative shadow DOM is not great<br>
<emilio> ... If we support the standalone fragment we can support it for declarative shadow dom<br>
<emilio> ... that's kinda why this is relevant to DSD<br>
<emilio> ... solves that messy problem r/n<br>
<noamr> q+<br>
<emilio> ... big question justinf is concerned about is scoping<br>
<justinf> q+<br>
<emilio> ... which is an issue, might be the same as inheriting from parent<br>
<emilio> ... lots of open issues, we have an explainer in MSEdgeExplainers<br>
<emilio> ... big list of open issues, but key problem we're solving is inline styles with declarative shadow dom<br>
<emilio> ... another solution for this would be declarative CSS modules<br>
<emilio> ... `<script type=css-module>` and `adoptedstylesheets=""`<br>
<emilio> ... TAG pointed to `@sheet`<br>
<emilio> ... seems this still has more issues<br>
<emilio> ... If we could get this standalone fragment thing would be nice<br>
<emilio> ... both seem good proposals, but I think there's a big demand to solve this<br>
<emilio> ... so there's shared goals, but they can solve the same problem<br>
<emilio> ... curious to see what the WG and developers prefer<br>
<emilio> ... that was more or less it<br>
<emilio> q+<br>
<emilio> ack noamr<br>
<justinf> noam +1<br>
<emilio> noamr: When I see this whole thing I see it like an HTML problem and not a CSS problem<br>
<emilio> ... You can fix this with shadow DOM if you have a fragment refer to an ID in your document<br>
<emilio> ... it seems also a problem with script importing<br>
<fantasai> s/ID/ID of a <style> or <link> element/<br>
<emilio> ... maybe we can present this at WHATNOT<br>
<fantasai> +1 noamr<br>
<emilio> ... But I wonder if there are commonalities to importing style and script<br>
<emilio> ... and there are solutions that could require less work<br>
<emilio> kschmi: Yeah if there was a way like svg fragment you're right we wouldn't need @sheet for this<br>
<justinf> the only issue with IDs with DSD is that we need a *global* ID to cross shadow root boundaries. But that's a DOM issue<br>
<emilio> ... We could have an attribute<br>
<emilio> noamr: you'd add a link pointing to the ID<br>
<castastrophe> q+<br>
<astearns> ack justinf<br>
<emilio> justinf: re. the scoping, one of the reasons I was shaking my head with scoping<br>
<emilio> ... we want to render instances, in a way that the root needs to hold the stylesheet of component a, but you don't want to emit them until you've found the first<br>
<emilio> ... so I think we need some sort of global resource<br>
<emilio> ... but I'd be very careful about choosing what global resource<br>
<noamr> for bundling, you can have an external HTML file that has multiple <style> elements with IDs and you refer to them<br>
<emilio> ... but I agree with noamr that this is kind of an HTML issue, because IDs don't propagate across shadow boundaries<br>
<bramus> emilio: wanted to ask whether other subresources have same nees<br>
<bramus> … but tha t is what noam ended up asking<br>
<astearns> ack emilio<br>
<astearns> ac castastrophe<br>
<astearns> ack castastrophe<br>
<emilio> castastrophe: had a question about @sheet, the syntax makes me think that if I wanted to override a sheet namespace I would be able to<br>
<emilio> ... with the fragment syntax it makes me feel like you can't<br>
<emilio> ... if I declare another ID in the DOM it doesn't override the first<br>
<emilio> ... what is the behavior here?<br>
<emilio> kschmi: That's one of the open questions<br>
<florian> q+<br>
<emilio> ... @layer would add to it<br>
<astearns> ack fantasai<br>
<astearns> ack florian<br>
<emilio> florian: I find the shadow dom use case very compelling<br>
<emilio> ... more compelling than the other use cases<br>
<emilio> ... if we agree to solve it with @sheet it motivates solving some of the `@sheet`s<br>
<emilio> ... issues<br>
<emilio> ... the way @sheet is imported seems problematic<br>
<emilio> ... browsers doing different things for `url(#foo)` seems like a problem<br>
<emilio> ... the overriding is question is a challenge as well<br>
<castastrophe> q+<br>
<emilio> ... the shadow dom use case seems the most compelling, the other ones seem nice<br>
<emilio> ... if we decide to solve the shadow dom use case some other way, not sure we want `@sheet`<br>
<justinf> this difference in behavior with legacy browser is always the case... I'm personally hoping that @sheet support can coincide with CSS imports support in Webkit and Gecko so that if you can import a stylehsheet you can also import an `@sheet`<br>
<emilio> kschmi: Great points, I think the original proposal was about importing / bundling<br>
<noamr> justinf: I think hash-fragments, e.g. in same-document links, cross shadow boundaries?<br>
<emilio> justinf: this is an addon to JS import asserts in CSS modules<br>
<emilio> ... you have a lot of JS modules which depend on small fragments on CSS<br>
<emilio> ... but bundlers don't know how to deal with bundling CSS there<br>
<emilio> ... that was my main motivation, you end up with lots of small CSS files otherwise<br>
<emilio> ... was kinda hoping that if @sheet is simple enough it'd ship along CSS imports in webkit / gecko<br>
<miriam> q+<br>
<emilio> ... happens to be a simple polyfill for transforming to @import<br>
<astearns> ack castastrophe<br>
<justinf> transforming to @supports, not @import<br>
<emilio> castastrophe: I see where you're coming from florian<br>
<emilio> ... if we solve it for webcomponents my preference would be to solve it for native DOM solutions as well<br>
<bramus> Big +1<br>
<emilio> ... I'm doing so much transforming of code between the two systems, so it'd be nice to allow authors to just write it once<br>
<astearns> ack miriam<br>
<justinf> btw, CSS imports is mainly a feature that makes CSS more usable from JS defined components... it doesn't need to be web components or shadow DOM<br>
<emilio> miriam: high level syntax thought, there was some mention of syntax looking similar to @layer, but funcitonality is entirely different<br>
<emilio> ... I think it overlaps more with @scope<br>
<justinf> q+<br>
<noamr> +1<br>
<emilio> q+<br>
<emilio> kschmi: Yeah the way I think about @sheet is a separate file<br>
<matthieud> actually yes I agree, @scope is closer to this than @layer<br>
<emilio> ... @layer is a different cascade layer, and that's why you can have multiple layers and so on<br>
<emilio> ... @sheet is only one definition per sheet, that kinda helps my mental model a bit<br>
<emilio> matthieud: I agree that @scope is closer than @layer<br>
<emilio> ack justinf<br>
<astearns> ack justinf<br>
<emilio> justinf: Wanted to comment, I wanted to make sure that this is not always associated with shadow dom and webcomponents<br>
<emilio> ... having a way to import this seems useful for non-shadow-dom related use cases as well<br>
<emilio> ... so I'm hoping this would be much broader<br>
<bramus> (FWIW: I believe @layer was only mentioned in relation to what browsers do when they don’t support it: they discard the entire block.)<br>
<emilio> ack emilio<br>
<astearns> ack emilio<br>
<bramus> emilio: want to suggest that if we are doing this we could bypass a lot of the fragment issues if we allow importing using a different syntad<br>
<emilio> @import sheet(name)<br>
<bramus> s/syntad/syntax<br>
<bramus> emilio: that bypasses a lot of the questions about what the fragment means<br>
<castastrophe> or both? @import url() sheet()<br>
<florian> +1<br>
<bramus> justinf: still seems to have the global namespace<br>
<weinig> (not sure if this has been mentioned, or how relevant it is, but there is a some written thoughts on fragments here -> https://www.w3.org/TR/fragid-best-practices/)<br>
<bramus> emilio: that’s kinda ???<br>
<emilio> castastrophe: +1 to emilio, you could combine it with url and specify different sheets from that URL<br>
<bramus> emilio: that wouldn have global namespace issues<br>
<bramus> … because you arkimporting this sheet from that url<br>
<bramus> justinf: depends on … declarative dom use case (missed)<br>
<bramus> emilio: guess you could with no URL you import the document or some smaller thing<br>
<bramus> … if you ignore the improt and inline style hting, it still works for declarative shadow dom<br>
<noamr> Perhaps "importing from inline" and "partially importing from a sheet" don't require the same solution?<br>
<bramus> … do `@import url() sheet()`<br>
<bramus> justinf: if you can do that, solves 99% of ht eproblems<br>
<bramus> … if you can bundle all, you can do ahead of time and import later<br>
<noamr> q+<br>
<justinf> q+<br>
<bramus> kurt: challenge with file specific syntax is what justin was saying – need to support same doc styles<br>
<astearns> Zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<bramus> … you want a high per site to paint auickly with styles<br>
<bramus> … best option is not an external file<br>
<bramus> … that is feedback i got from devs<br>
<bramus> … "sure separte file is nice, but inline in html is powerful for first paint"<br>
<astearns> ack noamr<br>
<emilio> `<style>@import url(..) sheet(..)</style>`<br>
<bramus> noamr: seems like different problem?<br>
<astearns> ack justinf<br>
<emilio> justinf: wanted to clarify on `<stlye>`. In a server component case you don't have all the components, they depend on the page<br>
<emilio> ... something like an amazon product page is a canonical example<br>
<emilio> ... could render millions of components<br>
<emilio> ... I don't think any external file solution deals with that<br>
<bramus> emilio: they are not exclusive<br>
<bramus> … as noam was saying, having a specific syntax to import sheets and being able to import from an inline style seem like differnet<br>
<bramus> justinf: agree<br>
<bramus> … would love to see capabitliy in html<br>
<bramus> emilio: ok<br>
<bramus> … then we are in agreement<br>
<bramus> florian: you emilio are proposing to solve with css syntax, not html<br>
<bramus> emilio: i was proposing to have specific syntax for importing style sheet from a file<br>
<bramus> … tha tdoes not avoid adding that fro m???<br>
<bramus> florian: if you have @import url() sheet() it imports tehs eet fro,m the url<br>
<bramus> … if you omit the url, its from the current file<br>
<bramus> … if the curernt file is the html, then that is where you try and go find it<br>
<bramus> emilio: or you could impor from url(#something) to refer to that style or link<br>
<castastrophe> q+<br>
<bramus> florian: the syntax you proposed not only is useful but fully replaces need for link rel=stylesheet and makes it not an html problem<br>
<bramus> emilio: still need to define how to target a partciular element<br>
<noamr> import url("#my-inline-style") sheet(my-sheet)<br>
<bramus> castastrophe: if you are inside sd with import, do you have timport @import from sd or from parent?<br>
<bramus> … does not exist right now<br>
<bramus> noamr: url fragment are not ???<br>
<bramus> astearns: should prolly close this for now<br>
<emilio> noamr: URL fragments do cross shadow boundaries, like `<a href="#foo">` doesn't look only inside its shadow tree<br>
<bramus> … was mentionedthat this should be presented at whatnot<br>
<bramus> … kurt, can you do that?<br>
<bramus> kurt: yes<br>
<bramus> astearns: and then we ahve issue of @sheet not being a spec<br>
<bramus> … would you kurt be intereste to be an editor for that?<br>
<bramus> kurt: yes<br>
<emilio> s/kurt/kschmi/<br>
<bramus> astearns: So I proposed to add kschmi as editor for css-cascade-7 to spec that<br>
<bramus> … start with what we have not, and then extend to shadow dom and othe ruse cases and bring back to the group<br>
<bramus> kschmi: sgtm<br>
<bramus> TabAtkins: the number?<br>
<bramus> astearns: taking that from fantasai that @scope is prolly done and to take 6 to CR<br>
<bramus> TabAtkins: if 6 is ready for cr and 5 is in cr, then merge scope into 5<br>
<bramus> … dont like many numbers, especially when its only 1 feature per number<br>
<bramus> fantasai: we should get 4 in rec bc layers are shipping and 6 should move to cr and merge down contents of 5 into 6<br>
<bramus> PROPOSED RESOLUTION: Add kurt as editor of css-cascade and work with current editors to figure out the number<br>
<bramus> florian: IUC we resolved on adding @sheet syntax itself, but not on the importing part<br>
<bramus> … regardless we have had enough debate about that that we should add an inline issue in the spec<br>
<bramus> … that its a moving target<br>
<bramus> astearns: editor’s discretion<br>
<bramus> RESOLVED: Add kurt as editor of css-cascade<br>
<bramus> astearns: let’s move on to shape issues<br>
<justinf> thank you everyone!<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11509#issuecomment-2622330858 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 17:23:09 UTC