[Bug 14694] innerHTML in DocumentFragment

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 Rafael Weinstein changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 3:42 AM, Henri Sivonen wrote: > On Thu, Nov 10, 2011 at 7:32 PM, Jonas Sicking wrote: >> I don't think we should make up rules for where it makes sense to >> insert DOM and where it doesn't. After all, we support .innerHTML on >> all HTML elements (and soon maybe all Eleme

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 3:17 AM, Henri Sivonen wrote: > On Fri, Nov 11, 2011 at 1:11 PM, Jonas Sicking wrote: >> Have you ever actually talked to the SVG WG about this specific issue? > > Yes, at the time foreign lands were being specced in HTML and the SVG > WG had to be dragged in kicking and s

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 1:42 PM, Henri Sivonen wrote: > As a bonus, developers would need to call createDocumentFragement() first. Doh. Would *not* need to call createDocumentFragement() first. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/

Re: innerHTML in DocumentFragment

On Thu, Nov 10, 2011 at 7:32 PM, Jonas Sicking wrote: > I don't think we should make up rules for where it makes sense to > insert DOM and where it doesn't. After all, we support .innerHTML on > all HTML elements (and soon maybe all Elements), and not just a subset > of them, right? Yes, but with

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 1:11 PM, Jonas Sicking wrote: > Microsoft has expressed support for changing the parser here. As a patch for IE9? > Have you ever actually talked to the SVG WG about this specific issue? Yes, at the time foreign lands were being specced in HTML and the SVG WG had to be d

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 3:00 AM, Henri Sivonen wrote: > On Fri, Nov 11, 2011 at 11:49 AM, Anne van Kesteren wrote: >>> Unfortunately

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 11:49 AM, Anne van Kesteren wrote: >> Unfortunately

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 1:49 AM, Anne van Kesteren wrote: > On Fri, 11 Nov 2011 10:44:10 +0100, Jonas Sicking wrote: >> >> For all element names defined in SVG 1.1 (for now), make the parser >> treat it just as it would have if it had parsed "...", except >> that it obviously wouldn't output the

Re: innerHTML in DocumentFragment

On Fri, 11 Nov 2011 10:44:10 +0100, Jonas Sicking wrote: For all element names defined in SVG 1.1 (for now), make the parser treat it just as it would have if it had parsed "...", except that it obviously wouldn't output the element. There are a few tags where this is a big problem. At least f

Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 12:27 AM, Simon Pieters wrote: > On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking wrote: > >> And yes, this does create a lot of edge cases which needs to be >> defined. But the goal should be to make sane calls sane, that seems >> imminently possible. So >> >> frag.inner

Re: innerHTML in DocumentFragment

On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking wrote: And yes, this does create a lot of edge cases which needs to be defined. But the goal should be to make sane calls sane, that seems imminently possible. So frag.innerHTML = ""; someSVGElement.appendChild(frag); seems very possible to ma

Re: innerHTML in DocumentFragment

On Thu, Nov 10, 2011 at 3:43 AM, Henri Sivonen wrote: > On Fri, Nov 4, 2011 at 1:03 AM, Yehuda Katz wrote: >> It would be useful if there was a way to take a String of HTML and parse it >> into a document fragment. This should work even if the HTML string contains >> elements that are invalid in

Re: innerHTML in DocumentFragment

On Thu, Nov 10, 2011 at 5:54 AM, Henri Sivonen wrote: > On Thu, Nov 10, 2011 at 2:05 PM, Yehuda Katz wrote: >> My thinking on this has evolved a bit since my original post. I wrote a >> patch to the spec that creates a new "unknown context" insertion mode that, >> in fact, only affects the proble

Re: innerHTML in DocumentFragment

On Thu, Nov 10, 2011 at 2:05 PM, Yehuda Katz wrote: > My thinking on this has evolved a bit since my original post. I wrote a > patch to the spec that creates a new "unknown context" insertion mode that, > in fact, only affects the problematic table case, and otherwise delegates to > the in-body i

Re: innerHTML in DocumentFragment

My thinking on this has evolved a bit since my original post. I wrote a patch to the spec that creates a new "unknown context" insertion mode that, in fact, only affects the problematic table case, and otherwise delegates to the in-body insertion mode. You can see it in full glory at http://www.w3

Re: innerHTML in DocumentFragment

On Fri, Nov 4, 2011 at 2:54 PM, João Eiras wrote: > * stripScripts is a boolean that tells the parser to strip unsafe content > like scripts, event listeners and embeds/objects which would be handled by a > 3rd party plugin according to user agent policy. "According to user agent policy" is a hug

Re: innerHTML in DocumentFragment

On Fri, Nov 4, 2011 at 1:03 AM, Yehuda Katz wrote: > It would be useful if there was a way to take a String of HTML and parse it > into a document fragment. This should work even if the HTML string contains > elements that are invalid in the "in body" insertion mode. > Something like this code sho

Re: innerHTML in DocumentFragment

The clipboard events spec has some text about HTML sanitization. It might be good to make sure any work in this area is shared. Daniel On Tue, Nov 8, 2011 at 17:10, Ojan Vafai wrote: > Providing concise, easy and XSS safe ways to generate a DOM is certainl

Re: innerHTML in DocumentFragment

Providing concise, easy and XSS safe ways to generate a DOM is certainly something we have to solve. I don't think sandbox is the best way to achieve this. Specifically, I don't believe sandbox on iframes actually strips the script elements, does it? It just doesn't execute them. If we want to con

Re: innerHTML in DocumentFragment

On Mon, Nov 7, 2011 at 8:23 PM, Ryan Seddon wrote: > On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai wrote: >> >> I don't really follow. Script won't execute until you append the fragment >> to the DOM, at which point the fragment itself doesn't go in the DOM, just >> it's children. So, I'm not really

Re: innerHTML in DocumentFragment

On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai wrote: > I don't really follow. Script won't execute until you append the fragment > to the DOM, at which point the fragment itself doesn't go in the DOM, just > it's children. So, I'm not really sure what sandboxing on fragments would > do. If I was a

Re: innerHTML in DocumentFragment

I don't really follow. Script won't execute until you append the fragment to the DOM, at which point the fragment itself doesn't go in the DOM, just it's children. So, I'm not really sure what sandboxing on fragments would do. On Fri, Nov 4, 2011 at 11:14 PM, Ryan Seddon wrote: > This would be a

Re: innerHTML in DocumentFragment

This would be a great addition, another thought would be the ability to sandbox the documentFragment. Much the same way you can sanitise responseText from an XHR using and iframe with the sandbox attribute being able to do this with fragments would be might handy.

Re: innerHTML in DocumentFragment

Importantly, the context-less use-case is by far the common one when you're constructing a DOM in JS. On Fri, Nov 4, 2011 at 12:55 PM, Yehuda Katz wrote: > My use-cases all want pure DOM nodes with no extra cruft added, > because they assume insertion into proper containers. This is true > about

Re: innerHTML in DocumentFragment

My use-cases all want pure DOM nodes with no extra cruft added, because they assume insertion into proper containers. This is true about both jQuery and future updates to template content inserted in the DOM. For the use case of "give me nodes that I can insert into a regular context and then seri

Re: innerHTML in DocumentFragment

On Fri, Nov 4, 2011 at 12:15, Yehuda Katz wrote: > Sent from my iPhone > > On Nov 4, 2011, at 11:55 AM, Daniel Cheng wrote: > >> On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. wrote: >>> 2011/11/4 Daniel Cheng : In that example, there was a clear context element though--I'd argue that Ra

Re: innerHTML in DocumentFragment

Sent from my iPhone On Nov 4, 2011, at 11:55 AM, Daniel Cheng wrote: > On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. wrote: >> 2011/11/4 Daniel Cheng : >>> In that example, there was a clear context element though--I'd argue >>> that Range.createContextualFragment should have been used instead.

Re: innerHTML in DocumentFragment

On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. wrote: > 2011/11/4 Daniel Cheng : >> In that example, there was a clear context element though--I'd argue >> that Range.createContextualFragment should have been used instead. >> >> It seems like the general use of such a function would be to add some >

Re: innerHTML in DocumentFragment

2011/11/4 Daniel Cheng : > In that example, there was a clear context element though--I'd argue > that Range.createContextualFragment should have been used instead. > > It seems like the general use of such a function would be to add some > nodes from a snippet of HTML markup into a div for example

Re: innerHTML in DocumentFragment

In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct c

Re: innerHTML in DocumentFragment

On Fri, Nov 4, 2011 at 9:33 AM, Daniel Cheng wrote: > Instead of simply switching the insertion mode when you see an element that > doesn't belong in in-body mode for context-less parsing, would it make sense > to synthesize the appropriate context elements instead? If I understand your suggestio

Re: innerHTML in DocumentFragment

Instead of simply switching the insertion mode when you see an element that doesn't belong in in-body mode for context-less parsing, would it make sense to synthesize the appropriate context elements instead? Daniel On Fri, Nov 4, 2011 at 05:54, João Eiras wrote: > On Fri, 04 Nov 2011 00:48:29

[Bug 14694] New: innerHTML in DocumentFragment

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 Summary: innerHTML in DocumentFragment Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2

Re: innerHTML in DocumentFragment

On Fri, 04 Nov 2011 00:48:29 +0100, Anne van Kesteren wrote: On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down wrote: Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment That requires a context. Yehuda w

Re: innerHTML in DocumentFragment

This sounds like an excellent idea. Chromium / WebKit had an issue with this in regards to copy & paste because some applications where inserting table-element-less tables into clipboard, and HTML5 parsing algorithm was stripping them out. - Ryosuke On Thu, Nov 3, 2011 at 4:03 PM, Yehuda Katz wr

Re: innerHTML in DocumentFragment

On 4/11/11 10:03 AM, Yehuda Katz wrote: It would be useful if there was a way to take a String of HTML and parse it into a document fragment. This should work even if the HTML string contains elements that are invalid in the "in body" insertion mode. Something like this code should work: v

Re: innerHTML in DocumentFragment

On Thu, Nov 3, 2011 at 4:03 PM, Yehuda Katz wrote: > It would be useful if there was a way to take a String of HTML and parse it > into a document fragment. This should work even if the HTML string contains > elements that are invalid in the "in body" insertion mode. > Something like this code sho

Re: innerHTML in DocumentFragment

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033360.html I'm in favor of making DocumentFragment.prototype.set innerHTML do the above. erik

Re: innerHTML in DocumentFragment

If we can get away with it WRT web compat, we should make createContextualFragment work context-less and we should make DocumentFragment.innerHTML work as Yehuda describes. There are clear use-cases for this that web devs want to do all the time. I don't see any downside except if the web already

Re: innerHTML in DocumentFragment

Yes, now I re-read it, that's clear. Sorry. Tim On 3 November 2011 23:51, James Graham wrote: > On Thu, 3 Nov 2011, Tim Down wrote: > >> Have you looked at the createContextualFragment() method of Range? >> >> http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment > > That do

Re: innerHTML in DocumentFragment

On Thu, 3 Nov 2011, Tim Down wrote: Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment That doesn't meet the use case where you don't know the contextual element upfront. As I understand it that is imp

Re: innerHTML in DocumentFragment

On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down wrote: Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment That requires a context. Yehuda wants a way of parsing where you do not know the context in advan

Re: innerHTML in DocumentFragment

Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment Tim On 3 November 2011 23:03, Yehuda Katz wrote: > It would be useful if there was a way to take a String of HTML and parse it > into a document fragment

innerHTML in DocumentFragment

It would be useful if there was a way to take a String of HTML and parse it into a document fragment. This should work even if the HTML string contains elements that are invalid in the "in body" insertion mode. Something like this code should work: var frag = document.createDocumentFragment();