Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

On Thu, May 17, 2012 at 2:56 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, May 16, 2012 at 4:54 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> That leaves the question of if the contents of the <script> should be
>> parsed as a HTML script or an SVG script. The same question applies to
>> <style>.
>>
>> Of course, ideally we would make the two parse the same way, but so
>> far I've not been successful in convincing people here that that's a
>> good idea.

That wouldn't solve the problem here, because deciding between HTML
and SVG not only affects the parsing of in-line scripts given in the
element content but also affects the handling of external scripts in
terms of varying the attribute that is used for designating the URL of
the external script.

> For what it's worth, the SVGWG thinks it's a good idea.  Let's team up
> and vanquish evil.

I think the SVG working group should learn to stand by its past
mistakes. Not standing by them in the sense of thinking the past
mistakes are great but in the sense of not causing further
disturbances by flip-flopping.

On Sat, May 19, 2012 at 6:29 AM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> There appears to be a consensus to use document.parse (which is fine with
> me), so I would like to double-check which behavior we're picking. IMO, the
> only sane choice is to unset the already-started flag since doing otherwise
> implies script elements parsed by document.parse won't be executed when
> inserted into a document.

I was expecting document.parse() to make scripts unexecutable. Are
there use cases for creating executable scripts using this facility?

If the facility is trying to be a substitute for assembling a document
fragment by hand using createElement and appendChild, it would be
logical for the scripts to be executable, but, as the motto goes,
"please leave your sense of logic at the door, thanks". On the other
hand, considering the problems with the HTML and SVG duality of script
and style, this facility seems particularly ill-suited for creating
those. Furthermore, I would expect there to be use cases for inserting
a single script element, in which case this facility is an overkill
compared to createElement, and use cases for including literals for
more complex repeating DOM subtrees, in which case it doesn't make
sense to repeat scripts or styles.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 31 May 2012 14:56:27 UTC