Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Introduce HTML Modules #4505

Open
wants to merge 17 commits into
base: master
from

Conversation

3 participants
@dandclark
Copy link

commented Apr 4, 2019

Introduce HTML Modules, an extension of the ES modules system that enables importing of HTML content

  • Introduce HTML Module Record, a new subtype of Cyclic Module Record, along with implementations of relevant inherited abstract methods.
  • Introduce HTML Module Script, a new type of Script.
  • Introduce algorithms for creating HTML Module Record and HTML Module Script.
  • Rename Module Script to JS Module Script and define Module Script as a union of HTML Module Script and JS Module Script.
  • Modify "prepare a script" to prevent premature execution of an HTML Module's scripts.
  • Modify "fetch a single module script" to create an HTML Module if the right MIME type is received.
  • Modify the parser's quirks mode determination so that HTML Module Documents are always placed in non-quirks mode.
  • Modify "fetch the descendants of a module script" and "finding the first parse error" to handle HTML Modules

This is not yet ready to merge in given there are still open questions about the design, e.g. whether HTML Modules require a new MIME type. The intent here is to facilitate discussion and tease out issues that can be better found when making changes against the actual spec, with the intention of eventually merging in the updated PR once consensus has been reached on all open issues. These issues are primarily being tracked over in the w3c/webcomponents repo.

There is a corresponding PR against the ES spec here, which refactors InnerModuleInstantiation/InnerModuleEvaluation to avoid issues with HTML Module Record's different way of tracking its requested modules.

I've placed the built result of these changes here: https://dandclark.github.io/built-specs/whatwg-html/html-modules.html


馃挜 Error: HTTP Error: 404 Not Found 馃挜

PR Preview failed to build. (Last tried on Apr 4, 2019, 11:58 PM UTC).

More

馃敆 Related URL

If the error is not surfaced properly, please file an issue.

dandclark added some commits Mar 6, 2019

Introduce HTML module script and redefine module script as union of H鈥
鈥ML module script and JavaScript module script
Add cross-spec references for Cyclic MR and Abstract MR. Add defs for鈥
鈥 HTML Module Record and ScriptEntry. Update 'find the first parse error' algo to work with HTML modules.
Add declaration that HTML MR inherits Absract MR Instantiate. Leave c鈥
鈥mmented out HTML MR InnerModuleInstantiation...we probably need to make an ES spec change for this one after all
Update parser rules to not put HTML Module documents in quirks mode. 鈥
鈥hange 'prepare a script' so that scripts in an HTML Module document are all converted to module type and are not executed at this stage.
Add HTML MR definition of GetRequestedModules(). Fix issue with fetch鈥
鈥 descendants and find first parse error where we were using the Module Record instead of its [[HostDefined]] (module script).
@annevk
Copy link
Member

left a comment

Exciting, couple early comments I found while skimming.

<ol>
<li><p>Create a new <span>Document</span> node <var>document</var> whose
<span data-x="concept-document-content-type">content type</span> is
<code data-x="">text/html</code> and mark it as being an <span

This comment has been minimized.

Copy link
@annevk

annevk Apr 8, 2019

Member

I'd suggest this is a TODO as well, as I hope we can agree it should match the MIME type we end up picking.

This comment has been minimized.

Copy link
@dandclark

dandclark Apr 12, 2019

Author

Yes, updated in latest commit.

This comment has been minimized.

Copy link
@dandclark

dandclark Apr 12, 2019

Author

Thanks for the early feedback!

<span data-x="concept-document-content-type">content type</span> is
<code data-x="">text/html</code> and mark it as being an <span
data-x="HTML documents">HTML document</span>. Let <var>document</var> be in
<span>no-quirks mode</span>. <var>document</var> must be considered an

This comment has been minimized.

Copy link
@annevk

annevk Apr 8, 2019

Member

"no-quirks" is the default so the main thing we have to ensure is that the parser cannot set it.

This comment has been minimized.

Copy link
@dandclark

dandclark Apr 12, 2019

Author

Removed the redundant no-quirks assigment here at HTML Module doc creation time.

See the initial insertion mode for the parser change that prevents the parser from switching it to quirks. I just followed the existing pattern for iframe srcdoc there.

<code data-x="">text/html</code> and mark it as being an <span
data-x="HTML documents">HTML document</span>. Let <var>document</var> be in
<span>no-quirks mode</span>. <var>document</var> must be considered an
<span>HTML module document</span>.</p></li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 8, 2019

Member

Should we set the origin as well?

This comment has been minimized.

Copy link
@dandclark

dandclark Apr 12, 2019

Author

Yes; updated this step to assign the origin from the environent settings object retrieved from the HTML Module script.

<ol>
<li><p>Set <var>scriptEntry</var>.[[InlineModuleRecord]] = null.</p></li>

<li><p>Set <var>scriptEntry</var>.[[ExternalScriptURL]] = *script鈥檚* src URL.</p></li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 8, 2019

Member

This needs more formal wording.

This comment has been minimized.

Copy link
@dandclark

dandclark Apr 12, 2019

Author

Updated in latest commit.

<p>Otherwise:</p>

<ol>
<li><p>Set <var>scriptEntry</var>.[[InlineModuleRecord]] = null.</p></li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 8, 2019

Member

You cannot use = like that. Seems like you want "to". (This happens more often, both above and below.)

This comment has been minimized.

Copy link
@dandclark

dandclark Apr 12, 2019

Author

Updated in latest commit.

@@ -58347,6 +58354,10 @@ o............A....e

</li>

<li><p>If the element's <span>node document</span> is an <span>HTML module document</span>, then

This comment has been minimized.

Copy link
@littledan

littledan Apr 9, 2019

Contributor

Can script tags be dynamically added to an HTML module's document? If so, I don't understand when those scripts would be run.

This comment has been minimized.

Copy link
@dandclark

dandclark Apr 12, 2019

Author

With the current design, dynamically added scripts won't execute (as if they were added to a dynamic document).

For non-dynamically-added scripts: after the HTML Module document is parsed, we basically take a snapshot of it at that time and the <script> elements at that point become the HTML module's child modules in the module graph. Fiddling dynamically with the HTML Module doc's tree after that point won't affect the structure of the module graph, and won't affect which scripts are executed or the order of execution.

I split the non-normative part of this line into a separate note and modified it to try to clarify what I meant here.

I'm open to creating an issue on the whatwg/html repo if you think this is contentious or needs to be open to wider discussion. Our design philosophy so far has generally been to treat the HTML module document as an inert dynamic document except for the special bits needed to enable HTML modules to work as a non-leaf node in the module graph.

Thanks for the feedback!

Address initial PR feedback: add TODO about MIME type to HTML Module 鈥
鈥oc creation, remove non-quirks mode assignment and add origin assignment for new HTML Module doc, replace '=' usage with 'to', and clarify note about HTML Module script execution in prepare-a-script.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.