On Fri, Nov 11, 2011 at 3:42 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Thu, Nov 10, 2011 at 7:32 PM, Jonas Sicking jo...@sicking.cc 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
On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking jo...@sicking.cc 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 = g/g;
someSVGElement.appendChild(frag);
seems
On Fri, Nov 11, 2011 at 12:27 AM, Simon Pieters sim...@opera.com wrote:
On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking jo...@sicking.cc 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
On Fri, 11 Nov 2011 10:44:10 +0100, Jonas Sicking jo...@sicking.cc 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 svgg..., except
that it obviously wouldn't output the svg element.
There are a few tags where this is a
On Fri, Nov 11, 2011 at 1:49 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 11 Nov 2011 10:44:10 +0100, Jonas Sicking jo...@sicking.cc 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 svgg..., except
that it
On Fri, Nov 11, 2011 at 11:49 AM, Anne van Kesteren ann...@opera.com wrote:
Unfortunately style and script are parsed differently depending on
if they live in foreign content or not. However this is something we
can fix, and would lead to a lot of other benefits (such as scripts
parsed
On Fri, Nov 11, 2011 at 3:00 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, Nov 11, 2011 at 11:49 AM, Anne van Kesteren ann...@opera.com wrote:
Unfortunately style and script are parsed differently depending on
if they live in foreign content or not. However this is something we
can fix, and
On Fri, Nov 11, 2011 at 1:11 PM, Jonas Sicking jo...@sicking.cc 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
On Thu, Nov 10, 2011 at 7:32 PM, Jonas Sicking jo...@sicking.cc 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?
On Fri, Nov 11, 2011 at 1:42 PM, Henri Sivonen hsivo...@iki.fi 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/
On Fri, Nov 11, 2011 at 3:17 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, Nov 11, 2011 at 1:11 PM, Jonas Sicking jo...@sicking.cc 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
On Fri, Nov 4, 2011 at 1:03 AM, Yehuda Katz wyc...@gmail.com 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
On Fri, Nov 4, 2011 at 2:54 PM, João Eiras jo...@opera.com 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
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
On Thu, Nov 10, 2011 at 5:54 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Thu, Nov 10, 2011 at 2:05 PM, Yehuda Katz wyc...@gmail.com 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,
On Thu, Nov 10, 2011 at 3:43 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, Nov 4, 2011 at 1:03 AM, Yehuda Katz wyc...@gmail.com 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
The clipboard events http://www.w3.org/TR/clipboard-apis/ 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 o...@chromium.org wrote:
Providing concise, easy and XSS safe ways to generate a
On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai o...@chromium.org 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
On Mon, Nov 7, 2011 at 8:23 PM, Ryan Seddon seddon.r...@gmail.com wrote:
On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai o...@chromium.org 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
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.
On Fri, 04 Nov 2011 00:48:29 +0100, Anne van Kesteren ann...@opera.com
wrote:
On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down timd...@gmail.com wrote:
Have you looked at the createContextualFragment() method of Range?
http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
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 jo...@opera.com wrote:
On Fri, 04 Nov
On Fri, Nov 4, 2011 at 9:33 AM, Daniel Cheng dch...@chromium.org 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
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
2011/11/4 Daniel Cheng dch...@chromium.org:
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
On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote:
2011/11/4 Daniel Cheng dch...@chromium.org:
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
Sent from my iPhone
On Nov 4, 2011, at 11:55 AM, Daniel Cheng dch...@chromium.org wrote:
On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote:
2011/11/4 Daniel Cheng dch...@chromium.org:
In that example, there was a clear context element though--I'd argue
that
On Fri, Nov 4, 2011 at 12:15, Yehuda Katz wyc...@gmail.com wrote:
Sent from my iPhone
On Nov 4, 2011, at 11:55 AM, Daniel Cheng dch...@chromium.org wrote:
On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote:
2011/11/4 Daniel Cheng dch...@chromium.org:
In that example,
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
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 wyc...@gmail.com wrote:
It would be useful if there was a way to take a String of HTML and parse it
into a
On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down timd...@gmail.com 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
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
Yes, now I re-read it, that's clear. Sorry.
Tim
On 3 November 2011 23:51, James Graham jgra...@opera.com 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
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
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
On Thu, Nov 3, 2011 at 4:03 PM, Yehuda Katz wyc...@gmail.com 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 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
37 matches
Mail list logo
