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

On Thu, May 31, 2012 at 7:55 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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.

I'm not sure I have a strong opinion here, but allowing scripts to be
executable seems potentially useful and not obviously (at least to me)
harmful. innerHTML behaves one way and createContextualFragment the
other, so there's not really anything to be consistent with.

Do you have a particular concern about making scripts executable?

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

Received on Thursday, 31 May 2012 16:00:58 UTC