You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There implies the need that <template> be changed to parse and know its contents, while today they are inert by default.
Why force a change to the parser when leveraging a type of <style> would be enough to prevent the styles from being applied to the page and the export or specifier attributes be the part that explain the usage?
Applying to the page and available for consumption off the module graph:
<style export="/foo.css">
/* ... */
</style>
NOT applying to the page but available for consumption off the module graph:
<style type="module"export="/foo.css">section {
border: medium dashed red;
}
</style>
is indeed ignored in the light DOM.
However, MDN lists the type attribute on the style element under Deprecated Attributes, explaining "This attribute should not be provided: if it is, the only permitted values are the empty string or a case-insensitive match for text/css."
But the living specification says: "if element's type attribute is present and its value is neither the empty string nor an ASCII case-insensitive match for "text/css", then return."
So I think this would work, but I do not know if there is some backward compatibility or history that I am missing.
Also, this technique would not work for SVGs, on which type="module" has no effect. But I assume it would work for <script type="application/json" export="/foo.json">.
But in any case, a change in the parser would be needed to recognize the export, which as I understand it is a core idea of the explainer/proposal.
With the suggestion of:
There implies the need that
<template>
be changed to parse and know its contents, while today they are inert by default.Why force a change to the parser when leveraging a
type
of<style>
would be enough to prevent the styles from being applied to the page and theexport
orspecifier
attributes be the part that explain the usage?Applying to the page and available for consumption off the module graph:
NOT applying to the page but available for consumption off the module graph:
This then can neatly be paralleled in other content types:
Etc.
The text was updated successfully, but these errors were encountered: