We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
When the modulepreload feature is served from HTTP Link header, it will fetch a modulepreload module script graph, which will in turn disallow further import maps, that will make import maps won't be parsed at all, see Prepare the script element, step 32.
Latest HTML spec commit: d67f8f7
This will make import maps totally useless if the modulepreload is served from HTTP Link header.
The text was updated successfully, but these errors were encountered:
cc @domenic @noamr
Sorry, something went wrong.
Yep, this is a known issue, and "working as intended".
Investigations into fixing this generally take the form of finding a solution for allowing import maps to update over time. See WICG/import-maps#92, https://github.com/guybedford/import-maps-extensions#lazy-loading-of-import-maps, and guybedford/import-maps-extensions#17 for the latest discussions on how we could do that. We know it's a high-priority request from web developers, but Chromium at least hasn't been able to find the engineering bandwidth for working on it so far.
/cc @hiroshige-g
modulepreload
No branches or pull requests
When the modulepreload feature is served from HTTP Link header,
it will fetch a modulepreload module script graph, which will in turn disallow further import maps, that will make import maps won't be parsed at all, see Prepare the script element, step 32.
Latest HTML spec commit: d67f8f7
This will make import maps totally useless if the modulepreload is served from HTTP Link header.
The text was updated successfully, but these errors were encountered: