-
Notifications
You must be signed in to change notification settings - Fork 27
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
What syntax could be used to pass attributes to other subresources on the web? #9
Comments
Is this not something that a host could choose to attach to |
This issue is used to track non-module subresources, so I don't think it relates to |
@littledan I must be misunderstanding this issue, can you explain? Is this just tracking how to inject something like |
@bmeck I don't see how this relates to import.meta. It's about new attributes defined in this repository (where we didn't yet propose any mapping to import.meta). |
@littledan I'm more confused now, are you saying this proposal is seeking to only provide a whitelist of key/value pairs; or, are you saying that this proposal isn't going to directly expose the key/value pair to the host so it can pass it to other languages? |
I was imagining we'd expose the k/v pairs to the host so it can decide what to do with them. It's still sort of an open question what we would do with unrecognized keys, but I wasn't really thinking about a whitelist. But I would like to keep hosts somehow vaguely aligned (#10 ). (This sounds like a third topic; I don't see how it relates to import.meta or the start of this thread.) |
While it may be important to pass attributes to other kinds of subresources, there are some that are really specific to the ES module context, and this includes the module type. Therefore, I don't think we should be blocked by coming up with a more general solution, but it will be good to continue discussion. |
Although module types only make sense in module contexts, other attributes (e.g., fetch options) may make sense for all sorts of subresources (e.g.,
<link>
elements and@import
in CSS). It would be ideal if we had a uniform way to pass these same flags to those contexts as well.Otherwise, we're sort of back to shoving something into URLs, for those cases. Although this is really sort of a web platform issue, it affects the viability of using these options out of the URL, so I want to suggest that we start discussion here.
Let's try to write down the different subresources in the web platform, and see if we can find syntax for them to accept an options bag for further parameters, analogous to what this proposal does for JavaScript.
h/t to @slightlyoff for raising this issue offline
The text was updated successfully, but these errors were encountered: