Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 9:28 PM, Rafael Weinstein rafa...@google.comwrote:
On Thu, May 10, 2012 at 4:19 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Rafael Weinstein wrote:
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
But ok, let's assume that the use case is create an element and its
subtree so that you can insert dynamically generated parts of an
application during runtime, e.g. inserting images in a dynamically
generated gallery [...]
[...[ but here's one that comes to mind which is valid markup: What's
the output for this
myDocFrag.innerHTML = optionOneoptiontwooptionthree;
My proposal would return a single option element with the value One.
But the example here suggests a different use case. There are presumably
three elements there, not one. If this is a use case we want to address,
then let's go back to the use cases again: what is the problem we are
trying to solve? When would you create a document fragment of some
options, instead of just creating a select with options?
BTW, for example
In handlerbars,
select
{{# each optionListThatComeInPairs }}
option{{ firstThingInPair }}
option{{ secondThingInPair }}
{{/ each }}
/select
Or equivalently, in MDV
select
template iterate=optionsListThatComeInPairs
option{{ firstThingInPair }}
option{{ secondThingInPair }}
/template
/select
To clarify, this doesn't suffer from the string concatenation problem that
Ian was worried about, right? {{ firstThingInPair }} is inserted as a
string, not HTML, right? Similarly, if you had 'data-foo={{ attributeValue
}}', it would be escaped appropriately so as to avoid any possibility of
XSS?
Ojan
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein rafa...@google.com wrote: I'm very much of a like mike with Henri here, in that I'm frustrated with the situation we're currently in WRT SVG MathML parsing foreign content in HTML, etc... In particular, I'm tempted to feel like SVG and MathML made this bed for themselves and they should now have to sleep in it. I think that characterization is unfair to MathML. The math working group tried hard to avoid local name collisions with HTML. They didn't want to play namespace games. As I understand it, they were forced into a different namespace by W3C strategy tax arising from the NAMESPACE ALL THE THINGS! attitude. SVG is the language that introduced collisions with both HTML and MathML and threw unconventional camel casing into the mix. On Fri, May 11, 2012 at 1:44 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The innerHTML API is convenient. It lets you set the entire descendant tree of an element, creating elements and giving them attributes, in a single call, using the same syntax you'd use if you were writing it in HTML (module some extra quote-escaping maybe). I'm less worried about magic in an API that's meant for representing tree literals in JavaScript as a sort of E4H without changing the JavaScript itself than I am about magic in APIs that are meant for parsing arbitrary potentially user-supplied content. If we are designing an API for the former case rather than the latter case, I'm OK with the following magic: * Up until the first start tag parser behaves as in in body (Tough luck if you want to use ![CDATA[ or U+ before the first tag, though I could be convinced that the parser should start in a mode that enables ![CDATA[.) * if the first start tag is any MathML 3 element name except set or image, start behaving as if setting innerHTML on math (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on math. * otherwise, if the first start tag is any SVG 1.1 element name except script, style, font or a, start behaving as if setting innerHTML on svg (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on svg. * otherwise, set the insertion mode per HTML-centric template rules proposed so far. Open question: Should it be possible to use a magic attribute on the first tag token to disambiguate it as MathML or SVG? xmlns=... would be an obvious disambiguator, but the values are unwieldy. Should xlink:href be used as a disambiguator for a? If the use case is putting tree literals in code, it probably doesn't make sense to use script or style (either HTML or SVG) in that kind of context anyway. And SVG font has been rejected by Mozilla and Microsoft anyway. I still think that having to create a DocumentFragment first and then set innerHTML on it is inconvenient and we should have a method on document that takes a string to parse and returns the resulting DocumentFragment, e.g. document.parse(string) to keep it short. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 10:55 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein rafa...@google.com wrote: I'm very much of a like mike with Henri here, in that I'm frustrated with the situation we're currently in WRT SVG MathML parsing foreign content in HTML, etc... In particular, I'm tempted to feel like SVG and MathML made this bed for themselves and they should now have to sleep in it. I think that characterization is unfair to MathML. The math working group tried hard to avoid local name collisions with HTML. They didn't want to play namespace games. As I understand it, they were forced into a different namespace by W3C strategy tax arising from the NAMESPACE ALL THE THINGS! attitude. SVG is the language that introduced collisions with both HTML and MathML and threw unconventional camel casing into the mix. Tangent: It appears to be a very difficult uphill battle to get SVG into the HTML namespace or un-namespaced entirely, but how difficult might it be to do that for MathML? We can branch this to a separate thread if the answer is anything other than Don't even think about it. On Fri, May 11, 2012 at 1:44 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The innerHTML API is convenient. It lets you set the entire descendant tree of an element, creating elements and giving them attributes, in a single call, using the same syntax you'd use if you were writing it in HTML (module some extra quote-escaping maybe). I'm less worried about magic in an API that's meant for representing tree literals in JavaScript as a sort of E4H without changing the JavaScript itself than I am about magic in APIs that are meant for parsing arbitrary potentially user-supplied content. I'm not sure what you mean by the latter. If this translates as improving innerHTML is okay with me, then cool. ^_^ If we are designing an API for the former case rather than the latter case, I'm OK with the following magic: * Up until the first start tag parser behaves as in in body (Tough luck if you want to use ![CDATA[ or U+ before the first tag, though I could be convinced that the parser should start in a mode that enables ![CDATA[.) Ah, so this would mean you just *always* emit the characters before the first start tag? That seems perfectly acceptable. In the contexts where text-before-the-tag is valid, that's exactly what you want to do. In the contexts where it's not, you're doing something wrong anyway, and there's only so much reasonable fixup we can do anyway. Might as well just emit the text. Don't know why we didn't think of that yet. * if the first start tag is any MathML 3 element name except set or image, start behaving as if setting innerHTML on math (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on math. * otherwise, if the first start tag is any SVG 1.1 element name except script, style, font or a, start behaving as if setting innerHTML on svg (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on svg. * otherwise, set the insertion mode per HTML-centric template rules proposed so far. I think that SVG should get priority over MathML on the conflicts - set and especially image are useful SVG elements that can reasonably be the first tag of a fragment. It seems more useful to get an svg fragment for an image than a mathml fragment. Open question: Should it be possible to use a magic attribute on the first tag token to disambiguate it as MathML or SVG? xmlns=... would be an obvious disambiguator, but the values are unwieldy. Should xlink:href be used as a disambiguator for a? If the use case is putting tree literals in code, it probably doesn't make sense to use script or style (either HTML or SVG) in that kind of context anyway. And SVG font has been rejected by Mozilla and Microsoft anyway. SVG is chucking xlink, so that won't work. In SVG2, a will just use @href. That conflict is just going to remain hard to resolve. font is less troublesome. Based on discussion in the SVGWG, we're okay with resolving the conflict always in HTML's favor. If others disagree with this, using attributes to disambiguate should be *really* easy. The only overlap in attributes is @id, @class, and @color. It should definitely be okay to resolve ambiguous cases like font color=red... in HTML's favor. If we did want to use a magic attribute, I suggest @svg and @math as boolean attributes with no effect other than this disambiguation (and then just resolving all conflicts in HTML's favor by default). I still think that having to create a DocumentFragment first and then set innerHTML on it is inconvenient and we should have a method on document that takes a string to parse and returns the resulting DocumentFragment, e.g. document.parse(string) to keep it short. I
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 11:59 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, May 11, 2012 at 1:55 AM, Henri Sivonen hsivo...@iki.fi wrote: I still think that having to create a DocumentFragment first and then set innerHTML on it is inconvenient and we should have a method on document that takes a string to parse and returns the resulting DocumentFragment, e.g. document.parse(string) to keep it short. Yes! Can we re-use createDocumentFragment and add an optional argument instead though? That seems unacceptably verbose. :/ I doubt people will be happy trading in their single-character $ for the 22-character createDocumentFragment. document.parse is 14 characters, which is less than ideal, but still much better. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 12:59 PM, Ryosuke Niwa rn...@webkit.org wrote: Yes! Can we re-use createDocumentFragment and add an optional argument instead though? I think that makes sense in principle, but I worried that the name createDocumentFragment is the kind of name that's works OK if you're writing Java into an IDE that has autocompletion but that's super inconvenient in a language that's dynamically typed (so autocompletion can't be exact) and often written without autocompletion. On Fri, May 11, 2012 at 1:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Tangent: It appears to be a very difficult uphill battle to get SVG into the HTML namespace or un-namespaced entirely, but how difficult might it be to do that for MathML? We can branch this to a separate thread if the answer is anything other than Don't even think about it. Don't even think about it. ;-) On Fri, May 11, 2012 at 1:44 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The innerHTML API is convenient. It lets you set the entire descendant tree of an element, creating elements and giving them attributes, in a single call, using the same syntax you'd use if you were writing it in HTML (module some extra quote-escaping maybe). I'm less worried about magic in an API that's meant for representing tree literals in JavaScript as a sort of E4H without changing the JavaScript itself than I am about magic in APIs that are meant for parsing arbitrary potentially user-supplied content. I'm not sure what you mean by the latter. If this translates as improving innerHTML is okay with me, then cool. ^_^ I mean that it's a bad if the kind of magic fragment parsing we're introducing here is used with untrusted input the way innerHTML today is used with untrusted input. If we are designing an API for the former case rather than the latter case, I'm OK with the following magic: * Up until the first start tag parser behaves as in in body (Tough luck if you want to use ![CDATA[ or U+ before the first tag, though I could be convinced that the parser should start in a mode that enables ![CDATA[.) Ah, so this would mean you just *always* emit the characters before the first start tag? Yes. * if the first start tag is any MathML 3 element name except set or image, start behaving as if setting innerHTML on math (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on math. * otherwise, if the first start tag is any SVG 1.1 element name except script, style, font or a, start behaving as if setting innerHTML on svg (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on svg. * otherwise, set the insertion mode per HTML-centric template rules proposed so far. I think that SVG should get priority over MathML on the conflicts - set and especially image are useful SVG elements that can reasonably be the first tag of a fragment. It seems more useful to get an svg fragment for an image than a mathml fragment. That's what I was trying to say. Open question: Should it be possible to use a magic attribute on the first tag token to disambiguate it as MathML or SVG? xmlns=... would be an obvious disambiguator, but the values are unwieldy. Should xlink:href be used as a disambiguator for a? If the use case is putting tree literals in code, it probably doesn't make sense to use script or style (either HTML or SVG) in that kind of context anyway. And SVG font has been rejected by Mozilla and Microsoft anyway. SVG is chucking xlink, so that won't work. In SVG2, a will just use @href. Surely SVG2 has to support xlink:href in order to support existing content. If we did want to use a magic attribute, I suggest @svg and @math as boolean attributes with no effect other than this disambiguation (and then just resolving all conflicts in HTML's favor by default). Makes sense. I still think that having to create a DocumentFragment first and then set innerHTML on it is inconvenient and we should have a method on document that takes a string to parse and returns the resulting DocumentFragment, e.g. document.parse(string) to keep it short. I agree. We should definitely *have* DocumentFragment.innerHTML, but we should also have a shorter way of doing so and getting the DOM, like the document.parse() you suggest. One thing that I particularly dislike about innerHTML is that it changes behavior depending on the HTMLness flag of the owner document (whether it uses the HTML parser or the XML parser). For consistency, we'd probably have to spread of that (Gecko-originating?) design bug to DocumentFragment for completeness if we were to introduce innerHTML on DocumentFragment. A new document.parse(string) or document.createDocumentFragment(string) could always use the HTML parser. However, I'm not strongly opposed to adding innerHTML to DocumentFragment if we
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 12:13 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 10, 2012 at 9:28 PM, Rafael Weinstein rafa...@google.com
wrote:
On Thu, May 10, 2012 at 4:19 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Rafael Weinstein wrote:
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
But ok, let's assume that the use case is create an element and its
subtree so that you can insert dynamically generated parts of an
application during runtime, e.g. inserting images in a dynamically
generated gallery [...]
[...[ but here's one that comes to mind which is valid markup: What's
the output for this
myDocFrag.innerHTML = optionOneoptiontwooptionthree;
My proposal would return a single option element with the value One.
But the example here suggests a different use case. There are presumably
three elements there, not one. If this is a use case we want to address,
then let's go back to the use cases again: what is the problem we are
trying to solve? When would you create a document fragment of some
options, instead of just creating a select with options?
BTW, for example
In handlerbars,
select
{{# each optionListThatComeInPairs }}
option{{ firstThingInPair }}
option{{ secondThingInPair }}
{{/ each }}
/select
Or equivalently, in MDV
select
template iterate=optionsListThatComeInPairs
option{{ firstThingInPair }}
option{{ secondThingInPair }}
/template
/select
To clarify, this doesn't suffer from the string concatenation problem that
Ian was worried about, right? {{ firstThingInPair }} is inserted as a
string, not HTML, right? Similarly, if you had 'data-foo={{ attributeValue
}}', it would be escaped appropriately so as to avoid any possibility of
XSS?
Correct. In the first example, handlebars will escape the script
before doing innerHTML, and MDV doesn't invoke the parser, it assigns
the Text node's textContent.
Ojan
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 7:13 AM, Henri Sivonen hsivo...@iki.fi wrote: However, I'm not strongly opposed to adding innerHTML to DocumentFragment if we also add a method on Document that parses a string using the HTML parser regardless of the HTMLness flag of the document and returns a DocumentFragment (or has an optional extra argument for forcing XML parsing explicitly). Just a side note, but at least parsing XML seems to be fairly sane today. I haven't really done any testing around this, but it seems like this would get you parsing of arbitrary XML fragments, including leading and trailing text nodes: (new DOMParser).parseFromString( x + string + /x, text/xml ).documentElement.childNodes Obviously this is overly verbose compared to document.parse( string, flag ).
Re: History Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
It was wrong for me to editorialize about SVG and MathML -- and punish was very poor word choice. I apologize to anyone who was insulted. It certainly wasn't my intent. I should have just said that I'm frustrated with the world we've arrived in WRT HTML vs XML and left it at that. On Fri, May 11, 2012 at 3:07 AM, Charles McCathieNevile cha...@opera.com wrote: On Fri, 11 May 2012 10:55:27 +0200, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein rafa...@google.com wrote: I'm very much of a like mike with Henri here, in that I'm frustrated with the situation we're currently in WRT SVG MathML parsing foreign content in HTML, etc... In particular, I'm tempted to feel like SVG and MathML made this bed for themselves and they should now have to sleep in it. I think that characterization is unfair to MathML. The math working group tried hard to avoid local name collisions with HTML. They didn't want to play namespace games. As I understand it, they were forced into a different namespace by W3C strategy tax arising from the NAMESPACE ALL THE THINGS! attitude. Actually, I think even that is an unfair characterisation. At the time both these technologies were developed (mid-late 90s) everyone assumed that XML was the path of the future for everything, and that de-crentralised extensibility was a critical requirement for a powerful web platform. Given that scenario, it is unclear whether there is a better approach. The current HTML approach of if it is important it will get into the mainline spec effectively breaks the key extensibility assumption. Leading implementors like Adobe, SodiPodi and Inkscape all introduced namespaced content all over the SVG map - in many cases doing things that active SVG WG members thought were excessive. Likewise Microsoft Office (at the time probably as widespread as web browsers in general) introduced namespaced content all over HTML (IE didn't support XHTML). Seven years later, both of those assumptions came under attack from the nascent WHAT-WG approach to updating HTML - but unlike the case for HTML, where the market leader had clearly resisted implementing XHTML, SVG in particular was backed by a number of XML-happy engines. It was several more years before SVG and MathML were incorporated into HTML in a way that clearly made sense. Punishing people, or even ridiculing them, for using XML in the late 90s, seems counter-productive at best. Outside HTML even Microsoft - who were one of the big creative forces behind XML - were pushing it everywhere, it was considered de riguer for making the mobile web a possibility outside Opera (which supported it anyway, but didn't require it), and it had, and still has, huge deployment. It just failed on the web browser platform, for reasons that are far easier to see in hindsight than they were at the time. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: History Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, 11 May 2012 19:57:37 +0200, Rafael Weinstein rafa...@google.com wrote: It was wrong for me to editorialize about SVG and MathML -- and punish was very poor word choice. I apologize to anyone who was insulted. It certainly wasn't my intent. I should have just said that I'm frustrated with the world we've arrived in WRT HTML vs XML and left it at that. Fair enough... cheers On Fri, May 11, 2012 at 3:07 AM, Charles McCathieNevile cha...@opera.com wrote: On Fri, 11 May 2012 10:55:27 +0200, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein rafa...@google.com wrote: I'm very much of a like mike with Henri here, in that I'm frustrated with the situation we're currently in WRT SVG MathML parsing foreign content in HTML, etc... In particular, I'm tempted to feel like SVG and MathML made this bed for themselves and they should now have to sleep in it. I think that characterization is unfair to MathML. The math working group tried hard to avoid local name collisions with HTML. They didn't want to play namespace games. As I understand it, they were forced into a different namespace by W3C strategy tax arising from the NAMESPACE ALL THE THINGS! attitude. Actually, I think even that is an unfair characterisation. At the time both these technologies were developed (mid-late 90s) everyone assumed that XML was the path of the future for everything, and that de-crentralised extensibility was a critical requirement for a powerful web platform. Given that scenario, it is unclear whether there is a better approach. The current HTML approach of if it is important it will get into the mainline spec effectively breaks the key extensibility assumption. Leading implementors like Adobe, SodiPodi and Inkscape all introduced namespaced content all over the SVG map - in many cases doing things that active SVG WG members thought were excessive. Likewise Microsoft Office (at the time probably as widespread as web browsers in general) introduced namespaced content all over HTML (IE didn't support XHTML). Seven years later, both of those assumptions came under attack from the nascent WHAT-WG approach to updating HTML - but unlike the case for HTML, where the market leader had clearly resisted implementing XHTML, SVG in particular was backed by a number of XML-happy engines. It was several more years before SVG and MathML were incorporated into HTML in a way that clearly made sense. Punishing people, or even ridiculing them, for using XML in the late 90s, seems counter-productive at best. Outside HTML even Microsoft - who were one of the big creative forces behind XML - were pushing it everywhere, it was considered de riguer for making the mobile web a possibility outside Opera (which supported it anyway, but didn't require it), and it had, and still has, huge deployment. It just failed on the web browser platform, for reasons that are far easier to see in hindsight than they were at the time. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
It feels like we're making progress here. It seems as though there are basically two camps: 1) We shouldn't attempt to solve this problem. E.g. an explicit context element should be required for fragment parsing. 2) The basic idea of inferring a context element is workable and there are details to be worked out. I suggest that we suspend for a bit the question of camp 1 vs 2 and just focus on the best possible (i.e. mutually agreeable) solution for camp 2. It goes without saying, that I'd really appreciate feedback in this direction from folks who are in camp #1 -- I'm looking at you, Hixie -- even if you hate this idea, you still have to help =-P. Once we have a complete proposal written down, then we can decide whether it's worth doing or not. Now, WRT camp #2, there seem to be three issues to resolve 1) What is done with tokens which precede the first start tag? 2) What is the mechanism (if any) for handling SVG MathML elements? 3) What is the form of the API (e.g. DocumentFragment.innerHTML, document.parse(), etc...). I'm actually encouraged because, while I have preferences WRT the above, I think all the permutations would solve the use cases we have. I'll start a new thread whose purpose is to sort out an agreeable proposal for the behavior of camp #2. On Fri, May 11, 2012 at 5:39 AM, Scott González scott.gonza...@gmail.com wrote: On Fri, May 11, 2012 at 7:13 AM, Henri Sivonen hsivo...@iki.fi wrote: However, I'm not strongly opposed to adding innerHTML to DocumentFragment if we also add a method on Document that parses a string using the HTML parser regardless of the HTMLness flag of the document and returns a DocumentFragment (or has an optional extra argument for forcing XML parsing explicitly). Just a side note, but at least parsing XML seems to be fairly sane today. I haven't really done any testing around this, but it seems like this would get you parsing of arbitrary XML fragments, including leading and trailing text nodes: (new DOMParser).parseFromString( x + string + /x, text/xml ).documentElement.childNodes Obviously this is overly verbose compared to document.parse( string, flag ).
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 8:14 PM, Yehuda Katz wyc...@gmail.com wrote: On Wed, May 9, 2012 at 10:24 AM, Jonas Sicking jo...@sicking.cc wrote: I think it's much better to prioritize developers over implementers here and let implementers and spec writers tackle the complexity that comes with context-free parsing. I think the proposals here, and the fact that jQuery has implemented context-free HTML parsing, proves that it is technically possible. I agree. It also illustrates that the idea of the API is intuitively understood by developers. Does jQuery support SVG here though? Because that is where it gets cumbersome. But maybe that is not much of a problem in practice. Maybe we should support context=svg for that use case once it comes up? -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 09 May 2012 22:32:08 +0200, Scott González scott.gonza...@gmail.com wrote: Perhaps I'm missing something, but isn't foocaptionbar/caption an invalid use case? Any top-level element that needs a context can't be mixed with a text node. Are there cases where this isn't true? foo tspanbar/tspan baz -- Simon Pieters Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Tab Atkins Jr. wrote: Still, requiring an explicit context declaration *at all* defeats most of the purpose of the API. Again, if we don't auto-detect SVG (so that rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 11:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: Still, requiring an explicit context declaration *at all* defeats most of the purpose of the API. Again, if we don't auto-detect SVG (so that rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? That's pretty much exactly the description of the jQuery $([markup goes here]) functionality, which has been cited multiple times as the justification for this functionality. A previous thread about this functionality was started by Yehuda Katz from jQuery about that exact function, asking for this functionality. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Tab Atkins Jr. wrote: On Thu, May 10, 2012 at 11:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: Still, requiring an explicit context declaration *at all* defeats most of the purpose of the API. Again, if we don't auto-detect SVG (so that rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? That's pretty much exactly the description of the jQuery $([markup goes here]) functionality, which has been cited multiple times as the justification for this functionality. A previous thread about this functionality was started by Yehuda Katz from jQuery about that exact function, asking for this functionality. Yes, I understand that. But what's the use case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 3:18 PM, Ian Hickson i...@hixie.ch wrote: Yes, I understand that. But what's the use case? http://code.google.com/p/dart/source/search?q=new%5CsElement%5C.html%5C%28origq=new%5CsElement%5C.html%5C%28btnG=Search+Trunk I'm sure you can find a bunch of jQuery usages too. -- erik
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Why is simplicity not enough of an answer? If you're developing a widget which uses templates for various portions, then as the widget developer you won't know the context for each template. You could probably figure it out by rendering the templates from top to bottom and inspecting the element where the next template will be inserted, but that's unnecessary work if the browser can do it for us. Alternatively, you can ask the user to provide the context, but then your widget API goes from simple strings to either hashes or arrays. On Thu, May 10, 2012 at 6:18 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: On Thu, May 10, 2012 at 11:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: Still, requiring an explicit context declaration *at all* defeats most of the purpose of the API. Again, if we don't auto-detect SVG (so that rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? That's pretty much exactly the description of the jQuery $([markup goes here]) functionality, which has been cited multiple times as the justification for this functionality. A previous thread about this functionality was started by Yehuda Katz from jQuery about that exact function, asking for this functionality. Yes, I understand that. But what's the use case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 3:18 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: On Thu, May 10, 2012 at 11:20 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Tab Atkins Jr. wrote: Still, requiring an explicit context declaration *at all* defeats most of the purpose of the API. Again, if we don't auto-detect SVG (so that rect just parses as HTMLUnknownElement by default), we haven't gained much, since authors will *still* have to wrap their code in a regex-based detector if they expect to ever use SVG. (An optional context declaration that lets you determine which way the tagname conflicts go is fine, of course.) Can you elaborate on the use case for parsing markup into a document fragment when you don't know where you'll be putting the document fragment or what kind of content is in it? That's pretty much exactly the description of the jQuery $([markup goes here]) functionality, which has been cited multiple times as the justification for this functionality. A previous thread about this functionality was started by Yehuda Katz from jQuery about that exact function, asking for this functionality. Yes, I understand that. But what's the use case? The use-case is to provide a more convenient API for developers. The whole purpose of this thread is to provide a convenience API which provides context-free parsing. If we don't care about providing such convenience for authors we should just tell them to use the already-defined .innerHTML or a custom HTML parser and this whole thread is just moot. / Jonas
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Erik Arvidsson wrote:
On Thu, May 10, 2012 at 3:18 PM, Ian Hickson i...@hixie.ch wrote:
Yes, I understand that. But what's the use case?
http://code.google.com/p/dart/source/search?q=new%5CsElement%5C.html%5C%28origq=new%5CsElement%5C.html%5C%28btnG=Search+Trunk
I'm sure you can find a bunch of jQuery usages too.
None of the examples I see there seem to be cases where the parsing code
doesn't know what's going on ahead of time. As far as I can tell, they
could all easily just take an argument saying what parse mode to use, and
avoid all the problems of magically determining the parse mode; e.g. it
would allow the examples inserting style blocks to insert the contents
into existing style blocks instead of creating new ones, and it would
not run the risk of the parse mode changing unexpectedly due to unescaped
content in the various places that seem to be prone to injection attacks
(though maybe the \${} syntax is some sort of magically autoescaping
syntax? Though I don't see how it could be, it doesn't seem to have enough
context either).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Jonas Sicking wrote: Yes, I understand that. But what's the use case? The use-case is to provide a more convenient API for developers. The whole purpose of this thread is to provide a convenience API which provides context-free parsing. If we don't care about providing such convenience for authors we should just tell them to use the already-defined .innerHTML or a custom HTML parser and this whole thread is just moot. My understanding is that the context for this thread is how to support template. Neither innerHTML nor a custom HTML parser will help for that. On Thu, 10 May 2012, Scott Gonz�lez wrote: Why is simplicity not enough of an answer? It's a fine answer. But I don't think magical APIs are simple. Simplicity in this case IMHO argues for explicitly selected context. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 3:33 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Jonas Sicking wrote: Yes, I understand that. But what's the use case? The use-case is to provide a more convenient API for developers. The whole purpose of this thread is to provide a convenience API which provides context-free parsing. If we don't care about providing such convenience for authors we should just tell them to use the already-defined .innerHTML or a custom HTML parser and this whole thread is just moot. My understanding is that the context for this thread is how to support template. Neither innerHTML nor a custom HTML parser will help for that. On Thu, 10 May 2012, Scott González wrote: Why is simplicity not enough of an answer? It's a fine answer. But I don't think magical APIs are simple. Simplicity in this case IMHO argues for explicitly selected context. The jQuery API shows that at least jQuery developers don't agree with you regarding what is simpler here. / Jonas
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 3:33 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Scott González wrote: Why is simplicity not enough of an answer? It's a fine answer. But I don't think magical APIs are simple. Simplicity in this case IMHO argues for explicitly selected context. I don't think authors think like that. Most of them don't even understand that they need a context element to parse a HTML fragment. They just want an API that's simple and do reasonable things in most cases. IMO, it's okay for edge cases to be weird as long as we agree on one behavior. - Ryosuke
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 12:18 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Tab Atkins Jr. wrote:
On Thu, May 10, 2012 at 11:20 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Tab Atkins Jr. wrote:
Still, requiring an explicit context declaration *at all* defeats
most of the purpose of the API. Again, if we don't auto-detect SVG
(so that rect just parses as HTMLUnknownElement by default), we
haven't gained much, since authors will *still* have to wrap their
code in a regex-based detector if they expect to ever use SVG. (An
optional context declaration that lets you determine which way the
tagname conflicts go is fine, of course.)
Can you elaborate on the use case for parsing markup into a document
fragment when you don't know where you'll be putting the document
fragment or what kind of content is in it?
That's pretty much exactly the description of the jQuery $([markup goes
here]) functionality, which has been cited multiple times as the
justification for this functionality. A previous thread about this
functionality was started by Yehuda Katz from jQuery about that exact
function, asking for this functionality.
Yes, I understand that. But what's the use case?
I'll try to speak slowly and use small words.
The innerHTML API is convenient. It lets you set the entire
descendant tree of an element, creating elements and giving them
attributes, in a single call, using the same syntax you'd use if you
were writing it in HTML (module some extra quote-escaping maybe).
That's just the contents, though. If you create the element itself at
the same time, you can't. To do that, you need to either use
document.createElement() and a bunch of el.setAttr() calls before
using .innerHTML on it, or figure out a container element that your
desired element can correctly be a child of, use
document.createElement() for *that*, then set innerHTML and pull out
the sole child from the container. The first requires you to specify
the root of your fragment in a completely different and much less
convenient way from the contents. The second requires you to know
from context what a correct container is for the root of your fragment
and specify it alongside the fragment, even though this is officially
redundant information (it's fully determined by the fragment itself,
modulo the few rare element collisions between languages).
Additionally, the string may have been constructed from multiple
sources within the program, requiring additional non-trivial effort to
keep the context information with the string and ensure it's still
correct.
The alternative, which jQuery does, is to take the latter approach,
but have the library figure out the root element for you, so you don't
have to learn, remember, and specify the name of the context every
time you want to make a fragment. However, this is hacky and slower
than it has any need to be.
I'll go ahead and anticipate your response of they should just use
the Element.create() API - while Element.create() is great, it solves
a different use-case. Being able to construct DOM from raw HTML is
easy to read and write and understand, particularly when it's a static
fragment (or a concatenation of mostly static fragments), while
Element.create() requires a translation into a JS API with a much
different syntax. Element.create() is much more readable and writable
when you're making some DOM out of a *lot* of dynamic information.
In other words, this:
$(div class=fooimg src=+foosrc+/div)
is a lot easier than:
Element.create(div, {class: foo}, [ Element.create(img, {src: foosrc}) ]);
So, that's the use-case for this API.
~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Jonas Sicking wrote: The jQuery API shows that at least jQuery developers don't agree with you regarding what is simpler here. That wouldn't be the first time. :-) jQuery doesn't really match the Web platform's design aesthetic, with method names consisting purely of punctuation, methods that can be used both to register a callback and invoke a callback (click(f) vs click()), the style of using return values to enable chained invocations of methods on a specific object, etc. I have great respect for jQuery as a library, but I'm not sure it's necessarily a given that just because jQuery does something one way, it makes sense for the Web platform to do it that way as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
The innerHTML API is convenient. It lets you set the entire descendant
tree of an element, creating elements and giving them attributes, in a
single call, using the same syntax you'd use if you were writing it in
HTML (module some extra quote-escaping maybe).
[...]
I'll go ahead and anticipate your response of they should just use the
Element.create() API
That would indeed be my response.
while Element.create() is great, it solves a different use-case. Being
able to construct DOM from raw HTML is easy to read and write and
understand, particularly when it's a static fragment (or a concatenation
of mostly static fragments), while Element.create() requires a
translation into a JS API with a much different syntax. Element.create()
is much more readable and writable when you're making some DOM out of a
*lot* of dynamic information.
In other words, this:
$(div class=fooimg src=+foosrc+/div)
is a lot easier than:
Element.create(div, {class: foo}, [ Element.create(img, {src: foosrc})
]);
So, that's the use-case for this API.
The idea of building elements using string concatenation is a security
disaster. What if foosrc above contains ' onclick=...' ?
But ok, let's assume that the use case is create an element and its
subtree so that you can insert dynamically generated parts of an
application during runtime, e.g. inserting images in a dynamically
generated gallery, and security by damned.
If we're going to do that, then we don't need any lookahead at all. We
should support literally that: parsing one element and its descendants. We
determine what element is being generatd by looking at the top of the
string (div ... - it's a div, tr ... - it's a tr, etc), and we
parse until that element is popped from the stack or the end of the string
is reached. This avoids all the problems with doing magical lookahead.
But I'm very skeptical about creating new APIs to encourage authors to use
injection-prone, non-type-checked, direct string manipulation in script to
generate DOM trees.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 7:01 PM, Ian Hickson i...@hixie.ch wrote: But I'm very skeptical about creating new APIs to encourage authors to use injection-prone, non-type-checked, direct string manipulation in script to generate DOM trees. Do you realize that a very large percentage of developers are already doing this and will continue to do it regardless of whether UAs provide this functionality?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Let's pretend that $() doesn't exist and we exposed this functionality as jQuery.createElementFromHtml(). FWIW, web authors' design aesthetics don't really match the Web platform's design aesthetic. This is why broken APIs like querySelectorAll() will be replaced by intuitive APIs like find(). On Thu, May 10, 2012 at 6:50 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Jonas Sicking wrote: The jQuery API shows that at least jQuery developers don't agree with you regarding what is simpler here. That wouldn't be the first time. :-) jQuery doesn't really match the Web platform's design aesthetic, with method names consisting purely of punctuation, methods that can be used both to register a callback and invoke a callback (click(f) vs click()), the style of using return values to enable chained invocations of methods on a specific object, etc. I have great respect for jQuery as a library, but I'm not sure it's necessarily a given that just because jQuery does something one way, it makes sense for the Web platform to do it that way as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Scott Gonz�lez wrote: On Thu, May 10, 2012 at 7:01 PM, Ian Hickson i...@hixie.ch wrote: But I'm very skeptical about creating new APIs to encourage authors to use injection-prone, non-type-checked, direct string manipulation in script to generate DOM trees. Do you realize that a very large percentage of developers are already doing this and will continue to do it regardless of whether UAs provide this functionality? Sure. Lots of sites have XSS vulnerabilities, too. Back in the day, font was used everywhere, as were tables for layout. Over time, Web authors have moved away from such practices. Today, many Web authors use innerHTML. I see no reason to believe that they wouldn't move away from doing so, if we provide them with better tools. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 1:01 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
while Element.create() is great, it solves a different use-case. Being
able to construct DOM from raw HTML is easy to read and write and
understand, particularly when it's a static fragment (or a concatenation
of mostly static fragments), while Element.create() requires a
translation into a JS API with a much different syntax. Element.create()
is much more readable and writable when you're making some DOM out of a
*lot* of dynamic information.
In other words, this:
$(div class=fooimg src=+foosrc+/div)
is a lot easier than:
Element.create(div, {class: foo}, [ Element.create(img, {src: foosrc})
]);
So, that's the use-case for this API.
The idea of building elements using string concatenation is a security
disaster. What if foosrc above contains ' onclick=...' ?
Why are you assuming that the var there comes from potentially-unsafe
user-provided data? As I mentioned, a lot of the usage of this is
creating markup from static fragments, or from a concatenation of
mostly static fragments.
But ok, let's assume that the use case is create an element and its
subtree so that you can insert dynamically generated parts of an
application during runtime, e.g. inserting images in a dynamically
generated gallery, and security by damned.
Security doesn't have to have anything to do with this. The
dynamically generated sources could be purely script-generated,
providing request parameters that the server consumes.
If we're going to do that, then we don't need any lookahead at all. We
should support literally that: parsing one element and its descendants. We
determine what element is being generatd by looking at the top of the
string (div ... - it's a div, tr ... - it's a tr, etc), and we
parse until that element is popped from the stack or the end of the string
is reached. This avoids all the problems with doing magical lookahead.
This solves exactly the jQuery use-case of parse a document fragment
from a string.
It doesn't solve the *almost* identical case of parse the contents of
a template, because there you don't have a root element. (But you
still have to know the appropriate context, for the same reasons. And
that information is also still implicitly expressed in the data
already.)
But I'm very skeptical about creating new APIs to encourage authors to use
injection-prone, non-type-checked, direct string manipulation in script to
generate DOM trees.
As others have said, you've lost this race. jQuery is the most popular
JS library in the world. This particular functionality is used
*constantly* in jQuery; it's a very basic usage that is almost
impossible to avoid. Simply put, this is a *very* popular API, and
authors will continue to use it no matter what you don't do. We might
as well make it fast, easy, and complete.
~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 12:50 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Jonas Sicking wrote: The jQuery API shows that at least jQuery developers don't agree with you regarding what is simpler here. That wouldn't be the first time. :-) jQuery doesn't really match the Web platform's design aesthetic, with method names consisting purely of punctuation, methods that can be used both to register a callback and invoke a callback (click(f) vs click()), the style of using return values to enable chained invocations of methods on a specific object, etc. I have great respect for jQuery as a library, but I'm not sure it's necessarily a given that just because jQuery does something one way, it makes sense for the Web platform to do it that way as well. To a large extent, jQuery is the *reason* for the modern Web platform's design aesthetic. Claiming it doesn't really match is, frankly, somewhat farcical. You don't need to duplicate jQuery, but don't let your personal distaste for its style cloud your judgement. Authors *overwhelmingly* like this style. It would be good to pay attention to that. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, 11 May 2012, Tab Atkins Jr. wrote: This solves exactly the jQuery use-case of parse a document fragment from a string. Fantastic! Let's use it then. It doesn't solve the *almost* identical case of parse the contents of a template, because there you don't have a root element. That's fine. We don't have to have the same solution for every problem. But I'm very skeptical about creating new APIs to encourage authors to use injection-prone, non-type-checked, direct string manipulation in script to generate DOM trees. As others have said, you've lost this race. People said the same about font. I chose to be more optimistic. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
The innerHTML API is convenient. It lets you set the entire descendant
tree of an element, creating elements and giving them attributes, in a
single call, using the same syntax you'd use if you were writing it in
HTML (module some extra quote-escaping maybe).
[...]
I'll go ahead and anticipate your response of they should just use the
Element.create() API
That would indeed be my response.
while Element.create() is great, it solves a different use-case. Being
able to construct DOM from raw HTML is easy to read and write and
understand, particularly when it's a static fragment (or a concatenation
of mostly static fragments), while Element.create() requires a
translation into a JS API with a much different syntax. Element.create()
is much more readable and writable when you're making some DOM out of a
*lot* of dynamic information.
In other words, this:
$(div class=fooimg src=+foosrc+/div)
is a lot easier than:
Element.create(div, {class: foo}, [ Element.create(img, {src: foosrc})
]);
So, that's the use-case for this API.
The idea of building elements using string concatenation is a security
disaster. What if foosrc above contains ' onclick=...' ?
But ok, let's assume that the use case is create an element and its
subtree so that you can insert dynamically generated parts of an
application during runtime, e.g. inserting images in a dynamically
generated gallery, and security by damned.
If we're going to do that, then we don't need any lookahead at all. We
should support literally that: parsing one element and its descendants. We
determine what element is being generatd by looking at the top of the
string (div ... - it's a div, tr ... - it's a tr, etc), and we
parse until that element is popped from the stack or the end of the string
is reached. This avoids all the problems with doing magical lookahead.
This was more or less Yehuda's original proposal. If we can make this
work, I think it also solves the problem and would be acceptable. My
sense is that this solution probably introduces more complexity into
the parser and it's output isn't any superior.
Anne pointed out that accomplishing this isn't straightforward. I
forget what his examples were (I think they had to do with poorly
formed markup), but here's one that comes to mind which is valid
markup: What's the output for this
myDocFrag.innerHTML = optionOneoptiontwooptionthree;
But I'm very skeptical about creating new APIs to encourage authors to use
injection-prone, non-type-checked, direct string manipulation in script to
generate DOM trees.
--
Ian Hickson U+1047E )\._.,--,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Rafael Weinstein wrote: On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 May 2012, Tab Atkins Jr. wrote: But ok, let's assume that the use case is create an element and its subtree so that you can insert dynamically generated parts of an application during runtime, e.g. inserting images in a dynamically generated gallery [...] [...[ but here's one that comes to mind which is valid markup: What's the output for this myDocFrag.innerHTML = optionOneoptiontwooptionthree; My proposal would return a single option element with the value One. But the example here suggests a different use case. There are presumably three elements there, not one. If this is a use case we want to address, then let's go back to the use cases again: what is the problem we are trying to solve? When would you create a document fragment of some options, instead of just creating a select with options? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 7:15 PM, Rafael Weinstein rafa...@google.comwrote: On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote: If we're going to do that, then we don't need any lookahead at all. We should support literally that: parsing one element and its descendants. We determine what element is being generatd by looking at the top of the string (div ... - it's a div, tr ... - it's a tr, etc), and we parse until that element is popped from the stack or the end of the string is reached. This avoids all the problems with doing magical lookahead. This was more or less Yehuda's original proposal. If we can make this work, I think it also solves the problem and would be acceptable. My sense is that this solution probably introduces more complexity into the parser and it's output isn't any superior. Yehuda has actually been complaining about this limitation for quite a while. I know that he would not consider this a full solution.
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 1:19 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Rafael Weinstein wrote: On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 May 2012, Tab Atkins Jr. wrote: But ok, let's assume that the use case is create an element and its subtree so that you can insert dynamically generated parts of an application during runtime, e.g. inserting images in a dynamically generated gallery [...] [...[ but here's one that comes to mind which is valid markup: What's the output for this myDocFrag.innerHTML = optionOneoptiontwooptionthree; My proposal would return a single option element with the value One. Ah, I didn't get that you were making that distinction. Sorry, then, in that case your suggestion isn't quite right. But the example here suggests a different use case. There are presumably three elements there, not one. If this is a use case we want to address, then let's go back to the use cases again: what is the problem we are trying to solve? When would you create a document fragment of some options, instead of just creating a select with options? For something like this: $(pExample +exnum+:/ppimg src=+exsrc+).appendTo(container); (Presumably, this is run in a loop that generates the exnum and exsrc variables programmatically.) The fragment is two sibling elements, but it's conceptually a unit. There's no container separating the units from each other. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 4:27 PM, Scott González scott.gonza...@gmail.com wrote: On Thu, May 10, 2012 at 7:15 PM, Rafael Weinstein rafa...@google.com wrote: On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote: If we're going to do that, then we don't need any lookahead at all. We should support literally that: parsing one element and its descendants. We determine what element is being generatd by looking at the top of the string (div ... - it's a div, tr ... - it's a tr, etc), and we parse until that element is popped from the stack or the end of the string is reached. This avoids all the problems with doing magical lookahead. This was more or less Yehuda's original proposal. If we can make this work, I think it also solves the problem and would be acceptable. My sense is that this solution probably introduces more complexity into the parser and it's output isn't any superior. Yehuda has actually been complaining about this limitation for quite a while. I know that he would not consider this a full solution. Ah, sorry. I didn't quite understand Hixie's proposal. I retract my statement -- this isn't a workable solution. Also, I'm curious why it's ok to peak at the first few characters of the string, and not ok to peak at the token stream until we see the first start tag?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 10 May 2012, Rafael Weinstein wrote: Also, I'm curious why it's ok to peak at the first few characters of the string, and not ok to peak at the token stream until we see the first start tag? Because it's predictable and easy to debug. When you're dealing with a weird effect caused by some accidental markup hundreds of lines down a string, it's really hard to work out what's going on. When the effect is caused by the very first thing in the string, it's much easier to notice it. (You see this kind problem sometimes on Web pages where text/plain files are sent as text/html, or text files are slightly augmented with HTML without properly escaping everything -- they render fine until they get to something that accidentally looks like markup, and the parser does its stuff, and you wonder why half of the 100-page document is bold.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, 11 May 2012, Tab Atkins Jr. wrote: For something like this: $(pExample +exnum+:/ppimg src=+exsrc+).appendTo(container); Can we really not come up with anything better? It makes me really sad to think that the best we can do here is to go from a nice structured environment, concatenate our data together into a string, and then reparse the string back into structured data to add it to the DOM. I understand that people do this kind of thing all the time, but I've always at least assumed that everyone agreed that it was a necessarily evil because the alternatives were even worse. I had hope when we were discussing Element.create() that maybe we were finally coming up with a workable alternative, but as far as I can tell that never went anywhere and now we're actually talking about adding APIs to _support_ string-based DOM tree generation as if it's an actually sane way of writing code. Am I really the only one here who thinks this is horrifying? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Fri, May 11, 2012 at 2:03 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
For something like this:
$(pExample +exnum+:/ppimg src=+exsrc+).appendTo(container);
Can we really not come up with anything better? It makes me really sad to
think that the best we can do here is to go from a nice structured
environment, concatenate our data together into a string, and then reparse
the string back into structured data to add it to the DOM.
I understand that people do this kind of thing all the time, but I've
always at least assumed that everyone agreed that it was a necessarily
evil because the alternatives were even worse. I had hope when we were
discussing Element.create() that maybe we were finally coming up with a
workable alternative, but as far as I can tell that never went anywhere
and now we're actually talking about adding APIs to _support_ string-based
DOM tree generation as if it's an actually sane way of writing code.
Am I really the only one here who thinks this is horrifying?
I'm sure you're not the only one, but you're a rarity. Most authors
find it really good.
It's very simple to go from having this in your static mockup:
pExample 1: pimg src=image.php?foo=bar
...to having this in your real site:
$(pExample +exnum+:pimg src=+exsrc+).appendTo(container);
It's substantially harder to go to this:
container.appendChild(Element.create(p, [Example+exnum]));
container.appendChild(Element.create(p, [Element.create(img, {src:
exsrc})]));
And it's a lot harder to read, too.
Again, Element.create() is great when you're generating elements out
of lots of dynamic pieces (all the +foo+ in your string gets
unwieldy and awkward). It's harder to use when you're generating
elements that are static or mostly so.
~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 4:58 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Rafael Weinstein wrote: Also, I'm curious why it's ok to peak at the first few characters of the string, and not ok to peak at the token stream until we see the first start tag? Because it's predictable and easy to debug. When you're dealing with a weird effect caused by some accidental markup hundreds of lines down a string, it's really hard to work out what's going on. When the effect is caused by the very first thing in the string, it's much easier to notice it. (You see this kind problem sometimes on Web pages where text/plain files are sent as text/html, or text files are slightly augmented with HTML without properly escaping everything -- they render fine until they get to something that accidentally looks like markup, and the parser does its stuff, and you wonder why half of the 100-page document is bold.) In the abstract, I actually agree with you, but this happens to be a case when this is effectively never going to be a problem. Just have a look at *any* templating langauge. Any time you see some kind of conditional, or loop construct, look at it's contents and imagine that that's what'll be passed to innerHTML here. 99.9% of the time it's going to either be all character tokens, or whitespace followed by a start tag. You're letting an non-existent problem kill a perfectly useful proposal. I'm not a huge fan of everything jQuery does either, but regardless of it's objective goodness, it has already done the test by offering this functionality. The kind of bug your describing hasn't been observed at all. Someone with more jQuery-cred correct me if I'm wrong. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 8:03 PM, Ian Hickson i...@hixie.ch wrote: I understand that people do this kind of thing all the time, but I've always at least assumed that everyone agreed that it was a necessarily evil because the alternatives were even worse. I had hope when we were discussing Element.create() that maybe we were finally coming up with a workable alternative, but as far as I can tell that never went anywhere and now we're actually talking about adding APIs to _support_ string-based DOM tree generation as if it's an actually sane way of writing code. I'm not sure why this isn't sane. It's exactly how everyone writes their code on the server, where the majority of their markup is generated. Raw HTML with variables is much more human friendly than structured JavaScript objects and arrays. Developers are already in the mindset of writing HTML fragments. They do it everywhere. In a traditional web model, you never run into the context problem because the server always generates a full page. So even if you're using nested templates on the server, with some of your templates being fragments that might require context (say a tr), by the time it reaches the browser it's already concatenated into a full page. As web apps become more advanced and servers start returning fragments (or the fragments are just generated directly on the client), then these issues start to crop up. In the developer's mind, nothing has changed about how to generate the markup. There's little incentive to switch from strings to Element.create(), but there's a lot of incentive to stay with strings.
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 5:03 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 May 2012, Tab Atkins Jr. wrote: For something like this: $(pExample +exnum+:/ppimg src=+exsrc+).appendTo(container); Can we really not come up with anything better? It makes me really sad to think that the best we can do here is to go from a nice structured environment, concatenate our data together into a string, and then reparse the string back into structured data to add it to the DOM. I understand that people do this kind of thing all the time, but I've always at least assumed that everyone agreed that it was a necessarily evil because the alternatives were even worse. I had hope when we were discussing Element.create() that maybe we were finally coming up with a workable alternative, but as far as I can tell that never went anywhere and now we're actually talking about adding APIs to _support_ string-based DOM tree generation as if it's an actually sane way of writing code. Am I really the only one here who thinks this is horrifying? I find it horrifying, and I'll venture that Yehuda and the author of every other templating mechanism does as well -- at least in the sense that all of our goal is to generally remove the *need* for page authors to have to use innerHTML, by declaring how their views should be composed, rather than doing it imperatively. Libraries exist at a higher leverage point and if *they* do the right thing, then a greater number of authors are protected. Adding this, makes it easier for libraries (and if I get my way, the platform itself) to do this right so that authors can stop constructing DOM imperatively altogether. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Yehuda Katz
(ph) 718.877.1325
On Thu, May 10, 2012 at 5:28 PM, Rafael Weinstein rafa...@google.comwrote:
On Thu, May 10, 2012 at 5:03 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
For something like this:
$(pExample +exnum+:/ppimg
src=+exsrc+).appendTo(container);
Can we really not come up with anything better? It makes me really sad to
think that the best we can do here is to go from a nice structured
environment, concatenate our data together into a string, and then
reparse
the string back into structured data to add it to the DOM.
I understand that people do this kind of thing all the time, but I've
always at least assumed that everyone agreed that it was a necessarily
evil because the alternatives were even worse. I had hope when we were
discussing Element.create() that maybe we were finally coming up with a
workable alternative, but as far as I can tell that never went anywhere
and now we're actually talking about adding APIs to _support_
string-based
DOM tree generation as if it's an actually sane way of writing code.
Am I really the only one here who thinks this is horrifying?
I find it horrifying, and I'll venture that Yehuda and the author of
every other templating mechanism does as well -- at least in the sense
that all of our goal is to generally remove the *need* for page
authors to have to use innerHTML, by declaring how their views should
be composed, rather than doing it imperatively.
Correct. The Handlebars templating engine, for example, protects against
injection by default. If you create the following template:
img src={{imgSource}}
the contents of imgSource are automatically escaped before being
concatenated. An explicit opt-out (via triple-mustache) is required in
order to allow unescaped HTML to make its way in.
It is, of course, possible for the output of a template engine to be a
String like trtdfoo/td/tr. The reason this is a problem is
decoupling: I would prefer if the code that creates my DOM didn't also need
to know about the exact context that another part of the code plans to
insert it into. It is of course possible to pass that information around,
but it is cumbersome and makes it harder to encapsulate concerns.
Libraries exist at a higher leverage point and if *they* do the right
thing, then a greater number of authors are protected. Adding this,
makes it easier for libraries (and if I get my way, the platform
itself) to do this right so that authors can stop constructing DOM
imperatively altogether.
Yep. My goal is for my users to use templates, and let me insert the
resulting DOM in the appropriate place. Ember.js users virtually never
construct and insert DOM directly, even though they work with HTML rather
extensively.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 5:13 PM, Rafael Weinstein rafa...@google.comwrote: On Thu, May 10, 2012 at 4:58 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 May 2012, Rafael Weinstein wrote: Also, I'm curious why it's ok to peak at the first few characters of the string, and not ok to peak at the token stream until we see the first start tag? Because it's predictable and easy to debug. When you're dealing with a weird effect caused by some accidental markup hundreds of lines down a string, it's really hard to work out what's going on. When the effect is caused by the very first thing in the string, it's much easier to notice it. (You see this kind problem sometimes on Web pages where text/plain files are sent as text/html, or text files are slightly augmented with HTML without properly escaping everything -- they render fine until they get to something that accidentally looks like markup, and the parser does its stuff, and you wonder why half of the 100-page document is bold.) In the abstract, I actually agree with you, but this happens to be a case when this is effectively never going to be a problem. Just have a look at *any* templating langauge. Any time you see some kind of conditional, or loop construct, look at it's contents and imagine that that's what'll be passed to innerHTML here. 99.9% of the time it's going to either be all character tokens, or whitespace followed by a start tag. You're letting an non-existent problem kill a perfectly useful proposal. I'm not a huge fan of everything jQuery does either, but regardless of it's objective goodness, it has already done the test by offering this functionality. The kind of bug your describing hasn't been observed at all. Someone with more jQuery-cred correct me if I'm wrong. I think our best final solution is something roughly like http://wiki.ecmascript.org/doku.php?id=harmony:quasis. Look at safehtml as an example. If browsers provide that method, that strikes the best balance of security and convenience. That said, innerHTML is here. That it doesn't work on DocumentFragment just makes people have to use dummy container elements and write less efficient code. I don't think implementing this will have any effect on whether people will use our eventual safehtml solution. In the interim, it's just confusing and clunky that innerHTML works everywhere except DocumentFragment. IMO it should work on Document as well. As a web developer who has done a lot of work with both Element.create style APIs and with jQuery string-based APIs, it's really much more of a pleasure to use the latter. It makes for much more concise and readable code. Those benefits are high enough that it justifies the clunkiness and the need to be XSS-careful. Template element has none of the issues of horrifying string-based approaches and is only related to this discussion in that it needs context-free parsing. Ojan
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, May 10, 2012 at 4:19 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Rafael Weinstein wrote:
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
But ok, let's assume that the use case is create an element and its
subtree so that you can insert dynamically generated parts of an
application during runtime, e.g. inserting images in a dynamically
generated gallery [...]
[...[ but here's one that comes to mind which is valid markup: What's
the output for this
myDocFrag.innerHTML = optionOneoptiontwooptionthree;
My proposal would return a single option element with the value One.
But the example here suggests a different use case. There are presumably
three elements there, not one. If this is a use case we want to address,
then let's go back to the use cases again: what is the problem we are
trying to solve? When would you create a document fragment of some
options, instead of just creating a select with options?
BTW, for example
In handlerbars,
select
{{# each optionListThatComeInPairs }}
option{{ firstThingInPair }}
option{{ secondThingInPair }}
{{/ each }}
/select
Or equivalently, in MDV
select
template iterate=optionsListThatComeInPairs
option{{ firstThingInPair }}
option{{ secondThingInPair }}
/template
/select
--
Ian Hickson U+1047E )\._.,--,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinstein rafa...@google.com wrote: What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. It's not controversial as long as an HTML context is assumed. I think it is still controversial for SVG and MathML elements that aren't wrapped in an svg or math element. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. Why should the programmer first create a document fragment and then set a property on it? Why not introduce four methods on Document that return a DocumentFragment: document.parseFragmentHTML (parses like template.innerHTML), document.parseFragementSVG (parses like svg.innerHTML), document.parseFragmentMathML (parses like math.innerHTML) and document.parseFragmentXML (parses like innerHTML in the XML mode without namespace context)? This would avoid magic for distinguishing HTML a and SVG a. On Thu, Apr 26, 2012 at 8:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: (In my dreams, we just merge SVG into the HTML namespace, and then this step disappears.) In retrospect, it would have been great if Namespaces in XML had never been introduced and SVG, MathML and HTML shared a single namespace. However, at this point trying to merge the namespaces would lead to chameleon namespaces which are evil and more trouble than fixing the historical mistake is worth. I feel very strongly that vendors and the W3C should stay away from turning SVG into a chameleon namespace. SVG is way more established them CSS gradients or Flexbox in terms of what kind of changes are acceptable. See http://lists.w3.org/Archives/Public/www-archive/2009Feb/0065.html as well as various XML experiences from non-browser contexts. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 9:52 AM, Henri Sivonen hsivo...@iki.fi wrote: Why should the programmer first create a document fragment and then set a property on it? Why not introduce four methods on Document that return a DocumentFragment: document.parseFragmentHTML (parses like template.innerHTML), document.parseFragementSVG (parses like svg.innerHTML), document.parseFragmentMathML (parses like math.innerHTML) and document.parseFragmentXML (parses like innerHTML in the XML mode without namespace context)? This would avoid magic for distinguishing HTML a and SVG a. We want template to be usable with SVG (and I guess MathML, though I have no idea how useful that would be), though. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On 05/09/2012 10:16 AM, James Graham wrote: On 05/09/2012 09:52 AM, Henri Sivonen wrote: On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinsteinrafa...@google.com wrote: What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. It's not controversial as long as an HTML context is assumed. I think it is still controversial for SVG and MathML elements that aren't wrapped in ansvg ormath element. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. Why should the programmer first create a document fragment and then set a property on it? Why not introduce four methods on Document that return a DocumentFragment: document.parseFragmentHTML (parses like template.innerHTML), document.parseFragementSVG (parses like svg.innerHTML), document.parseFragmentMathML (parses like math.innerHTML) and document.parseFragmentXML (parses like innerHTML in the XML mode without namespace context)? This would avoid magic for distinguishing HTMLa and SVGa. I think introducing four seperate methodsWithLongNames on document is not creating an API that authors will actually use. Instead it would likely be wrapped in some less-verbose API with a single entry point and library-specific magic and regexp to determine which entry point to use. So I fear this solution may just be punting the problem to a higher layer, where it will be more inconsistently solved. By way of a concrete-strawman (or whatever it is one is supposed to say) proposal: document.parse(string, [auto|html|svg|mathml|xml]) With auto being the default and doing magic, and the other options allowing one to disable the magic.
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 10:16 AM, James Graham jgra...@opera.com wrote: On 05/09/2012 09:52 AM, Henri Sivonen wrote: On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinsteinrafa...@google.com wrote: What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. It's not controversial as long as an HTML context is assumed. I think it is still controversial for SVG and MathML elements that aren't wrapped in ansvg ormath element. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. Why should the programmer first create a document fragment and then set a property on it? Why not introduce four methods on Document that return a DocumentFragment: document.parseFragmentHTML (parses like template.innerHTML), document.parseFragementSVG (parses like svg.innerHTML), document.parseFragmentMathML (parses like math.innerHTML) and document.parseFragmentXML (parses like innerHTML in the XML mode without namespace context)? This would avoid magic for distinguishing HTMLa and SVGa. I think introducing four seperate methodsWithLongNames on document is not creating an API that authors will actually use. Instead it would likely be wrapped in some less-verbose API with a single entry point and library-specific magic and regexp to determine which entry point to use. So I fear this solution may just be punting the problem to a higher layer, where it will be more inconsistently solved. Yes. In short, while making it Just Work for HTML is a great step, if you *still* need to use regex to tell when you're trying to build SVG so you can change the context, we aren't actually gaining much. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 11:39 AM, James Graham jgra...@opera.com wrote: document.parse(string, [auto|html|svg|mathml|xml]) Makes sense at least for the options other than auto. With auto being the default and doing magic, and the other options allowing one to disable the magic. I worry about introducing magic into APIs. It starts with good intentions but can lead to regrettable results. For MathML, if the parser contains a list of all MathML elements, the magic can work at any point in time if the parser and the input are from the same point in time but will fail if the parser is older vintage than the input given to it. (image can be treated as MathML here, since presumably the magic image is only needed for parsing legacy HTML pages.) Are we OK with the incorrect behavior when the input and the parser are of different vintage? (Note that the full document HTML parsing algorithm only has this problem for camel case SVG elements, which is a non-problem if the SVG working group can refrain from introducing more camel case elements.) With SVG, there's the problem that a is common and ambiguous. It seems bad to introduce an API that does reliable magic for almost everything but is unreliable for one common thing. Solving this problem with lookahead would be bad, because it would be surprising for a in a/a and a in apath//a to mean different things. Solving this problem with chameleon namespaces would introduce worse problems. I don't see any good way to solve the contextless a vs. a problem with magic. (If SVG moves away from xlink:href, we can't even use attributes to disambiguate.) If we end up doing (flawed) list-based magic, we need to make sure the SVG working group is on board and henceforth avoids local name collisions with HTML and MathML. If the API required the caller to request SVG explicitly, would it be a sure thing that jQuery would build magic heuristics on the library side? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 11:10 AM, Henri Sivonen hsivo...@iki.fi wrote: If we end up doing (flawed) list-based magic, we need to make sure the SVG working group is on board and henceforth avoids local name collisions with HTML and MathML. Yes, we (SVGWG) is on board with this. We won't introduce new elements that conflict. (Currently, SVG and HTML conflict with style, script, a, and font. SVG and MathML conflict in set and image. HTML and MathML don't conflict at all.) If the API required the caller to request SVG explicitly, would it be a sure thing that jQuery would build magic heuristics on the library side? I just pinged Yehuda to check, but I'd wager that jQuery will add SVG detection to their current context detection if SVG continues its climb into relevance for webdevs. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 11:10 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 9, 2012 at 11:39 AM, James Graham jgra...@opera.com wrote: document.parse(string, [auto|html|svg|mathml|xml]) Makes sense at least for the options other than auto. The idea is that whatever comes out of this can also be used for the template element. There is no known context there. And for fragment parsing deployed thus far (jQuery) the context is not known either. If the context was known we would not need to find it in the first place. So assuming some high-level context (svg/math/...) is known seems kind of weird to me. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On 5/9/12 5:24 AM, Tab Atkins Jr. wrote: (Currently, SVG and HTML conflict withstyle,script,a, and font. SVG and MathML conflict inset andimage. HTML and MathML don't conflict at all.) HTML has image, during parsing. So it conflicts with both SVG and MathML there... Though I suppose we could turn off that HTML feature inside templates; there's unlikely to be legacy content depending on it. ;) -Boris
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
I'm very much of a like mike with Henri here, in that I'm frustrated with the situation we're currently in WRT SVG MathML parsing foreign content in HTML, etc... In particular, I'm tempted to feel like SVG and MathML made this bed for themselves and they should now have to sleep in it. However, on balance, I'm in favor of this magic (picking the correct namespace based on the first element's tagName) for the following three reasons: *Not doing so means that using template to declare web components that do super awesome SVG stuff much more cumbersome. *Doing so doesn't negatively impact HTML. *SVG mostly working (modulo a few overlapping tagNames), is preferable to not working at all (and there's not really a problem with MathML). Much as I dislike it, parsing foreign content is kind of already gross magic, and it seems to me like this behavior is in keeping with what's already there. Moreover, not including it kind of punishes the wrong people, by making webdevs sleep in the bed that SVG and MathML made. I.e. It would make my life easier, but at the expense of webdevs. On Wed, May 9, 2012 at 12:52 AM, Henri Sivonen hsivo...@iki.fi wrote: On Tue, Apr 24, 2012 at 6:39 AM, Rafael Weinstein rafa...@google.com wrote: What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. It's not controversial as long as an HTML context is assumed. I think it is still controversial for SVG and MathML elements that aren't wrapped in an svg or math element. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. Why should the programmer first create a document fragment and then set a property on it? Why not introduce four methods on Document that return a DocumentFragment: document.parseFragmentHTML (parses like template.innerHTML), document.parseFragementSVG (parses like svg.innerHTML), document.parseFragmentMathML (parses like math.innerHTML) and document.parseFragmentXML (parses like innerHTML in the XML mode without namespace context)? This would avoid magic for distinguishing HTML a and SVG a. On Thu, Apr 26, 2012 at 8:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: (In my dreams, we just merge SVG into the HTML namespace, and then this step disappears.) In retrospect, it would have been great if Namespaces in XML had never been introduced and SVG, MathML and HTML shared a single namespace. However, at this point trying to merge the namespaces would lead to chameleon namespaces which are evil and more trouble than fixing the historical mistake is worth. I feel very strongly that vendors and the W3C should stay away from turning SVG into a chameleon namespace. SVG is way more established them CSS gradients or Flexbox in terms of what kind of changes are acceptable. See http://lists.w3.org/Archives/Public/www-archive/2009Feb/0065.html as well as various XML experiences from non-browser contexts. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Quick alternative proposal that might work for both template parsing and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Have innerHTML use that as the context element to the fragment parsing
algorithm.
df.innerHTML = 'p::before { content: 'hello world'; }';
Have template take an argument that's the element tag name for it to
use to create its context element. Defaults to body.
template context=tr td /template
template context=svg g/ /template
Parse template by creating a new Document object that's like the ones
you get from createDocument() (i.e. dead), and then creating a
DocumentFragment owned by that Document, and then pushing that
DocumentFragment onto the stack instead of the template element, but
set up to act like the template element for the purposes of being
popped off. (Except when parsing without a browsing context, then you
just parse normally.)
Not sure how solid this is, but it's an idea at least. Hopefully an
original one, though I'm sure y'all have considered it before. :-)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 09 May 2012 19:01:42 +0200, Ian Hickson i...@hixie.ch wrote:
Quick alternative proposal that might work for both template parsing
and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Or just string with the tag name, so it works the same as template
context?
Have innerHTML use that as the context element to the fragment parsing
algorithm.
df.innerHTML = 'p::before { content: 'hello world'; }';
Have template take an argument that's the element tag name for it to
use to create its context element. Defaults to body.
template context=tr td /template
template context=svg g/ /template
Parse template by creating a new Document object that's like the
ones
you get from createDocument() (i.e. dead), and then creating a
DocumentFragment owned by that Document, and then pushing that
DocumentFragment onto the stack instead of the template element, but
set up to act like the template element for the purposes of being
popped off. (Except when parsing without a browsing context, then you
just parse normally.)
Not sure how solid this is, but it's an idea at least. Hopefully an
original one, though I'm sure y'all have considered it before. :-)
--
Simon Pieters
Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Users will surely find this annoying when they know that it can be
automated. This will also result in users being tripped up on this as they
learn about this feature by looking at some other code that isn't passing a
context (because it doesn't need one) and then all of a sudden they hit a
case where they need one and it fails.
On Wed, May 9, 2012 at 1:01 PM, Ian Hickson i...@hixie.ch wrote:
Quick alternative proposal that might work for both template parsing and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Have innerHTML use that as the context element to the fragment parsing
algorithm.
df.innerHTML = 'p::before { content: 'hello world'; }';
Have template take an argument that's the element tag name for it to
use to create its context element. Defaults to body.
template context=tr td /template
template context=svg g/ /template
Parse template by creating a new Document object that's like the ones
you get from createDocument() (i.e. dead), and then creating a
DocumentFragment owned by that Document, and then pushing that
DocumentFragment onto the stack instead of the template element, but
set up to act like the template element for the purposes of being
popped off. (Except when parsing without a browsing context, then you
just parse normally.)
Not sure how solid this is, but it's an idea at least. Hopefully an
original one, though I'm sure y'all have considered it before. :-)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 09 May 2012 19:29:42 +0200, Ryosuke Niwa rn...@webkit.org wrote:
On May 9, 2012 10:26 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 09 May 2012 19:01:42 +0200, Ian Hickson i...@hixie.ch wrote:
Quick alternative proposal that might work for both template parsing
and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null
means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Or just string with the tag name, so it works the same as template
context?
What happens when I pass a?
I think that should get in body. Do we need to support anything more
than svg and math to get foreign content parsing here?
--
Simon Pieters
Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Yehuda Katz
(ph) 718.877.1325
On Wed, May 9, 2012 at 10:24 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 9, 2012 at 10:01 AM, Ian Hickson i...@hixie.ch wrote:
Quick alternative proposal that might work for both template parsing
and
DocumentFragment.innerHTML:
Have createDocumentFragment() take as an argument a context element.
Maybe also make it a mutable attribute of the object. Defaults to its
owner document's body element or root element or some such. Null means
no root element.
var df = document.createDocumentFragment(document.body);
df.contextElement = document.createElement('style');
Have innerHTML use that as the context element to the fragment parsing
algorithm.
df.innerHTML = 'p::before { content: 'hello world'; }';
Have template take an argument that's the element tag name for it to
use to create its context element. Defaults to body.
template context=tr td /template
template context=svg g/ /template
Parse template by creating a new Document object that's like the ones
you get from createDocument() (i.e. dead), and then creating a
DocumentFragment owned by that Document, and then pushing that
DocumentFragment onto the stack instead of the template element, but
set up to act like the template element for the purposes of being
popped off. (Except when parsing without a browsing context, then you
just parse normally.)
Not sure how solid this is, but it's an idea at least. Hopefully an
original one, though I'm sure y'all have considered it before. :-)
I think having to provide a context every where where you want to
parse HTML is creating very bad developer ergonomics. As others have
pointed out, it will likely just lead to developers ignoring these new
APIs and continue to write their own parsing algorithms.
I think it's much better to prioritize developers over implementers
here and let implementers and spec writers tackle the complexity that
comes with context-free parsing. I think the proposals here, and the
fact that jQuery has implemented context-free HTML parsing, proves
that it is technically possible.
I agree. It also illustrates that the idea of the API is intuitively
understood by developers.
/ Jonas
/ Jonas
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 9 May 2012, Jonas Sicking wrote: I think having to provide a context every wherewhere you want to parse HTML is creating very bad developer ergonomics. You wouldn't have to provide it everywhere. The vast majority of the time, the default body context is fine. I think the proposals here, and the fact that jQuery has implemented context-free HTML parsing, proves that it is technically possible. I don't think look-ahead and magically determining the parse mode from a preparse of the string is really a sane solution. It doesn't handle all cases (e.g. it doesn't handle the style example I gave), and it results in very weird results (very bad developer ergonomics) for cases like 1GB of text followed by caption vs 1GB of text followed by coption (where the former loses the text and the latter does not). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Perhaps I'm missing something, but isn't foocaptionbar/caption an invalid use case? Any top-level element that needs a context can't be mixed with a text node. Are there cases where this isn't true? I don't know how the actual parsing works, but the following logic seems reasonable to me: If the first character is not then use the default context. Otherwise, read all continuous characters that are valid for element names. If the element name found is valid, then use that to determine the context. Otherwise, use the default context. Parse the string using the context determined above. This should result in every possible string having a deterministic outcome, based on existing rules. On Wed, May 9, 2012 at 3:51 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 May 2012, Jonas Sicking wrote: I think having to provide a context every wherewhere you want to parse HTML is creating very bad developer ergonomics. You wouldn't have to provide it everywhere. The vast majority of the time, the default body context is fine. I think the proposals here, and the fact that jQuery has implemented context-free HTML parsing, proves that it is technically possible. I don't think look-ahead and magically determining the parse mode from a preparse of the string is really a sane solution. It doesn't handle all cases (e.g. it doesn't handle the style example I gave), and it results in very weird results (very bad developer ergonomics) for cases like 1GB of text followed by caption vs 1GB of text followed by coption (where the former loses the text and the latter does not). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 12:51 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 May 2012, Jonas Sicking wrote: I think having to provide a context every wherewhere you want to parse HTML is creating very bad developer ergonomics. You wouldn't have to provide it everywhere. The vast majority of the time, the default body context is fine. But the whole point of DocumentFragment.innerHTML is that you'd need to inspect the markup in order to know the context fragment. body may be fine 98%, but the use cases that motivated this feature need to know 100% of the time if it needs to be something else. I think the proposals here, and the fact that jQuery has implemented context-free HTML parsing, proves that it is technically possible. I don't think look-ahead and magically determining the parse mode from a preparse of the string is really a sane solution. It doesn't handle all cases (e.g. it doesn't handle the style example I gave), and it results in very weird results (very bad developer ergonomics) for cases like 1GB of text followed by caption vs 1GB of text followed by coption (where the former loses the text and the latter does not). For me, both of these examples fall squarely in the I can live with that bucket. I'll try again to persuade everyone that we not let perfect be the enemy of good. =-) -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 9:51 PM, Ian Hickson i...@hixie.ch wrote: I think the proposals here, and the fact that jQuery has implemented context-free HTML parsing, proves that it is technically possible. I don't think look-ahead and magically determining the parse mode from a preparse of the string is really a sane solution. It doesn't handle all cases (e.g. it doesn't handle the style example I gave), and it results in very weird results (very bad developer ergonomics) for cases like 1GB of text followed by caption vs 1GB of text followed by coption (where the former loses the text and the latter does not). Manually providing a context element in order to get SVG parsing is pretty crappy. There's no really good reason to do so. It would just mean that as SVG continues to grow in popularity, jQuery-style throw a regex against the string to see what context to use will continue to be popular/necessary, which is a pretty bad solution for authors, particularly when we could just *do the right thing* in a way that works almost all of the time. Your example about caption vs coption is a ridiculously rare case. It seems silly to worry about devs misspelling a particular rare HTML tag, in a particular situation that's invalid *anyway*, while blithely dismissing the enormously larger, non-crazy, valid-markup-using use-case of I want to create grect//g from a string the same way I can do divimg/div. If you're going to keep bringing this up, please justify why it's actually something we should worry about. Otherwise, this is a case that can be summarily dismissed. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 10:32 PM, Scott González scott.gonza...@gmail.com wrote: Perhaps I'm missing something, but isn't foocaptionbar/caption an invalid use case? Any top-level element that needs a context can't be mixed with a text node. Are there cases where this isn't true? Yes - SVG, MathML, and Ruby text can all, in some circumstances, validly have text before the first start tag of a fragment. In addition, comments are always valid. They're neither text nor start tags. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, May 9, 2012 at 1:32 PM, Rafael Weinstein rafa...@google.com wrote:
On Wed, May 9, 2012 at 12:51 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 9 May 2012, Jonas Sicking wrote:
I think having to provide a context every wherewhere you want to
parse HTML is creating very bad developer ergonomics.
You wouldn't have to provide it everywhere. The vast majority of the time,
the default body context is fine.
But the whole point of DocumentFragment.innerHTML is that you'd need
to inspect the markup in order to know the context fragment. body
may be fine 98%, but the use cases that motivated this feature need to
know 100% of the time if it needs to be something else.
I think the proposals here, and the fact that jQuery has implemented
context-free HTML parsing, proves that it is technically possible.
I don't think look-ahead and magically determining the parse mode from a
preparse of the string is really a sane solution. It doesn't handle all
cases (e.g. it doesn't handle the style example I gave), and it results
in very weird results (very bad developer ergonomics) for cases like
1GB of text followed by caption vs 1GB of text followed by coption
(where the former loses the text and the latter does not).
BTW, This does not appear to be the case in webkit, gecko or IE8.
t = document.createElement('table');
neither of
t.innerHTML = 'foocaptionbar/caption'
t.innerHTML = 'foocoptionbar/coption
discard foo.
For me, both of these examples fall squarely in the I can live with
that bucket. I'll try again to persuade everyone that we not let
perfect be the enemy of good. =-)
--
Ian Hickson U+1047E )\._.,--,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Tue, 1 May 2012, Jonas Sicking wrote: However I think that's only a realistic option if the HTML editor is willing to add such a parser mode to the HTML spec. The HTML editor isn't a relevant concern here. If a spec editor won't get out of the way and spec what the implementors want to implement, the editor should be replaced with one who will. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On 05/01/2012 02:43 AM, Anne van Kesteren wrote: On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein rafa...@google.com wrote: There aren't any parser changes required. DocumentFragment.innerHTML can still provide the fragment case with a context element and procede normally. It's not obvious to me what bug to open against HTML. Anne, can we move forward with this? I personally think it would be better if HTML kept defining all entry points to the HTML parser. And at least conceptually this is a new insertion mode I think contrary to what you suggest in http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html as only insertion modes handle emitted tokens. And although I guess it does not matter here for now, given that the tree builder can change the behavior of the tokenizer decoupling them seems rather odd to me. I agree with Anne's point here; I'd rather not try to spec something more complex than invoking an algorithm in the HTML spec in DOMParsing. HTH Ms2ger
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Tue, May 1, 2012 at 3:29 AM, Ms2ger ms2...@gmail.com wrote: On 05/01/2012 02:43 AM, Anne van Kesteren wrote: On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein rafa...@google.com wrote: There aren't any parser changes required. DocumentFragment.innerHTML can still provide the fragment case with a context element and procede normally. It's not obvious to me what bug to open against HTML. Anne, can we move forward with this? I personally think it would be better if HTML kept defining all entry points to the HTML parser. And at least conceptually this is a new insertion mode I think contrary to what you suggest in http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html as only insertion modes handle emitted tokens. And although I guess it does not matter here for now, given that the tree builder can change the behavior of the tokenizer decoupling them seems rather odd to me. I agree with Anne's point here; I'd rather not try to spec something more complex than invoking an algorithm in the HTML spec in DOMParsing. I would also agree with that. However I think that's only a realistic option if the HTML editor is willing to add such a parser mode to the HTML spec. Otherwise I think we're left with the option that Rafael describes. / Jonas
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, Apr 26, 2012 at 1:33 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 26 Apr 2012 10:05:28 +0200, Ryosuke Niwa rn...@webkit.org wrote: Also, I think Anne convinced me that it's better to deduce the insertion mode from the first element than inventing a new insertion mode (I've asked him to post his reasoning). 1) You cannot look at various elements and make a decision. E.g. if your first element is plaintext there will not be any other elements. 2) Defining a new top-level insertion mode while retaining compatible behavior might be an interesting exercise in parser complexity, but it's not clear there is a benefit (use cases?) and feasibility has not been demonstrated (consider handling ptdp, trptd, ...). The more we can define in terms of the existing parser, the better it is for developers. The behavior will be more predictable and there will be less quirks to learn. FWIW, https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 is the bug on the I've updated this bug with the current proposal. DOM Parsing spec, I don't think there's a bug on the HTML spec (other than https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 for SVG/MathML), but I There aren't any parser changes required. DocumentFragment.innerHTML can still provide the fragment case with a context element and procede normally. It's not obvious to me what bug to open against HTML. Anne, can we move forward with this? Also, note that a webkit patch which implements implied context is here: https://bugs.webkit.org/show_bug.cgi?id=84646 might be mistaken. -- Anne van Kesteren http://annevankesteren.nl/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein rafa...@google.com wrote: There aren't any parser changes required. DocumentFragment.innerHTML can still provide the fragment case with a context element and procede normally. It's not obvious to me what bug to open against HTML. Anne, can we move forward with this? I personally think it would be better if HTML kept defining all entry points to the HTML parser. And at least conceptually this is a new insertion mode I think contrary to what you suggest in http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html as only insertion modes handle emitted tokens. And although I guess it does not matter here for now, given that the tree builder can change the behavior of the tokenizer decoupling them seems rather odd to me. The Any other * tagName design also seems somewhat fragile to me. I think those lists need to be explicit and coordinated. We should at least put some checks in place to make sure we are not introducing more overlapping element names in the future. Also, I looked briefly at the WebKit patch (which does not appear to address the hairy Any other * tagName issue), DOM4 is not responsible for innerHTML. http://html5.org/specs/dom-parsing.html is and is written by Ms2ger (in case the move forward in your question was about defining this in DOM4). -- Anne van Kesteren http://annevankesteren.nl/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Mon, Apr 30, 2012 at 5:43 PM, Anne van Kesteren ann...@opera.com wrote: I personally think it would be better if HTML kept defining all entry points to the HTML parser. And at least conceptually this is a new insertion mode I think contrary to what you suggest in http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html as only insertion modes handle emitted tokens. And although I guess it does not matter here for now, given that the tree builder can change the behavior of the tokenizer decoupling them seems rather odd to me. This is simply invoking the fragment parsing algorithm that's already defined in DOMParsing, but intelligently supplying a context element. There's no need to worry about emitting tokens or anything, except insofar as DOMParsing already has to worry about that. The Any other * tagName design also seems somewhat fragile to me. I think those lists need to be explicit and coordinated. We should at least put some checks in place to make sure we are not introducing more overlapping element names in the future. I'm fine with that, as long as implementations are okay with updating their lists of elements as the underlying languages (SVG and MathML) change. This *will* potentially cause a behavior difference, as elements that previously parsed as HTMLUnknownElement instead parse as some specific SVG or MathML element. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Mon, Apr 30, 2012 at 6:51 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 30, 2012 at 5:43 PM, Anne van Kesteren ann...@opera.com wrote: I personally think it would be better if HTML kept defining all entry points to the HTML parser. And at least conceptually this is a new insertion mode I think contrary to what you suggest in http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html as only insertion modes handle emitted tokens. And although I guess it does not matter here for now, given that the tree builder can change the behavior of the tokenizer decoupling them seems rather odd to me. This is simply invoking the fragment parsing algorithm that's already defined in DOMParsing, but intelligently supplying a context element. There's no need to worry about emitting tokens or anything, except insofar as DOMParsing already has to worry about that. I think Anne's concern is that in order to find the first start tag, the tokenizer must be used. In this case, the tokenizer would be used absent of a parser. I'm actually ok with that because the tokenizer is not a risk of changing states (it starts in the DATA state and stops searching on the first start tag, so for this use it can't change state), but I understand the conceptual novelty. We can put this in the parser spec, but I'm not yet convinced it deserves a new insertion mode. UA's may implement it that way, so as to avoid duplication of some tokenization work, but it seems cleaner to describe it as running the tokenizer to look ahead to the first start tag. The Any other * tagName design also seems somewhat fragile to me. I think those lists need to be explicit and coordinated. We should at least put some checks in place to make sure we are not introducing more overlapping element names in the future. I'm fine with that, as long as implementations are okay with updating their lists of elements as the underlying languages (SVG and MathML) change. This *will* potentially cause a behavior difference, as elements that previously parsed as HTMLUnknownElement instead parse as some specific SVG or MathML element. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Anne pointed out to me that Yehuda had already proposed a very similar change to the spec on November 4th, 2011: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 The only difference appears to be new proposal handles head, body, SVG, and MathML elements. Also, I think Anne convinced me that it's better to deduce the insertion mode from the first element than inventing a new insertion mode (I've asked him to post his reasoning). - Ryosuke On Wed, Apr 25, 2012 at 12:39 PM, Rafael Weinstein rafa...@google.comwrote: Ok, so from the thread that Yehuda started last year, There seem to be three issues: 1) Interop (e.g. WRT IE) 2) Defining the behavior for all elements 3) HTML vs SVG vs MathML I think what Yehuda outlined earlier is basically right, and I have a proposal which accomplishes everything he wants in a different way and also addresses the three concerns above. My approach here is to not let perfect be the enemy of good. DocumentFragment.innerHTML has the following behavior. It picks an *implied context element* based on the tagName of the first start tag token which appears in the html provided. It then operates per the fragment case of the spec, using the implied context element as the context element. Here's the approach for picking the implied context element: Let the first start tag token imply the context element. The start tag = implied context element is as follows: caption, colgroup, thead, tbody, tfoot = HTMLTableElement tr = HTMLTableBodyElement col = HTMLColGroupElement td, th = HTMLTableRowElement head, body = HTMLHTMLElement rp, rt = HTMLRubyElement Any other HTML tagName = HTMLBodyElement Any other SVG tagName = SVGElement Any other MathML tagName = MathElement Any other tagName = HTMLBodyElement Note a few things about this: *Because this is basically a pre-processing step to the existing fragment case, the changes to the parser spec are purely additive (no new insertion modes or other parser changes needed). *It addresses (1) by only adding new parsing behavior to new API (implicitly retaining compat) *It explains (2) *The only problem with (3) is the SVG style, script, a font tags. Here HTML wins and I think that's fine. This problem is inherent to the SVG 1.1 spec and we shouldn't let it wreak more havoc on HTML. *This doesn't attempt to do anything clever with sequences of markup that contain conflicting top-level nodes (e.g. df.innerHTML = 'tdFoo/tdg/g';). There's nothing clever to be done, and IMO, attempting to be clever is a mistake. Here's how some of the examples from the previous thread would be parsed. I've tested these by simply inspecting the output of innerHTML applied to the implied context element from the example. On Thu, Nov 10, 2011 at 3:43 AM, Henri Sivonen hsivo...@iki.fi wrote: What about SVG and MathML elements? I totally sympathize that this is a problem with tr, but developing a complete solution that works sensibly even when you do stuff like frag.innerHTML = head/head head body frag.innerHTML = headdiv/div/head head body div frag.innerHTML = frameset/frameseta!-- b -- a !-- b -- frag.innerHTML = htmlbodyfoo/htmlbartr/tr foobar frag.innerHTML = htmlbodyfoo/htmltr/tr foo frag.innerHTML = div/divtr/tr div frag.innerHTML = tr/trdiv/div tbody tr div frag.innerHTML = gpath//g g path [Note that innerHTML doesn't work presently on SVGElements in WebKit or Gecko, but this last example would result if it did] On Tue, Apr 24, 2012 at 5:26 AM, Rafael Weinstein rafa...@google.com wrote: No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com wrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein rafa...@google.com wrote: Here's the approach for picking the implied context element: Let the first start tag token imply the context element. The start tag = implied context element is as follows: caption, colgroup, thead, tbody, tfoot = HTMLTableElement tr = HTMLTableBodyElement col = HTMLColGroupElement td, th = HTMLTableRowElement head, body = HTMLHTMLElement rp, rt = HTMLRubyElement Any other HTML tagName = HTMLBodyElement Isn't this one redundant with the last step? Any other SVG tagName = SVGElement Any other MathML tagName = MathElement What are these two, exactly? The parser currently doesn't have a list of SVG/MathML tag names, and the SVG WG didn't like it when it was proposed to use a fixed list of SVG tag names for parsing SVG in text/html, IIRC. Also note that innerHTML on non-HTML elements currently always parses in the in body insertion mode. I'd like to see that fixed before we try to support foreign content in contextless innerHTML. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 Any other tagName = HTMLBodyElement -- Simon Pieters Opera Software
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, 26 Apr 2012 10:05:28 +0200, Ryosuke Niwa rn...@webkit.org wrote: Also, I think Anne convinced me that it's better to deduce the insertion mode from the first element than inventing a new insertion mode (I've asked him to post his reasoning). 1) You cannot look at various elements and make a decision. E.g. if your first element is plaintext there will not be any other elements. 2) Defining a new top-level insertion mode while retaining compatible behavior might be an interesting exercise in parser complexity, but it's not clear there is a benefit (use cases?) and feasibility has not been demonstrated (consider handling ptdp, trptd, ...). The more we can define in terms of the existing parser, the better it is for developers. The behavior will be more predictable and there will be less quirks to learn. FWIW, https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 is the bug on the DOM Parsing spec, I don't think there's a bug on the HTML spec (other than https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 for SVG/MathML), but I might be mistaken. -- Anne van Kesteren http://annevankesteren.nl/
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Thu, Apr 26, 2012 at 1:26 AM, Simon Pieters sim...@opera.com wrote: On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein rafa...@google.com wrote: Any other HTML tagName = HTMLBodyElement Isn't this one redundant with the last step? No, this captures known HTML tagnames, so that HTML can lay claim on the few tags that overlap with SVG. The last step just captures any remaining tags that fell through the cracks, so they can become HTMLUnknownElements. Any other SVG tagName = SVGElement Any other MathML tagName = MathElement What are these two, exactly? The parser currently doesn't have a list of SVG/MathML tag names, and the SVG WG didn't like it when it was proposed to use a fixed list of SVG tag names for parsing SVG in text/html, IIRC. We don't need a specific list in the spec, but each browser would need one, constructed from whatever elements they currently understand. (In my dreams, we just merge SVG into the HTML namespace, and then this step disappears.) Also note that innerHTML on non-HTML elements currently always parses in the in body insertion mode. I'd like to see that fixed before we try to support foreign content in contextless innerHTML. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 Yes, that needs to be fixed. As Ms2ger said yesterday in IRC, the DOMParsing spec already handles this appropriately, but HTML needs a a fix, since the former hooks into the latter. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Henri, Does this address the concerns you raised earlier? On Thu, Apr 26, 2012 at 10:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 26, 2012 at 1:26 AM, Simon Pieters sim...@opera.com wrote: On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein rafa...@google.com wrote: Any other HTML tagName = HTMLBodyElement Isn't this one redundant with the last step? No, this captures known HTML tagnames, so that HTML can lay claim on the few tags that overlap with SVG. The last step just captures any remaining tags that fell through the cracks, so they can become HTMLUnknownElements. Any other SVG tagName = SVGElement Any other MathML tagName = MathElement What are these two, exactly? The parser currently doesn't have a list of SVG/MathML tag names, and the SVG WG didn't like it when it was proposed to use a fixed list of SVG tag names for parsing SVG in text/html, IIRC. We don't need a specific list in the spec, but each browser would need one, constructed from whatever elements they currently understand. (In my dreams, we just merge SVG into the HTML namespace, and then this step disappears.) Also note that innerHTML on non-HTML elements currently always parses in the in body insertion mode. I'd like to see that fixed before we try to support foreign content in contextless innerHTML. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 Yes, that needs to be fixed. As Ms2ger said yesterday in IRC, the DOMParsing spec already handles this appropriately, but HTML needs a a fix, since the former hooks into the latter. ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
It does feel very sensible that regardless of templates this is a useful feature that we've long desired. On Apr 24, 2012 8:28 AM, Rafael Weinstein rafa...@google.com wrote: No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com wrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Right. I just want to make sure we agree on the exact feature set and behavior before WebKit implements it. On Wed, Apr 25, 2012 at 7:39 AM, Brian Kardell bkard...@gmail.com wrote: It does feel very sensible that regardless of templates this is a useful feature that we've long desired. On Apr 24, 2012 8:28 AM, Rafael Weinstein rafa...@google.com wrote: No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com wrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Ok, so from the thread that Yehuda started last year, There seem to be three issues: 1) Interop (e.g. WRT IE) 2) Defining the behavior for all elements 3) HTML vs SVG vs MathML I think what Yehuda outlined earlier is basically right, and I have a proposal which accomplishes everything he wants in a different way and also addresses the three concerns above. My approach here is to not let perfect be the enemy of good. DocumentFragment.innerHTML has the following behavior. It picks an *implied context element* based on the tagName of the first start tag token which appears in the html provided. It then operates per the fragment case of the spec, using the implied context element as the context element. Here's the approach for picking the implied context element: Let the first start tag token imply the context element. The start tag = implied context element is as follows: caption, colgroup, thead, tbody, tfoot = HTMLTableElement tr = HTMLTableBodyElement col = HTMLColGroupElement td, th = HTMLTableRowElement head, body = HTMLHTMLElement rp, rt = HTMLRubyElement Any other HTML tagName = HTMLBodyElement Any other SVG tagName = SVGElement Any other MathML tagName = MathElement Any other tagName = HTMLBodyElement Note a few things about this: *Because this is basically a pre-processing step to the existing fragment case, the changes to the parser spec are purely additive (no new insertion modes or other parser changes needed). *It addresses (1) by only adding new parsing behavior to new API (implicitly retaining compat) *It explains (2) *The only problem with (3) is the SVG style, script, a font tags. Here HTML wins and I think that's fine. This problem is inherent to the SVG 1.1 spec and we shouldn't let it wreak more havoc on HTML. *This doesn't attempt to do anything clever with sequences of markup that contain conflicting top-level nodes (e.g. df.innerHTML = 'tdFoo/tdg/g';). There's nothing clever to be done, and IMO, attempting to be clever is a mistake. Here's how some of the examples from the previous thread would be parsed. I've tested these by simply inspecting the output of innerHTML applied to the implied context element from the example. On Thu, Nov 10, 2011 at 3:43 AM, Henri Sivonen hsivo...@iki.fi wrote: What about SVG and MathML elements? I totally sympathize that this is a problem with tr, but developing a complete solution that works sensibly even when you do stuff like frag.innerHTML = head/head head body frag.innerHTML = headdiv/div/head head body div frag.innerHTML = frameset/frameseta!-- b -- a !-- b -- frag.innerHTML = htmlbodyfoo/htmlbartr/tr foobar frag.innerHTML = htmlbodyfoo/htmltr/tr foo frag.innerHTML = div/divtr/tr div frag.innerHTML = tr/trdiv/div tbody tr div frag.innerHTML = gpath//g g path [Note that innerHTML doesn't work presently on SVGElements in WebKit or Gecko, but this last example would result if it did] On Tue, Apr 24, 2012 at 5:26 AM, Rafael Weinstein rafa...@google.com wrote: No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com wrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
That would be a major leap forward in the least right? On Apr 25, 2012 3:41 PM, Rafael Weinstein rafa...@google.com wrote: Ok, so from the thread that Yehuda started last year, There seem to be three issues: 1) Interop (e.g. WRT IE) 2) Defining the behavior for all elements 3) HTML vs SVG vs MathML I think what Yehuda outlined earlier is basically right, and I have a proposal which accomplishes everything he wants in a different way and also addresses the three concerns above. My approach here is to not let perfect be the enemy of good. DocumentFragment.innerHTML has the following behavior. It picks an *implied context element* based on the tagName of the first start tag token which appears in the html provided. It then operates per the fragment case of the spec, using the implied context element as the context element. Here's the approach for picking the implied context element: Let the first start tag token imply the context element. The start tag = implied context element is as follows: caption, colgroup, thead, tbody, tfoot = HTMLTableElement tr = HTMLTableBodyElement col = HTMLColGroupElement td, th = HTMLTableRowElement head, body = HTMLHTMLElement rp, rt = HTMLRubyElement Any other HTML tagName = HTMLBodyElement Any other SVG tagName = SVGElement Any other MathML tagName = MathElement Any other tagName = HTMLBodyElement Note a few things about this: *Because this is basically a pre-processing step to the existing fragment case, the changes to the parser spec are purely additive (no new insertion modes or other parser changes needed). *It addresses (1) by only adding new parsing behavior to new API (implicitly retaining compat) *It explains (2) *The only problem with (3) is the SVG style, script, a font tags. Here HTML wins and I think that's fine. This problem is inherent to the SVG 1.1 spec and we shouldn't let it wreak more havoc on HTML. *This doesn't attempt to do anything clever with sequences of markup that contain conflicting top-level nodes (e.g. df.innerHTML = 'tdFoo/tdg/g';). There's nothing clever to be done, and IMO, attempting to be clever is a mistake. Here's how some of the examples from the previous thread would be parsed. I've tested these by simply inspecting the output of innerHTML applied to the implied context element from the example. On Thu, Nov 10, 2011 at 3:43 AM, Henri Sivonen hsivo...@iki.fi wrote: What about SVG and MathML elements? I totally sympathize that this is a problem with tr, but developing a complete solution that works sensibly even when you do stuff like frag.innerHTML = head/head head body frag.innerHTML = headdiv/div/head head body div frag.innerHTML = frameset/frameseta!-- b -- a !-- b -- frag.innerHTML = htmlbodyfoo/htmlbartr/tr foobar frag.innerHTML = htmlbodyfoo/htmltr/tr foo frag.innerHTML = div/divtr/tr div frag.innerHTML = tr/trdiv/div tbody tr div frag.innerHTML = gpath//g g path [Note that innerHTML doesn't work presently on SVGElements in WebKit or Gecko, but this last example would result if it did] On Tue, Apr 24, 2012 at 5:26 AM, Rafael Weinstein rafa...@google.com wrote: No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com wrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, Apr 25, 2012 at 12:39 PM, Rafael Weinstein rafa...@google.com wrote: Ok, so from the thread that Yehuda started last year, There seem to be three issues: 1) Interop (e.g. WRT IE) 2) Defining the behavior for all elements 3) HTML vs SVG vs MathML I think what Yehuda outlined earlier is basically right, and I have a proposal which accomplishes everything he wants in a different way and also addresses the three concerns above. My approach here is to not let perfect be the enemy of good. DocumentFragment.innerHTML has the following behavior. It picks an *implied context element* based on the tagName of the first start tag token which appears in the html provided. It then operates per the fragment case of the spec, using the implied context element as the context element. Here's the approach for picking the implied context element: Let the first start tag token imply the context element. The start tag = implied context element is as follows: caption, colgroup, thead, tbody, tfoot = HTMLTableElement tr = HTMLTableBodyElement col = HTMLColGroupElement td, th = HTMLTableRowElement head, body = HTMLHTMLElement rp, rt = HTMLRubyElement Any other HTML tagName = HTMLBodyElement Any other SVG tagName = SVGElement Any other MathML tagName = MathElement Any other tagName = HTMLBodyElement Note a few things about this: *Because this is basically a pre-processing step to the existing fragment case, the changes to the parser spec are purely additive (no new insertion modes or other parser changes needed). *It addresses (1) by only adding new parsing behavior to new API (implicitly retaining compat) *It explains (2) *The only problem with (3) is the SVG style, script, a font tags. Here HTML wins and I think that's fine. This problem is inherent to the SVG 1.1 spec and we shouldn't let it wreak more havoc on HTML. *This doesn't attempt to do anything clever with sequences of markup that contain conflicting top-level nodes (e.g. df.innerHTML = 'tdFoo/tdg/g';). There's nothing clever to be done, and IMO, attempting to be clever is a mistake. Here's how some of the examples from the previous thread would be parsed. I've tested these by simply inspecting the output of innerHTML applied to the implied context element from the example. On Thu, Nov 10, 2011 at 3:43 AM, Henri Sivonen hsivo...@iki.fi wrote: What about SVG and MathML elements? I totally sympathize that this is a problem with tr, but developing a complete solution that works sensibly even when you do stuff like frag.innerHTML = head/head head body frag.innerHTML = headdiv/div/head head body div frag.innerHTML = frameset/frameseta!-- b -- a !-- b -- frag.innerHTML = htmlbodyfoo/htmlbartr/tr foobar frag.innerHTML = htmlbodyfoo/htmltr/tr foo frag.innerHTML = div/divtr/tr div frag.innerHTML = tr/trdiv/div tbody tr div Sorry, this should have been just tr frag.innerHTML = gpath//g g path [Note that innerHTML doesn't work presently on SVGElements in WebKit or Gecko, but this last example would result if it did] On Tue, Apr 24, 2012 at 5:26 AM, Rafael Weinstein rafa...@google.com wrote: No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com wrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
My concern with the proposal is that it currently requires libraries to still do a regexp and special case frameset and html. We should imply the correct context for all tags in HTML5, not matter if we like them or not. I think it is important that any valid HTML with one top level node works and results in a firstChild that directly map to the input. On Wed, Apr 25, 2012 at 12:39, Rafael Weinstein rafa...@google.com wrote: frag.innerHTML = frameset/frameseta!-- b -- The context for this should be HTMLHtmlElement frameset !-- b -- a gets dropped because it not valid as a child of html frag.innerHTML = htmlbodyfoo/htmlbartr/tr root context html head body foobar frag.innerHTML = htmlbodyfoo/htmltr/tr html head body foo -- erik
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
I'm in favor of the proposal. It solves all of the cases I know about. For what it's worth, libraries do not, today, bother dealing with html and frameset. Here are the regular expressions jQuery uses in its cleaning process: https://github.com/jquery/jquery/blob/master/src/manipulation.js#L17-42 Yehuda Katz (ph) 718.877.1325 On Wed, Apr 25, 2012 at 1:51 PM, Erik Arvidsson a...@chromium.org wrote: My concern with the proposal is that it currently requires libraries to still do a regexp and special case frameset and html. We should imply the correct context for all tags in HTML5, not matter if we like them or not. I think it is important that any valid HTML with one top level node works and results in a firstChild that directly map to the input. On Wed, Apr 25, 2012 at 12:39, Rafael Weinstein rafa...@google.com wrote: frag.innerHTML = frameset/frameseta!-- b -- The context for this should be HTMLHtmlElement frameset !-- b -- a gets dropped because it not valid as a child of html frag.innerHTML = htmlbodyfoo/htmlbartr/tr root context html head body foobar frag.innerHTML = htmlbodyfoo/htmltr/tr html head body foo -- erik
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, Apr 25, 2012 at 4:55 PM, Yehuda Katz wyc...@gmail.com wrote: https://github.com/jquery/jquery/blob/master/src/manipulation.js#L17-42 For posterity: https://github.com/jquery/jquery/blob/247d824/src/manipulation.js#L17-42
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
I agree. Changing the context element based on the first element is strange and counter-intutitive and doesn't buy us anything. For example, enforcing the in table insertion mode when we encounter td as the first element doesn't guarantee into where this fragment is inserted. In fact, it can be inserted as an immediate child of a shadow root for the component model. - Ryosuke On Wed, Apr 25, 2012 at 1:51 PM, Erik Arvidsson a...@chromium.org wrote: My concern with the proposal is that it currently requires libraries to still do a regexp and special case frameset and html. We should imply the correct context for all tags in HTML5, not matter if we like them or not. I think it is important that any valid HTML with one top level node works and results in a firstChild that directly map to the input. On Wed, Apr 25, 2012 at 12:39, Rafael Weinstein rafa...@google.com wrote: frag.innerHTML = frameset/frameseta!-- b -- The context for this should be HTMLHtmlElement frameset !-- b -- a gets dropped because it not valid as a child of html frag.innerHTML = htmlbodyfoo/htmlbartr/tr root context html head body foobar frag.innerHTML = htmlbodyfoo/htmltr/tr html head body foo -- erik
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
jQuery seems to think it buys us something because we have implemented exactly that. Yehuda Katz (ph) 718.877.1325 On Wed, Apr 25, 2012 at 2:34 PM, Ryosuke Niwa rn...@webkit.org wrote: I agree. Changing the context element based on the first element is strange and counter-intutitive and doesn't buy us anything. For example, enforcing the in table insertion mode when we encounter td as the first element doesn't guarantee into where this fragment is inserted. In fact, it can be inserted as an immediate child of a shadow root for the component model. - Ryosuke On Wed, Apr 25, 2012 at 1:51 PM, Erik Arvidsson a...@chromium.org wrote: My concern with the proposal is that it currently requires libraries to still do a regexp and special case frameset and html. We should imply the correct context for all tags in HTML5, not matter if we like them or not. I think it is important that any valid HTML with one top level node works and results in a firstChild that directly map to the input. On Wed, Apr 25, 2012 at 12:39, Rafael Weinstein rafa...@google.com wrote: frag.innerHTML = frameset/frameseta!-- b -- The context for this should be HTMLHtmlElement frameset !-- b -- a gets dropped because it not valid as a child of html frag.innerHTML = htmlbodyfoo/htmlbartr/tr root context html head body foobar frag.innerHTML = htmlbodyfoo/htmltr/tr html head body foo -- erik
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, Apr 25, 2012 at 3:05 PM, Yehuda Katz wyc...@gmail.com wrote: jQuery seems to think it buys us something because we have implemented exactly that. Do you know why jQuery does it that way? - Ryosuke
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
On Wed, Apr 25, 2012 at 2:34 PM, Ryosuke Niwa rn...@webkit.org wrote: I agree. Changing the context element based on the first element is strange and counter-intutitive and doesn't buy us anything. For example, enforcing the in table insertion mode when we encounter td as the first element doesn't guarantee into where this fragment is inserted. In fact, it can be inserted as an immediate child of a shadow root for the component model. If you have a fragment that starts with a td, you'd better be planning on eventually putting it as the child of a tr. (Or as the shadow children of a Component that is acting like a tr.) If you want to do something else... um, why? What possible use-case might there be for parsing a string starting with td aside from later putting it inside a tr? ~TJ
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
No, I hadn't. Let me digest this thread. Much of what I'm implicitly asking has already been discussed. I'll repost if I have anything to add here. Apologies for the noise. On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com wrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML
Have you looked at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ? On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.comwrote: The main points of contention in the discussion about the template element are 1) By what mechanism are its content elements 'inert' 2) Do template contents reside in the document, or outside of it What doesn't appear to be controversial is the parser changes which would allow the template element to have arbitrary top-level content elements. I'd like to propose that we add DocumentFragment.innerHTML which parses markup into elements without a context element. This has come up in the past, and is in itself a useful feature. The problem it solves is allowing templating systems to create DOM from markup without having to sniff the content and only innerHTML on an appropriate parent element (Yehuda can speak more to this). The parser changes required for this are a subset of the changes that Dimitri uncovered here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html And I've uploaded a webkit patch which implements them here: https://bugs.webkit.org/show_bug.cgi?id=84646 I'm hoping this is a sensible way to make progress. Thoughts?
