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

Add easy sync feature detection for new module types #7017

Open
domenic opened this issue Sep 3, 2021 · 4 comments
Open

Add easy sync feature detection for new module types #7017

domenic opened this issue Sep 3, 2021 · 4 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: script

Comments

@domenic
Copy link
Member

domenic commented Sep 3, 2021

Spinning off from #6472 (comment)

It is currently a bit nontrivial to feature-detect support for new module types like JSON or CSS modules. You can do something like the following async:

import("data:text/css,", { assert: { type: "css" } }).then(
  () => { console.log("supported"); },
  () => { console.log("not supported"); }
);

but this is kind of annoying.

I think a good API for this would be something like import.meta.supportsType("css") or maybe import.meta.supportsTypeAssert("css").

It's a little unusual for an import.meta API since it's not particularly about the current module. But I think that's OK?

Other places to put this I can think of would be:

  • As a static HTMLScriptElement.supportsTypeAssert("css"). (Not so great since it's window-only and various module types work in more places than just <script> elements.)
  • As a global, e.g. supportsImportTypeAssert("css").
  • As a new metaproperty of import itself, e.g. import.supportsType("css").

/cc @guybedford @dandclark

@domenic domenic added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: script labels Sep 3, 2021
@dandclark
Copy link
Contributor

I like import.meta.supportsType("css").

For a browser that does support CSS module scripts, what should import.meta.supportsType("css") return when executing in a worker script, where CSS module script imports are not allowed?

It seems to me that it should return false in that case, since attempting to import a CSS module in that context will fail. If we go with this behavior, then it strengthens the case the import.meta is the right place for supportsType, since in this sense it would indeed be about the current module.

On the other hand, it's reasonable to argue that import.meta.supportsType("css") just indicates overall UA support for the module type, so it should always be 'true' in a UA that supports the type, and it's the author's responsibility not to try importing CSS modules in a worker since that will never work in any UA.

@domenic
Copy link
Member Author

domenic commented Sep 3, 2021

I find the argument for false compelling, yeah.

@guybedford
Copy link
Contributor

Thanks for creating this issue.

As a new metaproperty of import itself, e.g. import.supportsType("css").

This could be a useful pattern as it would also be available in scripts then as well.

@domenic
Copy link
Member Author

domenic commented Sep 3, 2021

I thought about that but couldn't quite see the need. Any browser that is new enough to support this new API would support module scripts...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: script
Development

No branches or pull requests

3 participants