On Jun 10, 2014, at 11:01 AM, Ian Hickson wrote: > (I first tried to send this last week, but it seems the es-discuss > mailman is filtering some of my mail as spam or something?) > > Hello, > > I've been working with jorendorff to try to write a description of the > Loader part of the ES6 spec, to make sure I have a good grip of what the > spec says before I look at how I need to hook into it to define the Web's > dependency mechanism in the context of HTML Imports, etc. > > As part of this, I'm trying to understand how I should hook the HTML spec > into the ES6 spec for the purposes of regular <script> execution.
The ECMAScript initialization material [1] is brand new, but it is intended to describe how the initial state the ES execution environment is established by a host such as HTML. I don't expect the current material to be totally complete or correct yet but it is a good starting point so I'm glad to see that you are looking at it. > > Is my understanding correct that the HTML spec should invoke this > algorithm when the HTML spec creates the Window object?: > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-initialization Not exactly, although if you had said "first" Window object then maybe you statement would be correct. As you know, an ECMAScript environment may have multiple co-existent "global objects". The ES spec. abstracts the concepts associated with each global object as a "Realm". All ECMAScript code execution must take place in the context of a Realm so an initial Realm must be established before any ES code executes. Section 8.5 defines the initialization process that occurs for an ES engine before any ES code executes. It includes establishing the first Realm. Whether or not that initial Realm actually corresponds to the first "Window" is something you need to decided. For example, I can image that for some hosts the first Realm might actually some sort of utility Realm that is used for loading code and "forking" user Realms. 8.5 can't be performed for each Window object that shares a common ES engine because it essentially restarts the entire ES engine. Instead, I would expect that the steps of InitializeFirstRealm (8.5.1) to be approximately what should be called for each Window object. This suggests that InitializeFirstRealm is poorly named. Perhaps it should be renamed InitializeHostRealm. There may be additional refactoring that is needed between 8.5 and 8.5.1. > > If so, what should the browser do in step 7? I don't fully understand how > this is supposed to work. Suppose a page is just: > > <body> > <script> alert(document.body.innerHTML); </script> > <script> alert(document.body.innerHTML); </script> > > If I read the #sec-initialization algorithm correctly, the scripts will > execute back-to-back with no change in the DOM, so they'll output the same > text. But the Web requires that these output different text, since the > second <script> element won't be in the DOM when the first executes: ES doesn't know anything about the DOM, external script dependencies , etc. The ES model is that it has a simple queue (populated by the host) of script execution tasks and that the execution of the scripts in the queue take place in order. A simple command-line ES host probably would, as part of step 7, add a ScriptEvaluationTask to the queue for each script file listed on the command-line. They would then be evaluated in sequence. However, you don't have to do that and step 7 isn't the only place you can add new ScriptEvaluationTasks. I would imaging you would maintain your own queues and dependency algorithms that track order and DOM update dependencies such as between the two script tags in your example. You would then only EnqueueTask a ScriptEvaluationTask when it DOM update dependencies has been satisfied. Alternatively, you might define a new kind of ES Task, let's call it a SyncDOMTask. Then at step 7 you might EnqueueTask a DOMSyncTask onto the "ScriptTasks" queue between the two ScriptEvaluationTasks. I understand that this is all pretty vague and leaves a lot up to you. But I need to define ES execution in a host independent manner. I'm trying to provide the building blocks that you and other hosts need to describe how their complex environment-specific semantics integrate with the baseline ES execution semantics. > > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3051 > > Should I just say to invoke that algorithm but skip steps 6-8? > > (Also, how could step 6's substeps ever get triggered?) Working backwards, step 5 does many things, some of which are specified as having error conditions and exceptions, so I have to take into account what happens if any errors occur. Step 6, just says that if they do then the startup of the ES environment has failed. If an implementor can prove that they can trigger any of those error conditions then they don't have to worry about it. But for completeness, I do. It's up to you to define what you initially enqueue in step 7. It could be nothing (step 7 currently says "one or more", it probably should say "zero or more"). Step 8 just says to dispatch the next pending ES Task. You need to do that to actually get things started. However, step 4 of NextTask [2] is where the next ES Task is actually selected and it leaves it up to the implementation to define how the next Task selection process and what happens if all Task queue are empty. My expectation is that most of the integration work you need to do is in define exactly what the web platform does in NextTask step 4. It occurs to be that these implementation-specific extension points may be hard to find as they hare buried as steps in several algorithms. in my next revision I see if I can define an abstraction operation corresponding to each extension points. They we will have a list of operations that a host must define. Hope this helps, keep asking if it doesn't... Allen [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-initialization [2]:http://people.mozilla.org/~jorendorff/es6-draft.html#sec-nexttask-result
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
