Webcomponents: HTML module should require a new top level element
Example:
<!DOCTYPE html>
<module xmlns="http://www.w3.org/1999/xhtml">
<meta charset="UTF-8"/>
<!-- HTML Module stuff goes here -->
</module>
As stated in #742, modules should not execute any scripts when navigated to directly.
The topâlevel <module> element would signal that to modern browsers, in a similar way to how the <template> element creates an inert DOM tree in modern browsers. This would also allow us to preserve the existing (see #742 for why this probably isnât the best idea).text/html MIME type
See also:
- #645
- #742
ExE-Boss
All 15 comments
That doesn't really work due to the HTML parser (it'll always generate <html><head/><body/></html> basically). Reusing the HTML MIME type also does not work for security reasons (as outlined in the issue you reference).
annevk
on 19 May 2018
That doesn't really work due to the HTML parser (it'll always generate
<html><head/><body/></html>basically).
At least in that case, it could be possible to make it so that the topâlevel <module> element would prevent the generation of the <html xmlns="httpâ ://www elements, but the aforementioned security issues do make this somewhat problematic, plus this wouldnât work in older browsers, but neither does <template>.
Also, the <module xmlns="httpâ ://www element would at least allow sending HTML modules as application/xml or any other XML mimeâtype.
ExE-Boss
on 21 May 2018
Why is that important?
annevk
on 21 May 2018
(And if we wanted to support XML, why could we not use application/html-module+xml or some such?)
annevk
on 21 May 2018
Of course we could use application/xhtml-module+xml, but weâd still have to support the use case where itâs served as a generic application/xml MIMEâtype, which is permitted by the XML specification.
ExE-Boss
on 21 May 2018
No we don't.
annevk
on 21 May 2018
But I also don't think there's sufficient implementer support to support XML to begin with here.
annevk
on 21 May 2018
Given we're talking about a completely different MIME type, etc... this might be a great opportunity to change the parser if any. e.g. we can get rid of foster child, etc... so that you can get template element like parsing elsewhere. They do have a high implementation cost, and it might be confusing for authors though but I think it's worth considering at least.
rniwa
on 21 May 2018
XML support is interesting to process XHTML documents using XML parsers, which are far simpler than HTML parsers (faster, lighter, more broadly available).
mildred
on 31 Jan 2019
It's not clear they're faster. E.g., you need to parse until the end before you can do anything, since you might encounter a well-formedness error (unless we do XML5, which still seems like a good idea). And they're not always as optimized as HTML parsers with interning of common element and attribute names, buffers optimized based on average documents on the web, etc.
annevk
on 31 Jan 2019
So this issue started out with asking for a new top-level element (which at least for the stated goal doesn't really help and if there's a new MIME type it doesn't matter), but then morphed into considering a new parser or parser changes. Perhaps we should close this and track the new parser separately if folks still want that?
annevk
on 16 Mar 2019
The XML5 parser should be tracked in a separate proposal, whereas this should only be about the new top‑level element <module>, which I believe we should require.
ExE-Boss
on 16 Mar 2019
It's not clear why, as it won't affect the processing model of legacy user agents and for new user agents we can chose whatever we want anyway.
annevk
on 18 Mar 2019
Thing is, it doesnât make much sense for modules to have a <head> and <body> element, and so having the topâlevel element be named <module> would in a way be âchoosing whatever we wantâ for modern UAs, with the added bonus of semantic meaning.
ExE-Boss
on 19 Mar 2019
That's not really how it works, but we also cannot consider this if we're going to use the HTML parser.
annevk
on 19 Mar 2019
Related issues
jonathantneal
·
4Comments
npm1
·
8Comments
caridy
·
4Comments
annevk
·
5Comments
travisleithead
·
8Comments
Most helpful comment
It's not clear they're faster. E.g., you need to parse until the end before you can do anything, since you might encounter a well-formedness error (unless we do XML5, which still seems like a good idea). And they're not always as optimized as HTML parsers with interning of common element and attribute names, buffers optimized based on average documents on the web, etc.