Comments (15)
Well, as @xtuc mentioned, if JS BinAst has a different MIME type, it may require different processing, even if it's also a JS module.
from proposal-import-attributes.
Note, the above talks about how integration with type:
would work, but I'd imagine the same logic would apply with out-of-band data, the type indicated as part of the module specifier, or with a single piece of additional data rather than key/value pairs.
from proposal-import-attributes.
An unrecognized type should be ignored, as if none was provided, for the same reasons an unrecognized attribute is ignored. If the env can’t load the module, it will fail later.
from proposal-import-attributes.
@ljharb In this thread, we're talking about one specific environment--the Web. Are you saying that, if the type is not recognized, the Web should require that the MIME type be JavaScript? I don't understand the motivation for this behavior.
from proposal-import-attributes.
I’m saying that if explicit type info is provided but unrecognized, it should fall back to the mime type. Obviously if the mime type is unrecognized it should act as it does now.
from proposal-import-attributes.
Based on the discussion at WICG/webcomponents#839 , my understanding is that Mozilla and WebKit don't find it acceptable to choose the module interpretation based on the MIME type, at least when choosing between JavaScript and JSON/CSS/HTML (though WebAssembly may provide a point of flexibility). Within this repository, I'd like to work within that assumption. I'd recommend following up on that W3C thread if you want to see if that constraint can be loosened.
from proposal-import-attributes.
I think I’m not being clear :-)
I’m saying that an import with an inline unrecognized type should behave the same as an import without an inline unrecognized type. If that means the only type that can be imported without an inline type is javascript, that’s fine.
from proposal-import-attributes.
Let's centralize discussion of the handling of unrecognized types in #27 . I'd rather not repeat ourselves in several different threads!
from proposal-import-attributes.
I think that on the web it's important to set the Accept header when fetching the resource. For example:
import u from "https://a.cf/sven.jpeg" as json
The developer is requesting from the server a file of type json
. The host does that by sending an the corresponding Accept header.
from proposal-import-attributes.
The module is then parsed and processed according to its MIME type (which may provide more detailed information than simply the type:). The type: is not used at this point--it simply provided an additional check before the parser was invoked.
If we want to allow overlapping MIME type sets, as discussed in #16 (image/foobar+json
etc), then in this step it is the type
attribute, rather than the MIME type, that is what must be used to determine what kind of module to instantiate, or else we're left with some ambiguity.
([the MIME type] may provide more detailed information than simply the type)
Could you elaborate on this a bit? For modules, I'm not sure what information could be gleaned from the MIME type other than which type of module we should instantiate.
from proposal-import-attributes.
Is "script" the only tag that will needs this feature? In particular, does it make sense to loading images or templates (already supported via the template tag) using a script tag?
from proposal-import-attributes.
@jfparadis Could you say more about what you mean by that? I could imagine other sorts of attributes passed to other subresources (e.g., fetch options or integrity), and these could be passed through other tags (or out-of-band manifests).
from proposal-import-attributes.
I'd like to expect the browser to send different Sec-Fetch-Dest
header based on different type
.
import css from './global.css' with { type: 'css' }
Browser send Sec-Fetch-Dest: style
and Server can return this based on the header
body { color: red; }
import css from './global.css'
Browser send Sec-Fetch-Dest: script
and Server can return this based on the header
const css = new CSSStyleSheet()
const hasImport = x.includes('@import')
if (hasImport) css.replace(x)
else css.replaceSync(x)
export default css
from proposal-import-attributes.
Can we agree that the HTML/Web semantics needs to be worked out by Stage 3, but that we have a rough outline for how type
would work, enough to get us to Stage 2?
from proposal-import-attributes.
Why wouldn't the type be application/json
? As in:
import u from "https://a.cf/sven.json" as application/json
or
import u from "https://a.cf/sven.json" assert { accept: 'application/json' }
Then you could just pass it as the accept verbatim? Are you going to map assert types to all mime types and all future mime types?
from proposal-import-attributes.
Related Issues (20)
- Broken references in import assertions
- There should be an escape hatch to allow unknown import attributes HOT 3
- Tracking feasibility of unshipping `assert` contextual keyword in Chrome HOT 8
- No need for NLTH with `with` keyword HOT 9
- Stage 3 reviews HOT 15
- Inferring module type from MIME type vs `type` attribute needs clarification HOT 7
- Changes due to stage 3 reviews to present in July 2023 HOT 2
- return of dynamic import() HOT 1
- Invalid attributes keys in static imports should be a resolution/loading error and not a parsing error HOT 5
- Consider restricting attribute keys syntax to identifiers and strings again HOT 12
- Adding WPT tests HOT 2
- Restrict generalization by scoping private keys HOT 2
- how to use this feature in browser without polyfil? HOT 5
- Support gating with Progressive Enhancement or Graceful Degredation HOT 4
- Importing arbitrary files as raw bytes HOT 1
- Trouble with JSON Imports in JavaScript HOT 4
- [spam]
- [spam] HOT 1
- [spam]
- [spam]
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-import-attributes.