[Bug 8473] New: Sentence about the effect of changing src/async/defer on <script> is wrong

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8473

           Summary: Sentence about the effect of changing src/async/defer on
                    <script> is wrong
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec bugs
        AssignedTo: dave.null@w3.org
        ReportedBy: hsivonen@iki.fi
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org,
                    jonas@sicking.cc


The spec says:
"Changing the src, type, charset, async, and defer attributes dynamically has
no direct effect; these attribute are only used at specific times described
below (namely, when the element is inserted into the document)."

This doesn't seem to be entirely true. I tried implementing src/async/defer
freezing upon insertion into the document, and the results were wrong.

There are three interesting cases:
 1) The parser parser a script element from the network stream. A timeout (or
whatever) changes src/async/defer between the time the element is inserted to
the DOM and the time the end tag is parsed (and the script is run). In this
case, the timeout (or whatever) is racing with the network, so there's no point
in trying to make this case nice for the timeouts.

 2) The script start tag is document.written. Then the script doing the
document.write changes the src attribute on the script element that got created
by the document.write. Then the end tag is document.written.

 3) The special case where a script element has neither non-space content nor
the src attribute.

In case #1, the effective values of src, async and defer need to be frozen when
the element is inserted to the tree so that the asyncness or deferredness of
the script is solely determined by markup and cannot be changed by scripts
before the script is run. If the deferredness or asyncness were changeable by
scripts, there'd be a case where DOM scripting would need to feed back into the
parser, which would be bad for off-the-main-thread speculative parsing. (If the
deferredness/asyncness is determined solely by markup, a speculative
implementation doesn't need to speculate on the script, since it knows the
script can't do document.write with a defined insertion point.)

The old parser in Gecko doesn't allow scenario #2 (I don't know by what
mechanism), so the exact behavior in case #2 probably isn't Web
compat-sensitive. For me, it would be the easiest to perform the same freezing
in this case as in case #1, but I could see an argument why it would be less
surprising not to freeze in case #2.

When cases #1 and #3 coincide, the spec sentence is wrong. In that case,
subsequent additions of non-space content or a src attribute cause the script
to run even though it was originally parser-inserted. It seems to me that if
the script didn't got marked "already started" when the parser tried to run the
script upon </script>, src/async/defer need to be thawed so that another script
may cause the script to run at a later time (contrary to the spec sentence
claiming that setting src dynamically has no effect after the node has been
inserted into the document).

I'm requesting that the spec say more explicitly what I described above about
cases #1 and #3. I'm not quite sure what I should request about case #2, but
provisionally, I'm requesting that it be handled like case #1, even though case
#2 doesn't strictly really need the freezing.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 10 December 2009 22:52:48 UTC