Whatwg spec describes conception of the speculative HTML parsing.
So, there are many places in spec with the term active speculative parser. Spec says that HTML parser that owns an instance of speculative parser that performs in parallel. So parsing of HTML parser and parsing of Speculative parser are performed in parallel, independent of each other having their own resources.
I am inerested in a few things.
The first one.
Spec says that the speculative parser acting like HTML parser with some restriction, so that means it performs same steps like it does HTML parser.
Example with an end tag whose name is "script". Does it means that speculative parser will perform all steps (independently) from HTML parser?
But what about the step:
If the active speculative HTML parser is null and the JavaScript execution context stack is empty, then perform a microtask checkpoint.
Will that step be performed in two independent thread for HTML parser and speculative parser or not? If that step has affection only for HTML parser and haven't for speculative parser, it should say explicitly. You can argue that this is noncense because speculative parser can't perform it instruction due with the reason that step doesn't follow to the condition: "speculative parser is null".
Ok, what about an example in another algorithm:
If the active speculative HTML parser is not null, then return the result of creating a speculative mock element given given namespace, the tag name of the given token, and the attributes of the given token.
What can you say now? I want to know what steps can be applied to this or that parser and how they should fit together.
Second one:
Spec has algorithm speculative fetch with some rules for it. One of that rules describes:
If the speculative HTML parser encounters one of the following elements, then act as if that element is processed for the purpose of its effect of subsequent speculative fetches.
What does it mean: "act as if that element is processed for the purpose of its effect of subsequent speculative fetches."?
Addition 1, (step 2, note):
The result is not used. This step allows for a speculative fetch to be initiated from non-speculative parsing. The fetch is still speculative at this point, because, for example, by the time the element is inserted, intended parent might have been removed from the document.
The last sentence is unclear to me, could you clarify what there is going on?
From your questions it's not entirely clear if you understand what the speculative parser is meant to do. So as a recap, it's used to pre-fetch resources while the actual HTML parser is blocked on parsing-blocking <script> elements. So for instance, it the parser encounters a classic, non-async, non-defer <script src="script.js"></script> tag, instead of doing nothing for the time script.js is downloaded then executed, the browser can start a lighter speculative parser, that will search for other resources it can start fetching right away. This way, when the blocking script's execution is over, the browser will hopefully already have started fetching the next required resources and will be able to reuse the resources directly, speeding up the global page load.
If that step has affection only for HTML parser and haven't for speculative parser, it should say explicitly.
It does. The wording "If the active speculative HTML parser is null" means exactly that this step should NOT be performed by a speculative parser. That's just more correct wording since specs are written as pseudo code and it's better to rely on the presence or absence of a set variable than on a semi-abstract type.
So yes, all the steps in the script parsing will be executed, at the exception of the ones that actually do run scripts. (With the added note that, if I read it correctly, the pending parsing script would be null in this case and thus the last steps wouldn't be ran either).
For the create an element algo, since it returns early, it will indeed perform only the first step, which is to create a mock element. Remember, we want it to be light, there is no need to actually create the real DOM element, which will be a lot heavier and slower than the mock up ones.
What does it mean: "act as if that element is processed for the purpose of its effect of subsequent speculative fetches."?
It means that the speculative parser must act as if these elements had been actually processed and as if their effects were applied on the parser, even though they're not yet applied on the actual parser. This is because these elements will affect how the fetching should be done and thus the speculative parser must have the actual modifications to perform the correct fetches.
So for instance if the speculative parser meets a <base href="https://example.com/"> and then an <img src="./image.png">, it must take the <base>'s href into consideration to be able to fetch the correct image file.
The last sentence is unclear to me, could you clarify what there is going on?
An example of that, based on this example from the specs, and which unfortunately won't run in StackSnippet's null-origined iframe, so as a jsfiddle:
<iframe srcdoc='
<div id=a>
From iframe
<script>
// This script will move the current parent <div> to the <iframe>'s parent
// Since it's now in another document, the following script should not be executed nor downloaded
// Still, it's going to be parsed and inserted into the parent DOM
const div = document.getElementById("a");
parent.document.body.append(div);
</script>
<script src="script.js"></script>
</div>'
></iframe>
Since it turns out that the script should actually not be downloaded, the fetching of the script should be discarded, and thus it needed to be a speculative fetch at this point.