Can you clarify exactly what you need here?

I'd like to be able to say "Invoke the HTML fragment parsing algorithm with scripts enabled/disabled." or something similar.

Running the fragment parser with scripts enabled is likely to have very different results than what one might expect, since the fragment parser is defined as parsing into a new document and then regrafting the nodes. Could you elaborate further on what exactly you need? What are the semantics you want for running scripts? What scripts should run? How should they interact with document.write(), async scripts, the event loop, etc? What if there are re-entrant invokations of this algorithm? etc

(In reply to comment #3)
> Running the fragment parser with scripts enabled is likely to have very
> different results than what one might expect,

Indeed.

> since the fragment parser is
> defined as parsing into a new document and then regrafting the nodes. Could you
> elaborate further on what exactly you need?

That when scripts are enabled, the result of the fragment parsing algorithm is a document fragment that contain script element nodes whose 'already started' and 'parser-inserted' flags haven't been set.

> What are the semantics you want for
> running scripts?

The same as when inserting a manually-constructed DOM fragment into a document.

> What scripts should run? 

All scripts whose type is a supported language.

> How should they interact with
> document.write(), async scripts, the event loop, etc? What if there are
> re-entrant invokations of this algorithm? etc

Exactly as if the fragment had been constructed with document.createElement and appendChild.

So the requirement here is actually to have a flag to run the parser with scripts _disabled_ but to clear all the "already started" flags just before the nodes get inserted?

If I do this, then I should make sure to update the algorithms that rely on "the time the element's "already started" flag was set" to rely on the the time the flag was _last_ set.

Thinking about this some more, I think actually the current text is the right way to do it (but with the createContextualFragment() prose changed per sicking's editorial suggestion in [1], and the HTML spec changed per comment 5).

No?

[1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-December/029280.html

Checked in as WHATWG revision r5866.
Check-in comment: Clarify that if 'already started' is set multiple times, the state the last time it was set is what matters.
http://html5.org/tools/web-apps-tracker?from=5865&to=5866

> So the requirement here is actually to have a flag to run the parser with
> scripts _disabled_ but to clear all the "already started" flags just before the
> nodes get inserted?

The requirement is ability to optionally parse a fragment so that "already started" doesn't get set and the parser doesn't invoke the "prepare the script" algorithm.

So basically, for HTML, skipping everything from "Increment the parser's script nesting level by one" down to the end of that block (inclusive), and for XML, skip all but the first sentence of the paragraph that says "When an XML parser creates a script element"?

Are we sure that's better than doing it as it's done now (per comment 6)?

I would really like to avoid depending on these flags. The reason that text is there now is because there was confusion as to which behaviour was preferred here, and you hadn't yet fixed this bug. I defer to Henri for the technical details.

I don't really understand why depending on the script flags is any better or worse than depending on the parser flags. I'm definitely not a fan of complicating the parser further by having yet more parser modes, especially here where it really doesn't make much difference one way or the other as far as I can tell.

Oops. I should have responded here earlier.

In Firefox, Range::createContextualFragment is equivalent to building the fragment manually using createElementNS and appendChild. The spec already informatively says that XSLTProcessor::transformToFragment works like this, too.

In Firefox, the parser has a "prevent execution" flag that can be set to true in the fragment case. If it is set to true, the parser sets the "already started" flag on script elements instead of attempting to run them. If it is not set, the parser doesn't set the "already started" flag on the scripts (and doesn't run the scripts, either, because they aren't in a document at the time of the parse).

Ms2ger, if you want this please ping me on IRC so you can try to convince me it's needed. I'm just not seeing the value here.

mass-moved component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 13