Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS Module Scripts #541

Closed
dandclark opened this issue Jun 10, 2021 · 4 comments
Closed

CSS Module Scripts #541

dandclark opened this issue Jun 10, 2021 · 4 comments
Labels
venue: WHATWG Specifications in a WHATWG Workstream

Comments

@dandclark
Copy link

dandclark commented Jun 10, 2021

Request for Mozilla Position on an Emerging Web Specification

  • Specification Title: CSS Module Scripts
  • Specification or proposal URL: Explainer, HTML PR
  • Mozillians who can provide input (optional): @annevk

Other information

This proposal has already been in discussion for a while now (long thread here, see also the TAG review), but I realized we don't have a mozilla/standards-positions entry on it yet so I think it would be useful to get an official position.

Landing the CSS Module Script HTML Spec PR is currently blocked on resolution of an open issue in the import assertions TC39 proposal. However import assertions is at Stage 3 so that proposal is unlikely to undergo significant changes.

@annevk
Copy link
Contributor

annevk commented Jun 14, 2021

I'm not sure I understand your last paragraph. It seems to me those integration concerns need to be sorted, no? Including what kind of host hook to provide.

Do you recall if we ever discussed the identifier name? Do we want to specifically assert it's CSS or is stylesheet or some such sufficient?

@dandclark
Copy link
Author

@annevk Sorry, that paragraph was too vague. I agree that the integration concerns and the shape of the host hooks need to be settled before landing the HTML spec change. The import assertion proposal champions are joining an SES call this Wednesday to hopefully make some progress in that area.

I meant that most of the basic behavior of the proposal as observed by developers is unlikely to change much. For example, the fact that the import gives you a CSSStyleSheet, and the use of the import assertions syntax to convey the expected module type is unlikely to change, in my estimation, even if details about spec integration and behavior of undefined types need to be sorted out.

Regarding the identifier name, my understanding is that there was general agreement on using "css" as the type name, as in:

import styleSheet from "./styles.css" assert { type: "css" };

This was what I used in my slides (specifically, slide 7) in last year's TPAC discussion on the topic (notes here), and I don't recall disagreement on that point at the time. Happy to discuss alternatives though.

I like "css" because it's short and the use of the acronym would align nicely with "json" for JSON modules and maybe "html" someday:

import styleSheet from "./styles.css" assert { type: "css" };
import myJson from "./data.json" assert { type: "json" };
import doc from "./content.html" assert { type: "html" };

@annevk
Copy link
Contributor

annevk commented Jun 16, 2021

Thanks, provided the details are settled, I would recommend we mark this as worth prototyping.

@annevk annevk added the venue: WHATWG Specifications in a WHATWG Workstream label Jun 16, 2021
@annevk
Copy link
Contributor

annevk commented Jan 12, 2022

Closing this as per the previous comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
venue: WHATWG Specifications in a WHATWG Workstream
Projects
None yet
Development

No branches or pull requests

2 participants