Re: [webcomponents] HTML Parsing and the template element
I think I'm not understanding the implications of your argument. You're making a principled argument about future pitfalls. Can you help me get my head around it by way of example? Perhaps: -pitfalls developers fall into -further dangerous points along the slippery slope you think this opens up (you mentioned pandoras box) On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal child elements in the DOM. I do object if template has a null firstChild and the new property that leads to a fragment that belongs to a different owner document. (My non-objection to creating normal children in the DOM should not be read as a commitment to support templates Gecko.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. On Tue, Jun 26, 2012 at 8:25 AM, Rafael Weinstein rafa...@google.comwrote: I think I'm not understanding the implications of your argument. You're making a principled argument about future pitfalls. Can you help me get my head around it by way of example? Perhaps: -pitfalls developers fall into -further dangerous points along the slippery slope you think this opens up (you mentioned pandoras box) On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal child elements in the DOM. I do object if template has a null firstChild and the new property that leads to a fragment that belongs to a different owner document. (My non-objection to creating normal children in the DOM should not be read as a commitment to support templates Gecko.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn espr...@gmail.com wrote: Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. Because you can't nest textarea inside of itself, but we want templates to be nestable. ~TJ
Re: [webcomponents] HTML Parsing and the template element
Hmm, I might be in agreement with Henri then. Having all these parallel trees in the DOM is getting kind of out of control. Now there's the shadow DOM trees on every node, and also this nested tree of document fragments from template. There's a lot of simplicity in the DOM design that's lost from these two changes. On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn espr...@gmail.com wrote: Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. Because you can't nest textarea inside of itself, but we want templates to be nestable. ~TJ
Re: [webcomponents] HTML Parsing and the template element
(Please bottompost! Being a Googler teaches you bad email habits. ^_^) On Tue, Jun 26, 2012 at 1:34 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn espr...@gmail.com wrote: Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. Because you can't nest textarea inside of itself, but we want templates to be nestable. Hmm, I might be in agreement with Henri then. Having all these parallel trees in the DOM is getting kind of out of control. Now there's the shadow DOM trees on every node, and also this nested tree of document fragments from template. There's a lot of simplicity in the DOM design that's lost from these two changes. The problem is that this is a very theoretical opinion. In reality, these parallel trees *already exist*, except they're not DOM, they're bespoke JS trees that don't interoperate between libraries and have a decent impedance mismatch with the real DOM APIs, resulting in significant duplication. Let's get rid of these parallel trees isn't an option. Our choices are only maintain the status quo of multiple layers of DOM incompatibly stacked on top of each other or complicate DOM a bit to pull those trees into the fold. ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal child elements in the DOM. If we go this route how does template iterate work when the array is empty? Could you give some detail on what you'd like the behavior to be for iterate over [], [oneThing] and [oneThing, twoThings] ? - E
Re: [webcomponents] HTML Parsing and the template element
On Thu, Jun 14, 2012 at 10:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't have a good handle on how much commitment there is from non-Chrome parties here. I don't want to add this to the spec only to find that people think it's a good idea but only one vendor has plans to implement it. We have no urgent plans to work on this. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [webcomponents] HTML Parsing and the template element
On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal child elements in the DOM. I do object if template has a null firstChild and the new property that leads to a fragment that belongs to a different owner document. (My non-objection to creating normal children in the DOM should not be read as a commitment to support templates Gecko.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Tue, Jun 12, 2012 at 12:14 AM, Rafael Weinstein rafa...@google.com wrote: On Mon, Jun 11, 2012 at 3:13 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Just saying that querySelector/All doesn't match elements in a template (unless the scope is inside the template already) would work, but it means that we have to make sure that all future similar APIs also pay attention to this. I think that would be preferable compared to opening the Pandora's box of breaking the correspondence between the markup of the DOM tree. Besides, we'd need something like this for the XML case anyway if the position the spec takes is that it shies away from changing the correspondence between XML source and the DOM. In general, I think the willingness to break the correspondence between the source and the DOM should be the same for both HTML and XML serializations. If you believe that it's not legitimate to break the correspondence between XML source and the DOM, it would be logical to treat radical changes to the correspondence between HTML source and the DOM as equally suspect. I think looking at this as whether we are breaking the correspondance between source and DOM may not be helpful -- because it's likely to be a matter of opinion. Arguments that correspondence between the source and the DOM are a matter of opinion in the HTML case is the sort of slippery slope I'm worried about. After all, in theory, we could make the parsing algorithm output whatever data structure. If we make an exception here, I expect that we'll see more proposals that will involve the parser generating non-traditional DOM structures in order to accommodate supposed API benefits at the expense of the old DOM-assuming stuff working generically. In the XML case, the correspondence between the source and the DOM is not a matter of opinion. At least not at present. It seems that the template spec is not willing to change that. Why? Why doesn't the same answer apply to HTML? I think we shouldn't violate the DOM Consistency Design Principle and make templates have wormholes to another document when parsed from text/html but have normal children when parsed from application/xhtml+xml. That sort of route will lead to having to implement template inertness twice and one of the solutions will be one that's supposedly being avoided by the proposed design for HTML. There are several axes of presence for elements WRT to a Document: -serialization: do the elements appear in the serialization of the Document, as delivered to the client and if the client re-serializes via innerHTML, etc... -DOM traversal: do the elements appear via traversing the document's childNodes hierarchy -querySelector*, get*by*, etc: are the element's returned via various document-level query mechanisms -CSS: are the element's considered for matching any present or future document-level selectors I'm arguing that these axes should be coupled the way they are now and have always been. (And if you want them decoupled, the decoupling should be done e.g. using selectors that specifically prohibit templates in the parent chain of the selected node or using APIs that aren't low-level tree accessors like firstChild, childNodes and getElementById().) For better or worse, the DOM is a data structure that represents the markup and then has some higher-level-feature sugaring. It's not a data structure whose shape is dictated by the higher-level features. The DOM is so fundamental to the platform that I think the bar for changing its nature should be very high. Certainly higher than one vendor wishing to proceed with the feature that they've come up with. Certainly not for a feature that could be implemented without breaking the traditional model with relative ease (making inertness check walk the parent chain [or propagate an equivalent flag down for O(1) read] and rooting selector queries differently or using *:not(template)). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Mon, 4 Jun 2012, Ian Hickson wrote: On Wed, 4 Apr 2012, Rafael Weinstein wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? I think it's more or less ok [...] Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't have a good handle on how much commitment there is from non-Chrome parties here. I don't want to add this to the spec only to find that people think it's a good idea but only one vendor has plans to implement it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] HTML Parsing and the template element
On Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Just saying that querySelector/All doesn't match elements in a template (unless the scope is inside the template already) would work, but it means that we have to make sure that all future similar APIs also pay attention to this. I think that would be preferable compared to opening the Pandora's box of breaking the correspondence between the markup of the DOM tree. Besides, we'd need something like this for the XML case anyway if the position the spec takes is that it shies away from changing the correspondence between XML source and the DOM. In general, I think the willingness to break the correspondence between the source and the DOM should be the same for both HTML and XML serializations. If you believe that it's not legitimate to break the correspondence between XML source and the DOM, it would be logical to treat radical changes to the correspondence between HTML source and the DOM as equally suspect. I worry that if we take the position here that it's okay to change your correspondence between the source and the DOM in order to optimize for a real or perceived need, it will open the floodgates for all sorts of arguments that we can make the parser generate whatever data structures regardless of what the input looks like and we'll end up in a world of pain. It's bad enough that isindex is a parser macro. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Mon, Jun 11, 2012 at 3:13 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Just saying that querySelector/All doesn't match elements in a template (unless the scope is inside the template already) would work, but it means that we have to make sure that all future similar APIs also pay attention to this. I think that would be preferable compared to opening the Pandora's box of breaking the correspondence between the markup of the DOM tree. Besides, we'd need something like this for the XML case anyway if the position the spec takes is that it shies away from changing the correspondence between XML source and the DOM. In general, I think the willingness to break the correspondence between the source and the DOM should be the same for both HTML and XML serializations. If you believe that it's not legitimate to break the correspondence between XML source and the DOM, it would be logical to treat radical changes to the correspondence between HTML source and the DOM as equally suspect. I think looking at this as whether we are breaking the correspondance between source and DOM may not be helpful -- because it's likely to be a matter of opinion. I'd like to suggest that we look at more precise issues. There are several axes of presence for elements WRT to a Document: -serialization: do the elements appear in the serialization of the Document, as delivered to the client and if the client re-serializes via innerHTML, etc... -DOM traversal: do the elements appear via traversing the document's childNodes hierarchy -querySelector*, get*by*, etc: are the element's returned via various document-level query mechanisms -CSS: are the element's considered for matching any present or future document-level selectors The goal of the template element is this: the page author would like a declarative mechanism to author DOM fragments which are not in use as of page construction, but are readily available to be used when needed. Further, the author would like to be able to declare the fragments inline, at the location in the document where they should be placed, if when they are needed. Thus, template require that its contents be present for only serialization, and not for DOM traversal, querySelector*/etc..., or CSS. Also, it may be helpful to think about this in terms of classical object systems. Currently we only have instances. What we need is a classes. Native app windowing systems don't force you to create an instance of every window or dialog that your app may ever need and place it off screen until it's needed. They allow for the notion of declaring what the window or dialog will be and delay creating any UI resources (HWNDs, buttons, drag targets, etc..) until the app creates an instance. I worry that if we take the position here that it's okay to change your correspondence between the source and the DOM in order to optimize for a real or perceived need, it will open the floodgates for all sorts of arguments that we can make the parser generate whatever data structures regardless of what the input looks like and we'll end up in a world of pain. It's bad enough that isindex is a parser macro. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
* Rafael Weinstein wrote: I think looking at this as whether we are breaking the correspondance between source and DOM may not be helpful -- because it's likely to be a matter of opinion. I'd like to suggest that we look at more precise issues. There are several axes of presence for elements WRT to a Document: -serialization: do the elements appear in the serialization of the Document, as delivered to the client and if the client re-serializes via innerHTML, etc... -DOM traversal: do the elements appear via traversing the document's childNodes hierarchy -querySelector*, get*by*, etc: are the element's returned via various document-level query mechanisms -CSS: are the element's considered for matching any present or future document-level selectors And one might take the position that all of these should be defined in terms of what you call DOM traversal, making them all the same, with- in the confines of a DOM View, a concept that has fallen out of favour. The goal of the template element is this: the page author would like a declarative mechanism to author DOM fragments which are not in use as of page construction, but are readily available to be used when needed. Further, the author would like to be able to declare the fragments inline, at the location in the document where they should be placed, if when they are needed. Thus, template require that its contents be present for only serialization, and not for DOM traversal, querySelector*/etc..., or CSS. I do not see the thus here. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [webcomponents] HTML Parsing and the template element
On Thu, Jun 7, 2012 at 2:45 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Wed, Jun 6, 2012 at 7:13 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
A call like document.querySelectorAll('p') doesn't *want* to get the
p inside the template.
I think it's backwards to assume that querySelectorAll() works a
particular way and that's that's not what authors want and to change
the DOM in response.
You could make this argument about any assumption anyone makes anywhere
which in any way adds features.
template is a pretty fundamentally different use of the DOM from existing
practices and it seems like violations of existing rules are likely.
That said, is a best practice here to put template in the head if web
developers are inclined to inline the template declaration? At least then
you can rely on document.body.querySelectorAll(). That seems like the
cleanest approach from a developer's perspective and is consistent with
practices like putting embedded CSS in the head.
Alec
There are various solutions that don't involve drastic changes to the
correspondence between the markup and the DOM, for example:
* Invoking querySelectorAll() on a wrapper element that's known not to
be a parent of the templates on the page.
* Using a selector that fails to match elements whose ancestor chain
contains a template element.
* Introducing an API querySelectorNonTemplate(). (Don't say All if
you don't mean *all*).
Even though XML has fallen out of favor, I think violations of the DOM
Consistency principle and features that don't work with the XHTML
serialization should be considered huge red flags indicating faulty
design.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Wed, Jun 6, 2012 at 7:13 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
A call like document.querySelectorAll('p') doesn't *want* to get the
p inside the template.
I think it's backwards to assume that querySelectorAll() works a
particular way and that's that's not what authors want and to change
the DOM in response.
There are various solutions that don't involve drastic changes to the
correspondence between the markup and the DOM, for example:
* Invoking querySelectorAll() on a wrapper element that's known not to
be a parent of the templates on the page.
* Using a selector that fails to match elements whose ancestor chain
contains a template element.
* Introducing an API querySelectorNonTemplate(). (Don't say All if
you don't mean *all*).
Even though XML has fallen out of favor, I think violations of the DOM
Consistency principle and features that don't work with the XHTML
serialization should be considered huge red flags indicating faulty
design.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Thu, Jun 7, 2012 at 2:45 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Wed, Jun 6, 2012 at 7:13 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
A call like document.querySelectorAll('p') doesn't *want* to get the
p inside the template.
I think it's backwards to assume that querySelectorAll() works a
particular way and that's that's not what authors want and to change
the DOM in response.
There are various solutions that don't involve drastic changes to the
correspondence between the markup and the DOM, for example:
* Invoking querySelectorAll() on a wrapper element that's known not to
be a parent of the templates on the page.
* Using a selector that fails to match elements whose ancestor chain
contains a template element.
* Introducing an API querySelectorNonTemplate(). (Don't say All if
you don't mean *all*).
I gave all of these alternatives in the email you replied to. ^_^
Adding new API is a non-starter (it won't get used, and I think the
common case is non-template), and I already argued that expecting
authors to always get the scope right is similarly a non-starter.
Just saying that querySelector/All doesn't match elements in a
template (unless the scope is inside the template already) would work,
but it means that we have to make sure that all future similar APIs
also pay attention to this.
Pulling them out of the DOM ensures that we don't have to think about
this stuff in the future, and so can't mess it up accidentally.
~TJ
Re: [webcomponents] HTML Parsing and the template element
On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 4 Apr 2012, Rafael Weinstein wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? I think it's more or less ok, but it has the problem that it doesn't give a way to reset the insertion mode again while inside a template. I still think that breaking the old correspondence between markup and the DOM and shrugging the XML side off is a big mistake. Why would it be substantially harder to check inertness by walking the parent chain (which normally won't be excessively long) as opposed to checking a flag on the owner document? I strongly believe that this template contents should be children of the template element in the DOM instead of being behind a special wormhole to another document while parsing and serializing as if the special wormhole wasn't there. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Wed, Jun 6, 2012 at 3:50 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 4 Apr 2012, Rafael Weinstein wrote:
On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Perhaps lost among other updates was the fact that I've gotten the
first draft of HTML Templates spec out:
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
I think the task previously was to show how dramatic the changes to the
parser would need to be. Talking to Dimitri, it sounds to me like they
turned out to be less open-heart-surgery and more quick outpatient
procedure. Adam, Hixie, Henri, how do you guys feel about the
invasiveness of the parser changes that Dimitri has turned out here?
I think it's more or less ok, but it has the problem that it doesn't give
a way to reset the insertion mode again while inside a template.
I still think that breaking the old correspondence between markup and
the DOM and shrugging the XML side off is a big mistake. Why would it
be substantially harder to check inertness by walking the parent chain
(which normally won't be excessively long) as opposed to checking a
flag on the owner document?
I strongly believe that this template contents should be children of
the template element in the DOM instead of being behind a special
wormhole to another document while parsing and serializing as if the
special wormhole wasn't there.
This has pretty bad usability pitfalls.
A template like this:
template
pStamp out copies of me!/p
/template
...is morally equivalent to this:
script type=text/template
pStamp out copies of me!/p
/script
Which is to say, neither of them actually represent page content.
They represent templates of such, which will be used to produce
actual page content.
A call like document.querySelectorAll('p') doesn't *want* to get the
p inside the template. It'll be doing processing on paragraphs in
the page, real paragraph filled with content. Similarly with class
selectors, or other things of similar nature. An id selector probably
*does* want to grab the template element, but using ids inside of a
template is a bad idea anyway, since it will produce multiple elements
with the same id.
The only way to avoid this kind of matching is either to only link in
templates externally, expect all authors to qualify their selectors
sufficiently to never include a template element, or somehow hide the
contents from selectors applied to the main document.
I think the first is bad, I doubt anyone would reasonably think the
second would happen, and so the third is necessary. I think the
current plan (to stash the contents of a template into a document
fragment) is a decent way to accomplish this. Another alternative is
to simply state that they don't match selectors with a scope rooted
higher than their template.
~TJ
Re: [webcomponents] HTML Parsing and the template element
On Wed, 4 Apr 2012, Rafael Weinstein wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? I think it's more or less ok, but it has the problem that it doesn't give a way to reset the insertion mode again while inside a template. Consider the difference in how these would parse: template tbody /tbodytr /template template tbody /tbody template /template tr /template We need a way to stay in the 'in table' mode. We could do this by having the parser insert a fake node into the stack of open elements just for this purpose, I think. That is, when switching insertion mode in response to the first start tag inside the template insertion mode, also insert something into the stack so that the next time we reset, we reset correctly. We need to do that in a way that doesn't match end tags, though... Maybe we have to introduce a new kind of thing we push on the stack, which doesn't get matched by anything but the reset algorithm? The proposal here doesn't support SVG (or MathML, but SVG seems more important for template). Short of hard-coding a list of SVG elements, which seems really bad for forwards compatibility, I don't have a good proposal for dealing with this. I suppose we could go back to having an attribute on template, this time setting the context at a more coarse level of just HTML vs SVG vs MathML; that's more likely to be understood by authors than what I was suggesting before (in table body, etc). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] HTML Parsing and the template element
On Mon, Jun 4, 2012 at 2:42 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 4 Apr 2012, Rafael Weinstein wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? I think it's more or less ok, but it has the problem that it doesn't give a way to reset the insertion mode again while inside a template. Consider the difference in how these would parse: template tbody /tbody tr /template template tbody /tbody template /template tr /template We need a way to stay in the 'in table' mode. We could do this by having the parser insert a fake node into the stack of open elements just for this purpose, I think. That is, when switching insertion mode in response to the first start tag inside the template insertion mode, also insert something into the stack so that the next time we reset, we reset correctly. We need to do that in a way that doesn't match end tags, though... Maybe we have to introduce a new kind of thing we push on the stack, which doesn't get matched by anything but the reset algorithm? A template context? Sets the context for the rest of parsing, and gets popped by a /template returning to its matching template. The proposal here doesn't support SVG (or MathML, but SVG seems more important for template). Short of hard-coding a list of SVG elements, which seems really bad for forwards compatibility, I don't have a good proposal for dealing with this. I suppose we could go back to having an attribute on template, this time setting the context at a more coarse level of just HTML vs SVG vs MathML; that's more likely to be understood by authors than what I was suggesting before (in table body, etc). It doesn't require any more hard-coding than HTML needs in order to create proper elements instead of HTMLUnknownElements. You have to know the list of valid HTML elements to produce a proper DOM, and update that as you add more, even if the rest of parser is unchanged. This is the same thing, except it needs the list of valid SVG and MathML elements. ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Mon, 4 Jun 2012, Tab Atkins Jr. wrote: [...] We could do this by having the parser insert a fake node into the stack of open elements just for this purpose, I think. That is, when switching insertion mode in response to the first start tag inside the template insertion mode, also insert something into the stack so that the next time we reset, we reset correctly. We need to do that in a way that doesn't match end tags, though... Maybe we have to introduce a new kind of thing we push on the stack, which doesn't get matched by anything but the reset algorithm? A template context? Sets the context for the rest of parsing, and gets popped by a /template returning to its matching template. Yeah, something like that could work. We'd have to make sure we defined it as happening when /template was popped, but if we force that to only ever happen when we see a literal /template (which the proposal seems to, though I haven't verified that) that might work ok. The proposal here doesn't support SVG (or MathML, but SVG seems more important for template). Short of hard-coding a list of SVG elements, which seems really bad for forwards compatibility, I don't have a good proposal for dealing with this. I suppose we could go back to having an attribute on template, this time setting the context at a more coarse level of just HTML vs SVG vs MathML; that's more likely to be understood by authors than what I was suggesting before (in table body, etc). It doesn't require any more hard-coding than HTML needs in order to create proper elements instead of HTMLUnknownElements. You have to know the list of valid HTML elements to produce a proper DOM, and update that as you add more, even if the rest of parser is unchanged. This is the same thing, except it needs the list of valid SVG and MathML elements. I agree that it's the same. I don't think having a hard-coded list of HTML elements is a good thing either, it's got the same forward-compatibility problems. Unfortunately in the case of the existing lists we had no choice because UAs already had them. Here, we have a choice. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] HTML Parsing and the template element
On Mon, Jun 4, 2012 at 3:50 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 4 Jun 2012, Tab Atkins Jr. wrote: [...] We could do this by having the parser insert a fake node into the stack of open elements just for this purpose, I think. That is, when switching insertion mode in response to the first start tag inside the template insertion mode, also insert something into the stack so that the next time we reset, we reset correctly. We need to do that in a way that doesn't match end tags, though... Maybe we have to introduce a new kind of thing we push on the stack, which doesn't get matched by anything but the reset algorithm? A template context? Sets the context for the rest of parsing, and gets popped by a /template returning to its matching template. Yeah, something like that could work. We'd have to make sure we defined it as happening when /template was popped, but if we force that to only ever happen when we see a literal /template (which the proposal seems to, though I haven't verified that) that might work ok. So the most straight-forward way I saw to approach this (implemented here: https://bugs.webkit.org/show_bug.cgi?id=86031) was to make the context element become a stack of context elements. The idea is that each level of nested template opens a new fragment parsing context, with a coinciding context element which is initially unknown. E.g. from you example above: template tbody /tbody template /template tr /template -When the first template element is encountered, the parser switches into ImpliedContext insertion mode and pushes an unknown element on the stack of context elements which is associated with the current template element -When the tbody is encountered, it replaces the unknown element with a table context element -When the inner template is encountered, it pushes another unknown context element onto the stack of context elements -When the inner /template is encountered, the template is popped from the stack of open elements and the unknown element is popped from the stack of context elements. The reset insertion mode appropriately algorithm is run -- which now examines the current context element (associated with the first template which is the current element) which is table and sets the insertion mode to InTable. The proposal here doesn't support SVG (or MathML, but SVG seems more important for template). Short of hard-coding a list of SVG elements, which seems really bad for forwards compatibility, I don't have a good proposal for dealing with this. I suppose we could go back to having an attribute on template, this time setting the context at a more coarse level of just HTML vs SVG vs MathML; that's more likely to be understood by authors than what I was suggesting before (in table body, etc). It doesn't require any more hard-coding than HTML needs in order to create proper elements instead of HTMLUnknownElements. You have to know the list of valid HTML elements to produce a proper DOM, and update that as you add more, even if the rest of parser is unchanged. This is the same thing, except it needs the list of valid SVG and MathML elements. I agree that it's the same. I don't think having a hard-coded list of HTML elements is a good thing either, it's got the same forward-compatibility problems. Unfortunately in the case of the existing lists we had no choice because UAs already had them. Here, we have a choice. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webcomponents] HTML Parsing and the template element
What Tab said. On Tue, Apr 24, 2012 at 5:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. If iteration uses a different tagname than normal templating (say, iterate), thus avoiding the nesting template in template problem, you still have the problem of nesting iteration, which is *also* a common ability for template systems. Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. Might as well do that early so you can immediately delve into it with DOM methods and whatnot, rather than delaying it and keeping it as flat text until the point of use. ~TJ
Re: [webcomponents] HTML Parsing and the template element
I totally misread the purpose of templates beforehand -- template/s act more like a mixin rather than a fill-in. It also reflects in what Tab wrote that it's still vague how the two notions - that of text templates and that of mixins for building components - are to be mixed together, if at all. Re the use as mixins - template/s put together two different ideas. On on hand, it looks like a content-generating/replicating scheme, such as a CSS content:, or the proprietary CSS -moz-element:[3] properties. In that sense, template/ seems to take these a step further. From the spec[1]: One reason for creating a document fragment is to clone it multiple times to create repeating items that vary in some content, but have common basic structure of across all instances. I see the content as being the DOM, and the common basic structure as the functional *design* around it. If repeated data was to be a semantic part of content, I would imagine it would have been incorporated in the tree. On the other hand, it seems template/s are trying to answer the same need as XML: giving an alternative for semantic structuring of the document without loosing the ability to add functionality. Again from the spec: something that allows developers declare arbitrary DOM subtrees *in* the document markup. I realized as I'm writing this that template/s come from XBL so I shouldn't be surprised. So I think these points still need some thought: - should functional design detail be embedded in the document? It looks like this might be subset of HTML targeting solely user-interactive web-apps. If it is, it should either be left to another mechanism to solve than the DOM, or we might encourage attaching these template/s as external files (there is no mention of a template src=/ attribute) - existing techniques have DOM fragments hidden with style=display:none; and then replicating them programmatically. What benefits do template/s present? That the fragment is inert, and the declarative nature of insert points and such. If these are the advantages, then we can add an inert= or template= attribute that any div/. Enriching HTML with useful elements is good, but creating a new subset for the purpose of inert content and insert points brings a lot of logic to the browser-side. I think HTML 5 is more about being simple and direct. - how does this answer the need to separate functional design/layout from semantic structure? This seems to replace techniques the such as XML+XSLT or XBL to render content as you wish. From the XBL spec [2]: XSLT operates on a static DOM, permanently replacing that DOM for rendering. XBL, on the other hand, transparently transforms the DOM for rendering while leaving the underlying structure intact, and dynamically reflects changes to the underlying DOM in the transformed rendering. In light of what I wrote about, why should this functionality be replicated to the HTML realm (as the specs say) and not used by it? The specs are missing this motivation. XBL may be used alongside CSS and scripts, instead of merging them inside HTML. Since I'm joining this discussion after a lot of specs have been written I might be missing some key points, but if for nothing else - then let these be for the sake of pointing these questions out and answering them more clearly in the specs for the sake of future developers. Yuval [1]: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html [2]: http://dev.w3.org/2006/xbl2/ [3]: https://developer.mozilla.org/en/CSS/-moz-element On Thu, Apr 26, 2012 at 3:15 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Apr 25, 2012 at 4:33 PM, Brian Kardell bkard...@gmail.com wrote: Tab, are you saying: a) fixing that in script apis for document fragment or something is an ok solution to this, or that b) this means text templates should use template or c) it should be the goal to kill string templates altogether? I just talked with Ojan in person, because we were talking past each other with the terms we were using. I now understand what he was saying! When we say string-based templating, we're really saying I want to embed an arbitrary foreign language into HTML. That language happens to be a templating language, but the exact purpose you're putting it to is irrelevant for our purposes here. For this, script type=foo is not only a satisfactory existing solution to this, but it's the *correct* solution to this - that's precisely what script is designed to do. I was confusing this term with the idea of programmatic DOM creation that doesn't suck. Right now, the right way to create a fragment of HTML is to use a lot of document.createElement() and el.appendChild(). This sucks. Instead, everyone wants to just write a string containing HTML and parse it, like what innerHTML and jQuery do. For this, Raf's proposal works great - it lets you use the innerHTML API without having to employ hacks like jQuery uses to ensure
Re: [webcomponents] HTML Parsing and the template element
On Thu, Apr 26, 2012 at 9:43 AM, Yuval Sadan sadan.yu...@gmail.com wrote:
I totally misread the purpose of templates beforehand -- template/s act
more like a mixin rather than a fill-in. It also reflects in what Tab wrote
that it's still vague how the two notions - that of text templates and that
of mixins for building components - are to be mixed together, if at all.
Maybe. I'm not interested in trying to cut through more terminology
at this point, particularly when its subtly different from what I know
of mixins from class-based languages and mixins from SASS. I
explained the goals in my previous email; that should be clear enough,
and you can chop it up into terms you're familiar with on your own.
Re the use as mixins - template/s put together two different ideas.
On on hand, it looks like a content-generating/replicating scheme, such as a
CSS content:, or the proprietary CSS -moz-element:[3] properties. In that
sense, template/ seems to take these a step further. From the spec[1]:
(Tangential note: -moz-element() was a proprietary experiment, but
it's since been specced. I've punted it from Image Values level 3 to
level 4, as it had some problems that would have delayed the level 3
snapshot unduly, but it's still there.)
Less tangential note: the use of 'content' is seductive - it *seems*
right and natural, but it has a lot of failings. Most particularly,
it's not well-defined (because the behavior normally isn't observable)
exactly when a CSS property stops matching. In particular, if an
element switches an attribute from foo='bar' to foo='baz', and
there were rules for both [foo=bar] and [foo=baz] applying the same
'content' rule, did it stop matching sometime in between? Or was it
continuously maintained? Both interpretations are sensible. With
Components, and the fact that they can have side-effects, you can tell
the difference between these two, and they have substantially
different implications for how you need to design Components. So, we
rejected the use of 'content' (or the similar 'binding' from XBL)
early on, for these reasons. Shadow DOM shouldn't be attachable
through CSS, at least not without significant restrictions that remove
the problems I noted.
One reason for creating a document fragment is to clone it multiple times
to create repeating items that vary in some content, but have common basic
structure of across all instances.
I see the content as being the DOM, and the common basic structure as the
functional *design* around it. If repeated data was to be a semantic part of
content, I would imagine it would have been incorporated in the tree.
On the other hand, it seems template/s are trying to answer the same need
as XML: giving an alternative for semantic structuring of the document
without loosing the ability to add functionality. Again from the spec:
something that allows developers declare arbitrary DOM subtrees in the
document markup.
I realized as I'm writing this that template/s come from XBL so I
shouldn't be surprised.
So I think these points still need some thought:
- should functional design detail be embedded in the document? It looks like
this might be subset of HTML targeting solely user-interactive web-apps. If
it is, it should either be left to another mechanism to solve than the DOM,
or we might encourage attaching these template/s as external files (there
is no mention of a template src=/ attribute)
Why *not* use DOM? We're trying to create a template for producing
DOM, and it seems we should self-host if possible, as it means we
won't have to reinvent a lot of API surface. There's a point when
this becomes untenable (for example, XSLT is far past that point), but
the plans for now don't seem to ambitious.
Loading templates from a remote document is on the menu eventually,
but it's not necessary to solve right now.
- existing techniques have DOM fragments hidden with style=display:none;
and then replicating them programmatically. What benefits do template/s
present? That the fragment is inert, and the declarative nature of insert
points and such. If these are the advantages, then we can add an inert= or
template= attribute that any div/. Enriching HTML with useful elements
is good, but creating a new subset for the purpose of inert content and
insert points brings a lot of logic to the browser-side. I think HTML 5 is
more about being simple and direct.
That's not enough. In addition to the inertness, there are parsing
implications. We'd like, for example, for a Component to substitute
for a tr. To do so, its contents should be tds. If you just put
a td in your document, though, outside of the table context it
expects, the tag gets thrown away (the contents stay behind). Like I
pointed out, this is the exact same problem that jQuery has when it
wants to allow authors to make calls like $('tdfoo/td') - they
have to actually reach into the string, figure out what the
appropriate context is, and create
Re: [webcomponents] HTML Parsing and the template element
Earlier in this thread I mentioned I expect, however, that there
might be larger ideas behind why not to
do this in the sense of web components or declarative MDV-like data binding...
I guess this is mostly a question for Dimitri or Dominic, but:
template is used/referenced extensively in the Web Components
Explainer[1] -- I am wondering what using template to hold something
like a mustache template (which doesn't use an HTML-like syntax for
things like iterators and thus must be used as a string) would mean
in the context of those proposals... How would it affect one's ability
to use custom elements, decorators, etc...?
- Brian
[1] - https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
On Wed, Apr 25, 2012 at 9:41 AM, Clint Hill clint.h...@gmail.com wrote:
JSONP:
script
src=/myserver/users/{userID}/profile.jsjsonp=setProfile/script
On 4/25/12 2:36 AM, Kornel Lesiński kor...@geekhood.net wrote:
On Wed, 25 Apr 2012 00:48:15 +0100, Clint Hill clint.h...@gmail.com
wrote:
1) Templates that cleanly include /script.
What's the use-case for including script in a template? Can't code
using
the template simply invoke functions it needs?
--
regards, Kornel Lesiński
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote:
Earlier in this thread I mentioned I expect, however, that there
might be larger ideas behind why not to
do this in the sense of web components or declarative MDV-like data
binding...
I guess this is mostly a question for Dimitri or Dominic, but:
template is used/referenced extensively in the Web Components
Explainer[1] -- I am wondering what using template to hold something
like a mustache template (which doesn't use an HTML-like syntax for
things like iterators and thus must be used as a string) would mean
in the context of those proposals... How would it affect one's ability
to use custom elements, decorators, etc...?
Why would we want to consider a solution that requires two-pass
parsing and thus is guaranteed to be slower and more error-prone?
:DG
- Brian
[1] - https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
On Wed, Apr 25, 2012 at 9:41 AM, Clint Hill clint.h...@gmail.com wrote:
JSONP:
script
src=/myserver/users/{userID}/profile.jsjsonp=setProfile/script
On 4/25/12 2:36 AM, Kornel Lesiński kor...@geekhood.net wrote:
On Wed, 25 Apr 2012 00:48:15 +0100, Clint Hill clint.h...@gmail.com
wrote:
1) Templates that cleanly include /script.
What's the use-case for including script in a template? Can't code
using
the template simply invoke functions it needs?
--
regards, Kornel Lesiński
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 25, 2012 at 1:57 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote: Earlier in this thread I mentioned I expect, however, that there might be larger ideas behind why not to do this in the sense of web components or declarative MDV-like data binding... I guess this is mostly a question for Dimitri or Dominic, but: template is used/referenced extensively in the Web Components Explainer[1] -- I am wondering what using template to hold something like a mustache template (which doesn't use an HTML-like syntax for things like iterators and thus must be used as a string) would mean in the context of those proposals... How would it affect one's ability to use custom elements, decorators, etc...? Why would we want to consider a solution that requires two-pass parsing and thus is guaranteed to be slower and more error-prone? The nature of my question isn't whether you/we would want to consider replacing the current inert parse with treat it as text... I will let someone else address that if they care to. Regardless, however, it definitely seems to be the case that several people here have pointed out that nothing in this prevents one from using template to send mustache or handlebars templates, then just grabbing it with innerHTML or maybe even making some special property (originalText or something) available and using it more or less the way we do now... However, the explainer uses templates as part of other ideas, like element and decorator. The question I am asking then is If one chose to use the manual two pass parse approach above, would that affect their ability to use those templates inside of element or decorator? None of the examples in the explainer actually appear to use template element as anything more than a static chunk of markup, so I'm not sure how they are applied/whether a templating language choice even matters... Could they (meaning templates used in element and decorator) include token replacement or iteration, etc? -Brian
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 25, 2012 at 11:32 AM, Brian Kardell bkard...@gmail.com wrote: On Wed, Apr 25, 2012 at 1:57 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote: Earlier in this thread I mentioned I expect, however, that there might be larger ideas behind why not to do this in the sense of web components or declarative MDV-like data binding... I guess this is mostly a question for Dimitri or Dominic, but: template is used/referenced extensively in the Web Components Explainer[1] -- I am wondering what using template to hold something like a mustache template (which doesn't use an HTML-like syntax for things like iterators and thus must be used as a string) would mean in the context of those proposals... How would it affect one's ability to use custom elements, decorators, etc...? Why would we want to consider a solution that requires two-pass parsing and thus is guaranteed to be slower and more error-prone? The nature of my question isn't whether you/we would want to consider replacing the current inert parse with treat it as text... I will let someone else address that if they care to. Regardless, however, it definitely seems to be the case that several people here have pointed out that nothing in this prevents one from using template to send mustache or handlebars templates, then just grabbing it with innerHTML or maybe even making some special property (originalText or something) available and using it more or less the way we do now... However, the explainer uses templates as part of other ideas, like element and decorator. The question I am asking then is If one chose to use the manual two pass parse approach above, would that affect their ability to use those templates inside of element or decorator? Ah, I think I understand what you're asking. In custom elements and decorators, the template contents are used to populate the shadow DOM subtree. You don't have to use the template tag, and just populate the shadow DOM subtree in your own preferred method (imperatively or by hooking in some other templating system). However, roll-your-own is pretty much guaranteed to be inferior in terms of readability and performance. :DG None of the examples in the explainer actually appear to use template element as anything more than a static chunk of markup, so I'm not sure how they are applied/whether a templating language choice even matters... Could they (meaning templates used in element and decorator) include token replacement or iteration, etc? No. Also, as spec'd today, HTML Templates (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html) do not have anything like token replacement or iteration. :DG -Brian
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 25, 2012 at 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: No. Also, as spec'd today, HTML Templates (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html) do not have anything like token replacement or iteration. Though, of course, we'd like to augment Templates to have those capabilities in the future, tied to MDV, and then Components can have inert MDV-driven template iteration in their shadow DOM... Yay for modular specs that combine together well! ~TJ
Re: [webcomponents] HTML Parsing and the template element
And when that becomes the case, then using the source text becomes problematic not just less efficient right? On Apr 25, 2012 6:15 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 25, 2012 at 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: No. Also, as spec'd today, HTML Templates ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html ) do not have anything like token replacement or iteration. Though, of course, we'd like to augment Templates to have those capabilities in the future, tied to MDV, and then Components can have inert MDV-driven template iteration in their shadow DOM... Yay for modular specs that combine together well! ~TJ
Re: [webcomponents] HTML Parsing and the template element
script type=text/html works for string-based templating. Special handling of /script is not a big enough pain to justify adding a template element. For Web Components and template systems that want to do DOM based templating (e.g. MDV), the template element can meet that need much better than a string-based approach. If nothing else, it's more efficient (e.g. it only parses the HTML once instead of for each instantiation of the template). String-based templating already works. We don't need new API for it. DOM-based templating and Web Components do need new API in order to work at all. There's no need, and little benefit, for the template element to try to meet both use-cases. Ojan On Wed, Apr 25, 2012 at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Apr 25, 2012 at 3:17 PM, Brian Kardell bkard...@gmail.com wrote: And when that becomes the case, then using the source text becomes problematic not just less efficient right? Yes, for exactly the reasons you can't nest scripts. ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote: script type=text/html works for string-based templating. Special handling of /script is not a big enough pain to justify adding a template element. ... String-based templating already works. We don't need new API for it. DOM-based templating and Web Components do need new API in order to work at all. There's no need, and little benefit, for the template element to try to meet both use-cases. Strongly support these two points. If we're writing a template using a custom template language with its own syntax, etc..., it IS a script and I don't see why we would want a new element for it. That use case is elegantly addressed by the script element, which is supported by virtually all major browsers. I even think it's actively harmful to introduce a new element to replace this use case (text-based templates). - Ryosuke
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special handling
of /script is not a big enough pain to justify adding a template element.
For Web Components and template systems that want to do DOM based templating
(e.g. MDV), the template element can meet that need much better than a
string-based approach. If nothing else, it's more efficient (e.g. it only
parses the HTML once instead of for each instantiation of the template).
String-based templating already works. We don't need new API for it.
DOM-based templating and Web Components do need new API in order to work at
all. There's no need, and little benefit, for the template element to try to
meet both use-cases.
String-based templating *doesn't* work unless you take pains to make
it work. This is why jQuery has to employ regex hacks to make
$('tdfoo/td') work the way you'd expect. Fixing that in the
platform is a win, so authors don't have to ship code down the wire to
deal with this (imo quite reasonable) use-case.
When you want to do DOM-based templating, such as for Components or
MDV, you run into the *exact same* problems as the above, where you
may want to template something that, in normal HTML parsing, expects
to be in a particular context. Solving the problem once is nice,
especially since we get to kill another problem at the same time. We
aren't even compromising - this is pretty much exactly what we want
for full DOM-based templating.
~TJ
Re: [webcomponents] HTML Parsing and the template element
On Apr 25, 2012 7:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special
handling
of /script is not a big enough pain to justify adding a template
element.
For Web Components and template systems that want to do DOM based
templating
(e.g. MDV), the template element can meet that need much better than a
string-based approach. If nothing else, it's more efficient (e.g. it
only
parses the HTML once instead of for each instantiation of the template).
String-based templating already works. We don't need new API for it.
DOM-based templating and Web Components do need new API in order to
work at
all. There's no need, and little benefit, for the template element to
try to
meet both use-cases.
String-based templating *doesn't* work unless you take pains to make
it work. This is why jQuery has to employ regex hacks to make
$('tdfoo/td') work the way you'd expect. Fixing that in the
platform is a win, so authors don't have to ship code down the wire to
deal with this (imo quite reasonable) use-case.
Tab, are you saying: a) fixing that in script apis for document fragment
or something is an ok solution to this, or that b) this means text
templates should use template or c) it should be the goal to kill string
templates altogether?
When you want to do DOM-based templating, such as for Components or
MDV, you run into the *exact same* problems as the above, where you
may want to template something that, in normal HTML parsing, expects
to be in a particular context. Solving the problem once is nice,
especially since we get to kill another problem at the same time. We
aren't even compromising - this is pretty much exactly what we want
for full DOM-based templating.
~TJ
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 25, 2012 at 4:22 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special
handling
of /script is not a big enough pain to justify adding a template
element.
For Web Components and template systems that want to do DOM based
templating
(e.g. MDV), the template element can meet that need much better than a
string-based approach. If nothing else, it's more efficient (e.g. it only
parses the HTML once instead of for each instantiation of the template).
String-based templating already works. We don't need new API for it.
DOM-based templating and Web Components do need new API in order to work
at
all. There's no need, and little benefit, for the template element to
try to
meet both use-cases.
String-based templating *doesn't* work unless you take pains to make
it work. This is why jQuery has to employ regex hacks to make
$('tdfoo/td') work the way you'd expect. Fixing that in the
platform is a win, so authors don't have to ship code down the wire to
deal with this (imo quite reasonable) use-case.
When you want to do DOM-based templating, such as for Components or
MDV, you run into the *exact same* problems as the above, where you
may want to template something that, in normal HTML parsing, expects
to be in a particular context. Solving the problem once is nice,
especially since we get to kill another problem at the same time. We
aren't even compromising - this is pretty much exactly what we want
for full DOM-based templating.
I agree with everything your saying, but I think you're mixing up two
different problems here. What you're listing above is not what I'm calling
templating. I would call that programmatic DOM creation. We also have to
solve that problem and, coincidentally, it will also require the same
parsing rules as the ones we're suggesting for template. When I'm talking
about templating, I'm talking about something that involves iteration and
data-binding, e.g. script type=text/htmldiv{{ myBoundVariable
}}/div/script.
Ojan
Re: [webcomponents] HTML Parsing and the template element
Yes!! Thanks guys...that's exactly the distictions and clarifications I was looking for...assuming these are acceptable distinctions, definitions and goals. On Apr 25, 2012 8:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 25, 2012 at 4:33 PM, Brian Kardell bkard...@gmail.com wrote: Tab, are you saying: a) fixing that in script apis for document fragment or something is an ok solution to this, or that b) this means text templates should use template or c) it should be the goal to kill string templates altogether? I just talked with Ojan in person, because we were talking past each other with the terms we were using. I now understand what he was saying! When we say string-based templating, we're really saying I want to embed an arbitrary foreign language into HTML. That language happens to be a templating language, but the exact purpose you're putting it to is irrelevant for our purposes here. For this, script type=foo is not only a satisfactory existing solution to this, but it's the *correct* solution to this - that's precisely what script is designed to do. I was confusing this term with the idea of programmatic DOM creation that doesn't suck. Right now, the right way to create a fragment of HTML is to use a lot of document.createElement() and el.appendChild(). This sucks. Instead, everyone wants to just write a string containing HTML and parse it, like what innerHTML and jQuery do. For this, Raf's proposal works great - it lets you use the innerHTML API without having to employ hacks like jQuery uses to ensure that things parse in the right context. Related closely to this is stuff like a Web Component that wants to fill itself with a DOM fragment. Right now, you're required to do that within script. This sucks, partially because of the aforementioned existing suckiness with DOM building. Even once we fix that with Raf's proposal, it will still suck, because it means that Components are required to run script to build themselves, even if their DOM structure is totally static and doesn't depend on outside data. We want template to help us solve this problem, by letting us send HTML structure *in HTML* and potentially hook it up to a component declaratively, so components don't need to run script unless they're actually doing something dynamic. Parsing the contents of a template correctly requires the same mechanism that Raf is proposing. Somewhat further away, we have another proposal, MDV, which *is* intending to replace the basic functionality of the current templating libraries. It takes something representing an inert DOM structure with holes punched in it for data to fill in, hooks it up to a JS object full of data, and pops out a fragment of real DOM with all the holes filled in. This is obviously useful when done purely via script (the popularity of templating libraries attests to that!), but there's intriguing design-space around *declarative* templating/iteration, where you just declare a template in markup, tell it how to fetch a data source to use, and it handles the rest for you. No script required! This is very similar to the no-script Components use-case, and so it would be nice to reuse template. Even if we use a differently-named element, the parsing problems are identical, and we still need something like Raf's proposal to solve them. (Even ignoring the pure-declarative case, being able to ship your templates in the page HTML and just grab them with script when you want to use it seems useful.) A text template like handlebars (in other words, a foreign language) should be able to use a significant fraction of the stuff that MDV provides. It will have to parse itself into a DOM structure with the holes set up manually, but once you've done so it should be able to be used in many of the same contexts. This has nothing to do with the template tag, though, because it's not *trying* to parse as HTML - they should use script. This isn't *completely* ideal - if you are *almost* fine with the functionality that MDV provides, but need just a little bit more, you either have to switch from template to script (which isn't trivial), or embed your extra functionality in the HTML via @data-* or something, which may be a bit clumsy. We'll see how bad this is in practice, but I suspect that once MDV matures, this will become a minor problem. ~TJ
Re: [webcomponents] HTML Parsing and the template element
Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. I know of many, many templating systems and I have simply never (aside from MDV) seen it in exactly this light (that is templates actually embedded in others), regardless of whether those are for within the browser for generating HTML (or anything else) or on the server - or even for code generation. It seems to me that there is a rich history of templating text, it's very useful and in every case I have seen you have a template and that template can contain references to other templates, not embed them... Am I seeing this improperly? This seems to be the case with freemarker, velocity, mustache, handlbars, even jsp, asp, php, etc - (there are really a lot of them, I'm just throwing out a bunch). This kind of approach does not seem like it would be out of place in HTML or even XML - we think about a lot of things that way (in terms of references). Are there some in particular that someone could point to that illustrate otherwise? If you use the same element as both a marker for the template and as a beam off which to hang instructions (template data-iterate for example) then you are bound to wind up in this situation, but otherwise I don't see why it is so controversial to just say not embedded, referenced. Perhaps if described as 2 or 3 tags instead of 1 it would be easier to discuss? 1. the template tag, just like script (can't embed itself) only template (so it can contain scripts and is easily identified for what it is) 2. a template-ref tag which allows you to ref another template (I expect this wont actually be used by a lot of languages since this is generally a feature of the template language itself - but ok) 3. a template-instruction tag which provides your beam off which to hang whatever (iterate, condition, etc) and allows anyone who is interested in building templating languages that are fully legit HTML to do so (I think that unless there is a lot more to the sale, people will tend to stick with non-HTML looking iterators, conditions, etc - but ok) Is 1 as I describe it really controversial? 2 and 3 seem to me to be clearly about features of a particular templating language (or at least a particular class of them that mostly don't exist today). I expect, however, that there might be larger ideas behind why not to do this in the sense of web components or declarative MDV-like data binding and it would be good to hear the larger perspective of how that might fit together so decisions on one front don't negate good ideas on another. - Brian On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote:
I know of many, many templating systems and I have simply never (aside
from MDV) seen it in exactly this light (that is templates actually
embedded in others), regardless of whether those are for within the
browser for generating HTML (or anything else) or on the server - or
even for code generation. It seems to me that there is a rich history
of templating text, it's very useful and in every case I have seen you
have a template and that template can contain references to other
templates, not embed them... Am I seeing this improperly? This seems
to be the case with freemarker, velocity, mustache, handlbars, even
jsp, asp, php, etc - (there are really a lot of them, I'm just
throwing out a bunch). This kind of approach does not seem like it
would be out of place in HTML or even XML - we think about a lot of
things that way (in terms of references). Are there some in
particular that someone could point to that illustrate otherwise?
Most system do allow it. The syntax they use might not make it clear.
http://emberjs.com/#toc_displaying-a-list-of-items
ul
{{#each people}}
liHello, {{name}}!/li
{{/each}}
/ul
In here there is a template between the start each and end each.
--
erik
Re: [webcomponents] HTML Parsing and the template element
Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. I would recommend adding a mime type specifier to the template. Choosing text/html as a content type may hint that contents should be parsed. Alternatively or additionally an attribute indicating that the contents should be parsed as DOM may be specified, e.g. template html/ or template dom/. On Apr 24, 2012 6:25 AM, Rafael Weinstein rafa...@google.com wrote: Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of
Re: [webcomponents] HTML Parsing and the template element
On 04/24/2012 05:57 PM, Yuval Sadan wrote: Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. That is actually quite a useful axis of distinction. If we want normal methods on the document like getElementsByClassName or getElementById to return elements in templates they obviously need to be parsed as actual elements in the DOM. If we don't it seems very unnatural to have them parsed as elements; making DOM Core methods, CSS selectors, etc. have some dependence on whether there is an element called template in the tree just seems like a recipe for pain. My feeling is that the elements in templates aren't like the other elements in the document and so we don't want the normal lookup/traversal methods on document to work on them.
Re: [webcomponents] HTML Parsing and the template element
Hmm. I have to say that I disagree that your example below shows a
template within a template. That is IMO 1 template wherein there is
iteration syntax.
But to further my point: Where does the demarcation of template stop and
template syntax begin in your example? Or are you saying that the template
syntax is in fact that demarcation?
On 4/24/12 8:48 AM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote:
I know of many, many templating systems and I have simply never (aside
from MDV) seen it in exactly this light (that is templates actually
embedded in others), regardless of whether those are for within the
browser for generating HTML (or anything else) or on the server - or
even for code generation. It seems to me that there is a rich history
of templating text, it's very useful and in every case I have seen you
have a template and that template can contain references to other
templates, not embed them... Am I seeing this improperly? This seems
to be the case with freemarker, velocity, mustache, handlbars, even
jsp, asp, php, etc - (there are really a lot of them, I'm just
throwing out a bunch). This kind of approach does not seem like it
would be out of place in HTML or even XML - we think about a lot of
things that way (in terms of references). Are there some in
particular that someone could point to that illustrate otherwise?
Most system do allow it. The syntax they use might not make it clear.
http://emberjs.com/#toc_displaying-a-list-of-items
ul
{{#each people}}
liHello, {{name}}!/li
{{/each}}
/ul
In here there is a template between the start each and end each.
--
erik
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 11:48 AM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote:
I know of many, many templating systems and I have simply never (aside
from MDV) seen it in exactly this light (that is templates actually
embedded in others), regardless of whether those are for within the
browser for generating HTML (or anything else) or on the server - or
even for code generation. It seems to me that there is a rich history
of templating text, it's very useful and in every case I have seen you
have a template and that template can contain references to other
templates, not embed them... Am I seeing this improperly? This seems
to be the case with freemarker, velocity, mustache, handlbars, even
jsp, asp, php, etc - (there are really a lot of them, I'm just
throwing out a bunch). This kind of approach does not seem like it
would be out of place in HTML or even XML - we think about a lot of
things that way (in terms of references). Are there some in
particular that someone could point to that illustrate otherwise?
Most system do allow it. The syntax they use might not make it clear.
http://emberjs.com/#toc_displaying-a-list-of-items
ul
{{#each people}}
liHello, {{name}}!/li
{{/each}}
/ul
In here there is a template between the start each and end each.
While you could think of it that way, that's not generally how we
refer to it when discussing templates - right? Just pick any and the
documentation (it seems to me) will refer to templates separately
from instructions/macros/etc that make up the templating language (the
above are an example of handlebars each block helpers). In your
provided example (which uses handlebars) the better analogy to what I
am arguing is partials - see https://github.com/wycats/handlebars.js/
--- about 1/2 way down the page you will find:
Partials
You can register additional templates as partials, which will be used
by Handlebars when it encounters a partial ({{ partialName}}).
Partials can either be String templates or compiled template
functions. Here's an example:
var source = ul{{#people}}li{{ link}}/li{{/people}}/ul;
Handlebars.registerPartial('link', 'a href=/people/{{id}}{{name}}/a')
var template = Handlebars.compile(source);
var data = { people: [
{ name: Alan, id: 1 },
{ name: Yehuda, id: 2 }
]};
template(data);
// Should render:
// ul
// lia href=/people/1Alan/a/li
// lia href=/people/2Yehuda/a/li
// /ul
Again, all of these templating systems (it seems to me) draw a
distinction between these two ideas... Am I missing something?
Re: [webcomponents] HTML Parsing and the template element
I agree with these statements: there is no use for the contents before it is used programmatically it's never considered to be part of the document's semantic content I'd like to add that the only use-case for a template/ tag (IMO) is to deliver content to the UA safely preventing the DOM from using it. I would never want the UA to present this content or place it in the element stack before something has programmatically manipulated it. To have the UA parse it and add it to the element stack seems problematic in that it would possibly have to be reversed out once I'm done manipulating it. From: Yuval Sadan sadan.yu...@gmail.com Date: Tue, 24 Apr 2012 18:57:46 +0300 To: Rafael Weinstein rafa...@google.com Cc: public-webapps public-webapps@w3.org, Ryosuke Niwa rn...@webkit.org Subject: Re: [webcomponents] HTML Parsing and the template element Resent-From: public-webapps@w3.org Resent-Date: Tue, 24 Apr 2012 15:58:26 + Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. I would recommend adding a mime type specifier to the template. Choosing text/html as a content type may hint that contents should be parsed. Alternatively or additionally an attribute indicating that the contents should be parsed as DOM may be specified, e.g. template html/ or template dom/. On Apr 24, 2012 6:25 AM, Rafael Weinstein rafa...@google.com wrote: Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. If iteration uses a different tagname than normal templating (say, iterate), thus avoiding the nesting template in template problem, you still have the problem of nesting iteration, which is *also* a common ability for template systems. Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. Might as well do that early so you can immediately delve into it with DOM methods and whatnot, rather than delaying it and keeping it as flat text until the point of use. ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 9:11 AM, James Graham jgra...@opera.com wrote: On 04/24/2012 05:57 PM, Yuval Sadan wrote: Placing contents as CDATA is an option. I personally think the template/ tag as proposed is adhoc to somebody's notion of how templates should work. To avoid this I think they should be simpler. I am not seeing the added advantage of having the client parse the contents upon encountering it: there is no use for the contents before it is used programatically, and as such it could be prepared on first use, via the DocumentFragment suggestion mentioned earlier. Specifically, it's never considered to be part of the document's semantic content. Perhaps I'm overlooking something here. That is actually quite a useful axis of distinction. If we want normal methods on the document like getElementsByClassName or getElementById to return elements in templates they obviously need to be parsed as actual elements in the DOM. If we don't it seems very unnatural to have them parsed as elements; making DOM Core methods, CSS selectors, etc. have some dependence on whether there is an element called template in the tree just seems like a recipe for pain. My feeling is that the elements in templates aren't like the other elements in the document and so we don't want the normal lookup/traversal methods on document to work on them. I *believe* we don't want lookup methods to find the inert elements inside of a template. Traversal should still work, obviously - if you ask for the children of a template node, you should get its actual children, so you can manipulate them. This distinction is why one possible approach (previously stated) is to stuff the elements into a separate subtree, similar to the shadow tree. That might make the design somewhat cleaner, in that the lookup methods can continue to just lookup in the normal DOM. ~TJ ~TJ
Re: [webcomponents] HTML Parsing and the template element
Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. This is a great point: What parser? If you're implying the HTML Parser, then I think we're talking about a Templating syntax and not just a template/ tag. To which I would imagine is the hard road to take. On 4/24/12 9:45 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. If iteration uses a different tagname than normal templating (say, iterate), thus avoiding the nesting template in template problem, you still have the problem of nesting iteration, which is *also* a common ability for template systems. Any way you slice it, common templating scenarios will create problems if you don't hook it up to a proper parser at some point. Might as well do that early so you can immediately delve into it with DOM methods and whatnot, rather than delaying it and keeping it as flat text until the point of use. ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 10:14 AM, Brian Kardell bkard...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. But in his example, and most of the ones people have been citing or really want to use this for they are no tags in the HTML sense... Those are handlebars (or mustache or dust or haml or whatever) [snip further comments along similar lines] As long as it's handlebars that merely *look* like elements, we have to ship code down the wire that is simply a functional replacement for the DOM that the user already has. This is suboptimal. It's a cowpath that only curves this way because the straighter path was blocked by a boulder, and cows don't have dynamite. We do. The more we can replace code-on-the-wire with code-in-the-browser, the better. (Subject to obvious tradeoffs, of course.) ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 10:14 AM, Brian Kardell bkard...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill clint.h...@gmail.com wrote: Hmm. I have to say that I disagree that your example below shows a template within a template. That is IMO 1 template wherein there is iteration syntax. The iteration syntax is basically an element - the example that Arv gave even used element-like syntax, with open and close tags. That iteration element is inside of a template. But in his example, and most of the ones people have been citing or really want to use this for they are no tags in the HTML sense... Those are handlebars (or mustache or dust or haml or whatever) [snip further comments along similar lines] As long as it's handlebars that merely *look* like elements, we have to ship code down the wire that is simply a functional replacement for the DOM that the user already has. This is suboptimal. It's a cowpath that only curves this way because the straighter path was blocked by a boulder, and cows don't have dynamite. We do. I do not think it is an entirely accurate statement to say the path only curves this way because the straighter path was blocked by a boulder. There is pretty much nothing preventing existing templating languages (client or server) from looking (inside) just like has been suggested, and yet the most popular ones generally don't do that... Instead, we use things for instructions/controls/macros/etc that purposely don't look like HTML specifically to call them out as different because that increases readability and maintainability - and it makes them not use-specific (I can use them to generate anything, not just DOM). Personally, I prefer it that way - but maybe that's just me? It does seem to be the case that many people are talking about though -- using those libraries with the template tag... Maybe they can chime in... I am very interested though in knowing whether this would essentially be a case of allowed/works, but discouraged. I do agree that it is less optimal in the sense that you have to lex/parse/etc but that also means there is a lot of room for competition in variants which I think is a good thing in general. If things get so tight as to require that the template tag identifies iterators, etc as well (by way of data-* attributes) - I think that would limit the competition for templating languages to very close to 1. At that point, might as well go ahead and define it. At that point - it also seems salty enough to my taste to want to trade a few ms for something I like more... Does anyone have any kinds of metrics illustrating just how much better optimized this would be by comparison? I've used templating a lot and honestly, I've never found it to be the bottleneck or the problem. All that said, maybe with some time and experience I could learn to love it as DOM too... I'm really not trying to be the only one arguing endlessly about it, so unless someone backs me up on at least some point here I will rest my case :) -Brian
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 2:40 PM, Brian Kardell bkard...@gmail.com wrote: All that said, maybe with some time and experience I could learn to love it as DOM too... I'm really not trying to be the only one arguing endlessly about it, so unless someone backs me up on at least some point here I will rest my case :) I feel the same way. I'm not really sure why we would want to use elements and attributes to define the templating language. If the purpose is we can now parse templates using DOM, then I have to wonder if anyone using templates is actually asking for that. I know of two use cases that need to be solved: 1) Templates that cleanly include /script. 2) Generating fragments with arbitrary top-level elements. Are there other use cases that are trying to be solved with template?
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 24, 2012 at 12:00, Scott González scott.gonza...@gmail.com wrote:
Are there other use cases that are trying to be solved with template?
3. Inert. You don't want to fetch resources at unresolved URLs.
img src=/images/${user}.png
4. Selectors should not match content of the template
both of these works fine with script type=text/x-this-is-a-hack
--
erik
Re: [webcomponents] HTML Parsing and the template element
You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.comwrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. :DG
Re: [webcomponents] HTML Parsing and the template element
Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.comwrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. :DG
Re: [webcomponents] HTML Parsing and the template element
Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. :DG
Re: [webcomponents] HTML Parsing and the template element
I'd like to weigh in on this topic as it is something that I'm involved in at work as well. Could you maybe explain further parsing the template contents as HTML can contain sub templates? If you take this example: template div!-- A little markup //--/div template!-- subtemplate markup //--/template div!-- A little more markup //--/div /template Are you saying there is 1 Node that has a 3 children? If yes what benefit does that bring that inert tags doesn't? On 4/23/12 8:25 PM, Rafael Weinstein rafa...@google.com wrote: Yes. I think this issue is a distraction. Using the script tag for encoding opaque text contents is a hack, but it works as well as it can. AFAIC, The main drawback is that the contents cannot contain the string /script. This will be the case for any new element we came up with for this purpose. If someone has an idea for how to do better than this and why it's worth doing, please speak up. Part of the point of parsing the template contents as HTML is exactly so that template contents can contain subtemplates. It's a universal feature of templating systems and needs to be well supported. On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we just use script elements for that then? On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote: You musn't forget what we're not planning for. Templates can be great for so many applications - generating code (JSON, Javascript), generating plain-text or otherwise formatted (markdown, restructured text, etc.) content and much more. I don't think templates should be parsed by DOM unless explicitly requested. The simplest scenario should also be supported imho, that is script type=text/html/script-ish markup with access to textContent. On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com wrote: On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com wrote: On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface? This seems like a neat idea -- though I haven't thought about this in depth yet. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element
Re: [webcomponents] HTML Parsing and the template element
On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html Once parsed, the template contents must not be in the document tree. That's surprising, radical and weird. Why are the template contents hosted in a document fragment that the template element points to using a non-child property? Why aren't the template contents simply hosted as a subtree rooted at the template element? This also breaks the natural mapping between XML source and the DOM in the XML case. This weirdness also requires a special case to the serialization algorithm. If the document fragment wasn't there and the contents of the template were simply children of template element, the parsing algorithm changes would look rather sensible. Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen hsivo...@iki.fi wrote: When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. FYI, now there's dialog and a global inert= attribute so if those features stay template should presumably just hook into them. -- Anne van Kesteren http://annevankesteren.nl/
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote: On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html Once parsed, the template contents must not be in the document tree. That's surprising, radical and weird. Why are the template contents hosted in a document fragment that the template element points to using a non-child property? Why aren't the template contents simply hosted as a subtree rooted at the template element? In terms of weirdness, this is not much different from the textarea, script, or xmp. It does change the existing behavior, so anyone using a template tag today will suddenly find no child nodes -- that part _is_ a bit surprising. However, moving this into a separate document fragment allows us to easily define the boundaries of intertness. If you look at the spec, the document fragment is indeed created from a separate document is inert (like createHTMLDocument case): http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template-contents-initialization. This also breaks the natural mapping between XML source and the DOM in the XML case. True. This weirdness also requires a special case to the serialization algorithm. True. If the document fragment wasn't there and the contents of the template were simply children of template element, the parsing algorithm changes would look rather sensible. Great! Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. :DG -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 18, 2012 at 8:46 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 18 Apr 2012 16:49:55 +0200, Henri Sivonen hsivo...@iki.fi wrote: When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. FYI, now there's dialog and a global inert= attribute so if those features stay template should presumably just hook into them. Different concept of 'inertness', unless I'm greatly mistaken. The @inert attribute turns off all user interaction - mouse, tabs, access keys, etc. - with the elements in the subtree. The inertness that the template element wants is preventing network requests and such, so that it's friendly to templating systems that want to produce templated urls in img/etc that get some of their pieces filled in upon instantiation. ~TJ
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote: On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html Once parsed, the template contents must not be in the document tree. That's surprising, radical and weird. Why are the template contents hosted in a document fragment that the template element points to using a non-child property? Why aren't the template contents simply hosted as a subtree rooted at the template element? As Dimitri says, it can make inertness a little simpler to explain. It also prevents APIs like querySelector from accidentally grabbing the contents of a template when they *intend* to grab the real DOM produced from the template. ~TJ This also breaks the natural mapping between XML source and the DOM in the XML case. This weirdness also requires a special case to the serialization algorithm. If the document fragment wasn't there and the contents of the template were simply children of template element, the parsing algorithm changes would look rather sensible. Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 18, 2012 at 9:32 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote: On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html Once parsed, the template contents must not be in the document tree. That's surprising, radical and weird. Why are the template contents hosted in a document fragment that the template element points to using a non-child property? Why aren't the template contents simply hosted as a subtree rooted at the template element? In terms of weirdness, this is not much different from the textarea, script, or xmp. It does change the existing behavior, so anyone using a template tag today will suddenly find no child nodes -- that part _is_ a bit surprising. However, moving this into a separate document fragment allows us to easily define the boundaries of intertness. If you look at the spec, the document fragment is indeed created from a separate document is inert (like createHTMLDocument case): http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template-contents-initialization. This also breaks the natural mapping between XML source and the DOM in the XML case. True. I've created a bug against the spec to make clear that the XML parser will be unchanged WRT the template element. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16787 This weirdness also requires a special case to the serialization algorithm. True. If the document fragment wasn't there and the contents of the template were simply children of template element, the parsing algorithm changes would look rather sensible. Great! Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. :DG -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Wed, 18 Apr 2012, Dimitri Glazkov wrote: Wouldn't it make more sense to host the template contents as normal descendants of the template element and to make templating APIs accept either template elements or document fragments as template input? Or to make the template elements have a cloneAsFragment() method if the template fragment is designed to be cloned as the first step anyway? When implementing this, making embedded content inert is probably the most time-consuming part and just using a document fragment as a wrapper isn't good enough anyway, since for example img elements load their src even when not inserted into the DOM tree. Currently, Gecko can make imbedded content inert on a per-document basis. This capability is used for documents returned by XHR, createDocument and createHTMLDocument. It looks like the template proposal will involve computing inertness from the ancestor chain (template ancestor or DocumentFragment marked as inert as an ancestor). It's unclear to me what the performance impact will be. Right, ancestor-based inertness is exactly what we avoid with sticking the parsed contents into a document fragment from an inert document. Otherwise, things get hairy quick. I am also pretty scared of tokenising stuff like it is markup but then sticking it into a different document. It seems like very surprising behaviour. Have you considered (and this may be a very bad idea) exposing the markup inside the template as a text node, but exposing the corresponding DOM as an IDL attribute on the HTMLTemplateElement (or whatever it's called) interface?
Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 4, 2012 at 12:12 PM, Rafael Weinstein rafa...@google.com wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == Not this! Here's why: Making something look like markup but then not tokenizing it as markup is confusing. The confusion leads to authors not having a clear mental model of what's going on and where stuff ends. Trying to make things just work for authors leads to even more confusing here be dragons solutions. Check out http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state Making something that looks like markup but isn't tokenized as markup also makes the delta between HTML and XHTML greater. Some people may be ready to throw XHTML under the bus completely at this point, but this also goes back to the confusion point. Apart from namespaces, the mental model you can teach for XML is remarkably sane. Whenever HTML deviates from it, it's a complication in the understandability of HTML. Also, multi-level parsing is in principle bad for perf. (How bad really? Dunno.) I *really* don't want to end up writing a single-pass parser that has to be black-box indishtinguishable from something that's defined as a multi-pass parser. (There might be a longer essay about how this sucks in the public-html archives, since the SVG WG proposed something like this at one point, too.) == IDEA 2: Just tweak insertion modes == I think a DWIM insertion mode that switches to another mode and reprocesses the token upon the first start tag token *without* trying to return to the DWIM insertion mode when the matching end tag is seen for the start tag that switched away from the DWIM mode is something that might be worth pursuing. If we do it, I think we should make it work for a fragment parsing API that doesn't require context beyound assuming HTML, too. (I think we shouldn't try to take the DWIM so far that a contextless API would try to guess HTML vs. SVG vs. MathML.) Just to connect the threads. A few weeks back, I posted an update about the HTML Templates spec: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1171.html Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html The draft is roughly two parts: motivation for the spec and deltas to HTML specification to allow serialization and parsing of the template element. To be honest, after finishing the draft, I wondered if we should just merge the whole thing into the HTML specification. As a warm-up exercise for the draft, I first implemented the changes to tree construction algorithm here in WebKit (https://bugs.webkit.org/show_bug.cgi?id=78734). The patch (https://bugs.webkit.org/attachment.cgi?id=128579action=review) includes new parsing tests, and should be fairly intuitive to read to those familiar with the test format. The interesting bit here is that all parser changes are additive: we are only adding what effectively are extensions points -- well, that and a new contextless parsing mode for when inside of the template tag. I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? If you're going to change the parser when adding the template element, what's in that spec looks fairly reasonable to me. Hixie and Henri have spent more time designing the algorithm that I have (Eric and I just implemented it), so they might have a different perspective. Adam The violation of the Degrade Gracefully principle and tearing the parser spec open right when everybody converged on the spec worry me, though. I'm still hoping for a design that doesn't require parser changes at all and that doesn't blow up in legacy browsers (even better if the results in legacy browsers were sane enough to serve as input for a polyfill). I agree with your concern. It's bugging me too -- that's why I am not being an arrogant jerk yelling at people and trying to shove this through. In general, it's difficult to justify making changes to anything that's stable -- especially considering how long and painful the road to getting stable was. However, folks like Yehuda, Erik, and Rafael spent years tackling this problem, and I tend to trust their steady hand... hands? I don't think there's an option to degrade gracefully here. My personal feeling is that even if it's years
Re: [webcomponents] HTML Parsing and the template element
On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == Not this! Here's why: Making something look like markup but then not tokenizing it as markup is confusing. The confusion leads to authors not having a clear mental model of what's going on and where stuff ends. Trying to make things just work for authors leads to even more confusing here be dragons solutions. Check out http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state Making something that looks like markup but isn't tokenized as markup also makes the delta between HTML and XHTML greater. Some people may be ready to throw XHTML under the bus completely at this point, but this also goes back to the confusion point. Apart from namespaces, the mental model you can teach for XML is remarkably sane. Whenever HTML deviates from it, it's a complication in the understandability of HTML. Also, multi-level parsing is in principle bad for perf. (How bad really? Dunno.) I *really* don't want to end up writing a single-pass parser that has to be black-box indishtinguishable from something that's defined as a multi-pass parser. (There might be a longer essay about how this sucks in the public-html archives, since the SVG WG proposed something like this at one point, too.) == IDEA 2: Just tweak insertion modes == I think a DWIM insertion mode that switches to another mode and reprocesses the token upon the first start tag token *without* trying to return to the DWIM insertion mode when the matching end tag is seen for the start tag that switched away from the DWIM mode is something that might be worth pursuing. If we do it, I think we should make it work for a fragment parsing API that doesn't require context beyound assuming HTML, too. (I think we shouldn't try to take the DWIM so far that a contextless API would try to guess HTML vs. SVG vs. MathML.) Just to connect the threads. A few weeks back, I posted an update about the HTML Templates spec: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1171.html Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html The draft is roughly two parts: motivation for the spec and deltas to HTML specification to allow serialization and parsing of the template element. To be honest, after finishing the draft, I wondered if we should just merge the whole thing into the HTML specification. As a warm-up exercise for the draft, I first implemented the changes to tree construction algorithm here in WebKit (https://bugs.webkit.org/show_bug.cgi?id=78734). The patch (https://bugs.webkit.org/attachment.cgi?id=128579action=review) includes new parsing tests, and should be fairly intuitive to read to those familiar with the test format. The interesting bit here is that all parser changes are additive: we are only adding what effectively are extensions points -- well, that and a new contextless parsing mode for when inside of the template tag. I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? The violation of the Degrade Gracefully principle and tearing the parser spec open right when everybody converged on the spec worry me, though. I'm still hoping for a design that doesn't require parser changes at all and that doesn't blow up in legacy browsers (even better if the results in legacy browsers were sane enough to serve as input for a polyfill). I agree with your concern. It's bugging me too -- that's why I am not being an arrogant jerk yelling at people and trying to shove this through. In general, it's difficult to justify making changes to anything that's stable -- especially considering how long and painful the road to getting stable was. However, folks like Yehuda, Erik, and Rafael spent years tackling this problem, and I tend to trust their steady hand... hands? I don't think there's an option to degrade gracefully here. My personal feeling is that even if it's years before browsers reliably support this and developers can use it without needing to be careful until then, there's a long term view here which is the sooner me put this into the spec, the sooner that day will arrive. Also, I like this approach because it addresses the inert DOM use case as well as the context-free parsing use case. :DG
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == Not this! Here's why: Making something look like markup but then not tokenizing it as markup is confusing. The confusion leads to authors not having a clear mental model of what's going on and where stuff ends. Trying to make things just work for authors leads to even more confusing here be dragons solutions. Check out http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state Making something that looks like markup but isn't tokenized as markup also makes the delta between HTML and XHTML greater. Some people may be ready to throw XHTML under the bus completely at this point, but this also goes back to the confusion point. Apart from namespaces, the mental model you can teach for XML is remarkably sane. Whenever HTML deviates from it, it's a complication in the understandability of HTML. Also, multi-level parsing is in principle bad for perf. (How bad really? Dunno.) I *really* don't want to end up writing a single-pass parser that has to be black-box indishtinguishable from something that's defined as a multi-pass parser. (There might be a longer essay about how this sucks in the public-html archives, since the SVG WG proposed something like this at one point, too.) == IDEA 2: Just tweak insertion modes == I think a DWIM insertion mode that switches to another mode and reprocesses the token upon the first start tag token *without* trying to return to the DWIM insertion mode when the matching end tag is seen for the start tag that switched away from the DWIM mode is something that might be worth pursuing. If we do it, I think we should make it work for a fragment parsing API that doesn't require context beyound assuming HTML, too. (I think we shouldn't try to take the DWIM so far that a contextless API would try to guess HTML vs. SVG vs. MathML.) Just to connect the threads. A few weeks back, I posted an update about the HTML Templates spec: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1171.html Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html The draft is roughly two parts: motivation for the spec and deltas to HTML specification to allow serialization and parsing of the template element. To be honest, after finishing the draft, I wondered if we should just merge the whole thing into the HTML specification. As a warm-up exercise for the draft, I first implemented the changes to tree construction algorithm here in WebKit (https://bugs.webkit.org/show_bug.cgi?id=78734). The patch (https://bugs.webkit.org/attachment.cgi?id=128579action=review) includes new parsing tests, and should be fairly intuitive to read to those familiar with the test format. The interesting bit here is that all parser changes are additive: we are only adding what effectively are extensions points -- well, that and a new contextless parsing mode for when inside of the template tag. The violation of the Degrade Gracefully principle and tearing the parser spec open right when everybody converged on the spec worry me, though. I'm still hoping for a design that doesn't require parser changes at all and that doesn't blow up in legacy browsers (even better if the results in legacy browsers were sane enough to serve as input for a polyfill). I agree with your concern. It's bugging me too -- that's why I am not being an arrogant jerk yelling at people and trying to shove this through. In general, it's difficult to justify making changes to anything that's stable -- especially considering how long and painful the road to getting stable was. However, folks like Yehuda, Erik, and Rafael spent years tackling this problem, and I tend to trust their steady hand... hands? :DG
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == Not this! Here's why: Making something look like markup but then not tokenizing it as markup is confusing. The confusion leads to authors not having a clear mental model of what's going on and where stuff ends. Trying to make things just work for authors leads to even more confusing here be dragons solutions. Check out http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state Making something that looks like markup but isn't tokenized as markup also makes the delta between HTML and XHTML greater. Some people may be ready to throw XHTML under the bus completely at this point, but this also goes back to the confusion point. Apart from namespaces, the mental model you can teach for XML is remarkably sane. Whenever HTML deviates from it, it's a complication in the understandability of HTML. Also, multi-level parsing is in principle bad for perf. (How bad really? Dunno.) I *really* don't want to end up writing a single-pass parser that has to be black-box indishtinguishable from something that's defined as a multi-pass parser. (There might be a longer essay about how this sucks in the public-html archives, since the SVG WG proposed something like this at one point, too.) This makes sense. As an aside, this is also why implementing templates as a script tag is a bad idea. == IDEA 2: Just tweak insertion modes == I think a DWIM insertion mode that switches to another mode and reprocesses the token upon the first start tag token *without* trying to return to the DWIM insertion mode when the matching end tag is seen for the start tag that switched away from the DWIM mode is something that might be worth pursuing. If we do it, I think we should make it work for a fragment parsing API that doesn't require context beyound assuming HTML, too. (I think we shouldn't try to take the DWIM so far that a contextless API would try to guess HTML vs. SVG vs. MathML.) Sounds like a good direction to explore. I'll play with this. The violation of the Degrade Gracefully principle and tearing the parser spec open right when everybody converged on the spec worry me, though. I'm still hoping for a design that doesn't require parser changes at all and that doesn't blow up in legacy browsers (even better if the results in legacy browsers were sane enough to serve as input for a polyfill). Yeah, Adam expressed a similar concern. I must admit, before digging into the HTML parsing, I was a bit more bullish about making this just work. Turns out, there's this delicate balance between the reality and the proper solution. I am still optimistic we can find something that both doesn't look like a gross hack and degrades well in most cases. :DG -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[webcomponents] HTML Parsing and the template element
Hello folks!
You may be familiar with the work around the template element, or a
way to declare document fragments in HTML (see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033868.html
for some background).
In trying to understand how this newfangled beast would work, I
started researching HTML parsing, and--oh boy was I ever sorry! Err..
I mean.. --and investigating how the contents of the template
element could be parsed.
So far, I have two ideas. Both introduce changes to HTML parsing
algorithm. Both have flaws, and I thought the best thing to do would
be to share the data with the experts and seek their opinions. Those
of you cc'd -- you're the designated experts :)
== IDEA 1: Keep template contents parsing in the tokenizer ==
PRO: if we could come up with a way to perceive the stuff between
template and /template as a character stream, we enable a set of
use cases where the template contents does not need to be a complete
HTML subtree. For example, I could define a template that sets up a
start of a table, then a few that provide repetition patterns for
rows/cells, and then one to close out a table:
template id=headtablecaptionNyan-nyan/captionthead ...
tbody/template
template id=rowtrtemplatetd ... /td/template/tr/template
template id=foot/tbody/table/template
Then I could slam these templates together with some API and produce
an arbitrary set of tables.
PRO: Since the template contents are parsed as string, we create
opportunities for performance optimizations at the UA level. If a
bunch of templates is declared, but only a handful is used, we could
parse template contents on demand, thus reducing the churn of DOM
elements.
CON: Tokenizer needs to be really smart and will start looking a lot
like a specialized parser. At first glance, template behaves much
like a textarea -- any tags inside will just be treated as
characters. It works until you realize that templates sometimes need
to be nested. Any use case that involves building a
larger-than-one-dimensional data representation (like tables) will
involve nested templates. This makes things rather tricky. I made an
attempt of sketching this out here:
http://dvcs.w3.org/hg/webcomponents/raw-file/a28e16cc4167/spec/templates/index.html#parsing.
As you can see, this adds a largish set of new states to tokenizer.
And it is still incomplete, breaking in cases like
templatescriptalert('template is
awesome!');/script/template.
It could be argued that--while pursuing the tokenizer algorithm
perfection--we could just stop at some point of complexity and issue a
stern warning for developers to not get too crazy, because stuff will
break -- akin to including /script string in your Javascript code.
== IDEA 2: Just tweak insertion modes ==
PRO: It's a lot less intrusive to the parser -- just adjust insertion
modes to allow template tags in places where they would ordinary be
ignored or foster-parented, and add a new insertion for template
contents to let all tags in. I made a quick sketch here:
http://dvcs.w3.org/hg/webcomponents/raw-file/c96f051ca008/spec/templates/index.html#parsing
(Note: more massaging is needed to make it really work)
CON: You can't address fun partial-tree scenarios.
Which idea appeals to you? Perhaps you have better ideas? Please share.
:DG
Re: [webcomponents] HTML Parsing and the template element
Re-using the generic raw text element parsing algorithm would be the
simplest change to the parser. Do you have a concrete example of
where nested template declarations are required? For example,
rather than including nested templates, you might instead consider
referencing other template elements by id.
Adam
On Wed, Feb 8, 2012 at 2:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
Hello folks!
You may be familiar with the work around the template element, or a
way to declare document fragments in HTML (see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033868.html
for some background).
In trying to understand how this newfangled beast would work, I
started researching HTML parsing, and--oh boy was I ever sorry! Err..
I mean.. --and investigating how the contents of the template
element could be parsed.
So far, I have two ideas. Both introduce changes to HTML parsing
algorithm. Both have flaws, and I thought the best thing to do would
be to share the data with the experts and seek their opinions. Those
of you cc'd -- you're the designated experts :)
== IDEA 1: Keep template contents parsing in the tokenizer ==
PRO: if we could come up with a way to perceive the stuff between
template and /template as a character stream, we enable a set of
use cases where the template contents does not need to be a complete
HTML subtree. For example, I could define a template that sets up a
start of a table, then a few that provide repetition patterns for
rows/cells, and then one to close out a table:
template id=headtablecaptionNyan-nyan/captionthead ...
tbody/template
template id=rowtrtemplatetd ... /td/template/tr/template
template id=foot/tbody/table/template
Then I could slam these templates together with some API and produce
an arbitrary set of tables.
PRO: Since the template contents are parsed as string, we create
opportunities for performance optimizations at the UA level. If a
bunch of templates is declared, but only a handful is used, we could
parse template contents on demand, thus reducing the churn of DOM
elements.
CON: Tokenizer needs to be really smart and will start looking a lot
like a specialized parser. At first glance, template behaves much
like a textarea -- any tags inside will just be treated as
characters. It works until you realize that templates sometimes need
to be nested. Any use case that involves building a
larger-than-one-dimensional data representation (like tables) will
involve nested templates. This makes things rather tricky. I made an
attempt of sketching this out here:
http://dvcs.w3.org/hg/webcomponents/raw-file/a28e16cc4167/spec/templates/index.html#parsing.
As you can see, this adds a largish set of new states to tokenizer.
And it is still incomplete, breaking in cases like
templatescriptalert('template is
awesome!');/script/template.
It could be argued that--while pursuing the tokenizer algorithm
perfection--we could just stop at some point of complexity and issue a
stern warning for developers to not get too crazy, because stuff will
break -- akin to including /script string in your Javascript code.
== IDEA 2: Just tweak insertion modes ==
PRO: It's a lot less intrusive to the parser -- just adjust insertion
modes to allow template tags in places where they would ordinary be
ignored or foster-parented, and add a new insertion for template
contents to let all tags in. I made a quick sketch here:
http://dvcs.w3.org/hg/webcomponents/raw-file/c96f051ca008/spec/templates/index.html#parsing
(Note: more massaging is needed to make it really work)
CON: You can't address fun partial-tree scenarios.
Which idea appeals to you? Perhaps you have better ideas? Please share.
:DG
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote: ... Do you have a concrete example of where nested template declarations are required? When working with tree like structures it is comment to use recursive templates. http://code.google.com/p/mdv/source/browse/use_cases/tree.html -- erik
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 2:20 PM, Erik Arvidsson a...@chromium.org wrote:
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote:
... Do you have a concrete example of
where nested template declarations are required?
When working with tree like structures it is comment to use recursive
templates.
http://code.google.com/p/mdv/source/browse/use_cases/tree.html
I'm not sure I fully understand how templates work, so please forgive
me if I'm butchering it, but here's how I could imagine changing that
example:
=== Original ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template ref=t1 iterate=children/template
/ul
/li
/template
/ul
=== Changed ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template-reference ref=t1 iterate=children/template-reference
/ul
/li
/template
/ul
(Obviously you'd want a snappier name than template-reference to
reference another template element.)
I looked at the other examples in the same directory and I didn't see
any other examples of nested template declarations.
Adam
Re: [webcomponents] HTML Parsing and the template element
[This time from the right email]
On Wed, Feb 8, 2012 at 2:10 PM, Adam Barth w...@adambarth.com wrote:
Re-using the generic raw text element parsing algorithm would be the
simplest change to the parser. Do you have a concrete example of
where nested template declarations are required? For example,
rather than including nested templates, you might instead consider
referencing other template elements by id.
Referencing templates rather than including sub-templates inline is
certainly a solution. In fact, it's a common feature of templating
systems. It's useful when a single component is used in multiple
disparate or random places throughout the page.
However, it's worth backing up here and thinking about what templating is.
Templating is about convenience and maintainability of pages -- Not
about any core capability. Templating is useful and near ubiquitous
because it makes it easy to think about authoring your page.
Web pages are highly complex and often deeply nested repeating tree
structures. You can certainly de-construct the page into some sort of
templating-4th-normal-form and dump each component at the top level
of the document.
However, doing this abandons the largely coherent structure of
template, e.g. where table rows are defined in the context of the
table in which they are used, etc... -- which is sort of the idea of
templating -- that you get to describe your page in more or less the
way that it will be rendered.
Adam
On Wed, Feb 8, 2012 at 2:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
Hello folks!
You may be familiar with the work around the template element, or a
way to declare document fragments in HTML (see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033868.html
for some background).
In trying to understand how this newfangled beast would work, I
started researching HTML parsing, and--oh boy was I ever sorry! Err..
I mean.. --and investigating how the contents of the template
element could be parsed.
So far, I have two ideas. Both introduce changes to HTML parsing
algorithm. Both have flaws, and I thought the best thing to do would
be to share the data with the experts and seek their opinions. Those
of you cc'd -- you're the designated experts :)
== IDEA 1: Keep template contents parsing in the tokenizer ==
PRO: if we could come up with a way to perceive the stuff between
template and /template as a character stream, we enable a set of
use cases where the template contents does not need to be a complete
HTML subtree. For example, I could define a template that sets up a
start of a table, then a few that provide repetition patterns for
rows/cells, and then one to close out a table:
template id=headtablecaptionNyan-nyan/captionthead ...
tbody/template
template id=rowtrtemplatetd ... /td/template/tr/template
template id=foot/tbody/table/template
Then I could slam these templates together with some API and produce
an arbitrary set of tables.
PRO: Since the template contents are parsed as string, we create
opportunities for performance optimizations at the UA level. If a
bunch of templates is declared, but only a handful is used, we could
parse template contents on demand, thus reducing the churn of DOM
elements.
CON: Tokenizer needs to be really smart and will start looking a lot
like a specialized parser. At first glance, template behaves much
like a textarea -- any tags inside will just be treated as
characters. It works until you realize that templates sometimes need
to be nested. Any use case that involves building a
larger-than-one-dimensional data representation (like tables) will
involve nested templates. This makes things rather tricky. I made an
attempt of sketching this out here:
http://dvcs.w3.org/hg/webcomponents/raw-file/a28e16cc4167/spec/templates/index.html#parsing.
As you can see, this adds a largish set of new states to tokenizer.
And it is still incomplete, breaking in cases like
templatescriptalert('template is
awesome!');/script/template.
It could be argued that--while pursuing the tokenizer algorithm
perfection--we could just stop at some point of complexity and issue a
stern warning for developers to not get too crazy, because stuff will
break -- akin to including /script string in your Javascript code.
== IDEA 2: Just tweak insertion modes ==
PRO: It's a lot less intrusive to the parser -- just adjust insertion
modes to allow template tags in places where they would ordinary be
ignored or foster-parented, and add a new insertion for template
contents to let all tags in. I made a quick sketch here:
http://dvcs.w3.org/hg/webcomponents/raw-file/c96f051ca008/spec/templates/index.html#parsing
(Note: more massaging is needed to make it really work)
CON: You can't address fun partial-tree scenarios.
Which idea appeals to you? Perhaps you have better ideas? Please share.
:DG
Re: [webcomponents] HTML Parsing and the template element
Here's a real-world example, that's probably relatively simple
compared to high traffic web pages (i.e. amazon or facebook)
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/template/api_template.html?revision=120962content-type=text%2Fplain
that produces each page of the chrome extensions API doc, e.g.
http://code.google.com/chrome/extensions/contextMenus.html
This uses jstemplate. Do a search in the first link. Every time you
see jsdisplay or jsselect, think template.
On Wed, Feb 8, 2012 at 2:36 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 8, 2012 at 2:20 PM, Erik Arvidsson a...@chromium.org wrote:
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote:
... Do you have a concrete example of
where nested template declarations are required?
When working with tree like structures it is comment to use recursive
templates.
http://code.google.com/p/mdv/source/browse/use_cases/tree.html
I'm not sure I fully understand how templates work, so please forgive
me if I'm butchering it, but here's how I could imagine changing that
example:
=== Original ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template ref=t1 iterate=children/template
/ul
/li
/template
/ul
=== Changed ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template-reference ref=t1 iterate=children/template-reference
/ul
/li
/template
/ul
(Obviously you'd want a snappier name than template-reference to
reference another template element.)
I looked at the other examples in the same directory and I didn't see
any other examples of nested template declarations.
Adam
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 2:41 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 8, 2012 at 2:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == PRO: if we could come up with a way to perceive the stuff between template and /template as a character stream, we enable a set of use cases where the template contents does not need to be a complete HTML subtree. For example, I could define a template that sets up a start of a table, then a few that provide repetition patterns for rows/cells, and then one to close out a table: template id=headtablecaptionNyan-nyan/captionthead ... tbody/template template id=rowtrtemplatetd ... /td/template/tr/template template id=foot/tbody/table/template Then I could slam these templates together with some API and produce an arbitrary set of tables. But that could be done in the second approach as well, right? All you need to do is replace ... by span class=placeholder/span and you can replace that element later by some API. I am not sure I understand what you're saying here, so I'll try to clarify the example. The first and last templates contain incomplete tag structures (or partial trees as I call them later--not sure what the term is): the first only contains the opening table and tbody tags, and the last one closes them. Unless you treat template contents as a string, you can't create a corresponding DOM tree for just the first or just the last template. CON: Tokenizer needs to be really smart and will start looking a lot like a specialized parser. At first glance, template behaves much like a textarea -- any tags inside will just be treated as characters. It works until you realize that templates sometimes need to be nested. Any use case that involves building a larger-than-one-dimensional data representation (like tables) will involve nested templates. I think we should first discuss and agree on whether we want nested template elements or not, and how it should behave. Ok, sounds good. Rafael and Erik have done a lot of research in this area. They are more than qualified to answer this question. It could be argued that--while pursuing the tokenizer algorithm perfection--we could just stop at some point of complexity and issue a stern warning for developers to not get too crazy, because stuff will break -- akin to including /script string in your Javascript code. I don't think we want to introduce a new variant of /script. It's way too complicated as is. PRO: It's a lot less intrusive to the parser -- just adjust insertion modes to allow template tags in places where they would ordinary be ignored or foster-parented, and add a new insertion for template contents to let all tags in. I made a quick sketch here: http://dvcs.w3.org/hg/webcomponents/raw-file/c96f051ca008/spec/templates/index.html#parsing (Note: more massaging is needed to make it really work) CON: You can't address fun partial-tree scenarios. Could you elaborate on this point? This approach seems much more manageable to implement and will have much less surprising behaviors. That was referring to the stuff I just explained above. - Ryosuke
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 2:47 PM, Rafael Weinstein rafa...@chromium.org wrote:
Here's a real-world example, that's probably relatively simple
compared to high traffic web pages (i.e. amazon or facebook)
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/template/api_template.html?revision=120962content-type=text%2Fplain
that produces each page of the chrome extensions API doc, e.g.
http://code.google.com/chrome/extensions/contextMenus.html
This uses jstemplate. Do a search in the first link. Every time you
see jsdisplay or jsselect, think template.
It's a bit hard for me to understand that example because I don't know
how jstemplate works.
I'm just suggesting that rather than trying to jam a square peg
(template) into a round hole (the HTML parser), there might be a way
of reshaping both the peg and the hole into an octagon.
Adam
On Wed, Feb 8, 2012 at 2:36 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 8, 2012 at 2:20 PM, Erik Arvidsson a...@chromium.org wrote:
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote:
... Do you have a concrete example of
where nested template declarations are required?
When working with tree like structures it is comment to use recursive
templates.
http://code.google.com/p/mdv/source/browse/use_cases/tree.html
I'm not sure I fully understand how templates work, so please forgive
me if I'm butchering it, but here's how I could imagine changing that
example:
=== Original ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template ref=t1 iterate=children/template
/ul
/li
/template
/ul
=== Changed ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template-reference ref=t1 iterate=children/template-reference
/ul
/li
/template
/ul
(Obviously you'd want a snappier name than template-reference to
reference another template element.)
I looked at the other examples in the same directory and I didn't see
any other examples of nested template declarations.
Adam
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 3:16 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 8, 2012 at 2:47 PM, Rafael Weinstein rafa...@chromium.org wrote:
Here's a real-world example, that's probably relatively simple
compared to high traffic web pages (i.e. amazon or facebook)
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/template/api_template.html?revision=120962content-type=text%2Fplain
that produces each page of the chrome extensions API doc, e.g.
http://code.google.com/chrome/extensions/contextMenus.html
This uses jstemplate. Do a search in the first link. Every time you
see jsdisplay or jsselect, think template.
It's a bit hard for me to understand that example because I don't know
how jstemplate works.
Sorry. This example wasn't really meant to be understood so much as
observed for:
1) A general feel for levels of nesting.
2) That the nested components are defined where they are used.
3) How complex the templating already is, even given that templates
can be nested.
3) Imagine what this page might look like if each nested component was
pulled out and put somewhere else (possibly the top level).
I'm just suggesting that rather than trying to jam a square peg
(template) into a round hole (the HTML parser), there might be a way
of reshaping both the peg and the hole into an octagon.
I get that. Unfortunately, I'm useless on this front because I know
next to nothing about HTML parsing.
All I can offer is an opinion as to how well various declarative
semantics will address the templating use case.
Maybe the best analogy I can give is this: try to imagine if someone
proposed that C looping constructs couldn't contain a body -- only a
function call. e.g.
for (int i = 0; i count; i++) doMyThing();
You can still write all the same programs, but it'd be an
unfortunately feature to give up.
Adam
On Wed, Feb 8, 2012 at 2:36 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 8, 2012 at 2:20 PM, Erik Arvidsson a...@chromium.org wrote:
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote:
... Do you have a concrete example of
where nested template declarations are required?
When working with tree like structures it is comment to use recursive
templates.
http://code.google.com/p/mdv/source/browse/use_cases/tree.html
I'm not sure I fully understand how templates work, so please forgive
me if I'm butchering it, but here's how I could imagine changing that
example:
=== Original ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template ref=t1 iterate=children/template
/ul
/li
/template
/ul
=== Changed ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template-reference ref=t1 iterate=children/template-reference
/ul
/li
/template
/ul
(Obviously you'd want a snappier name than template-reference to
reference another template element.)
I looked at the other examples in the same directory and I didn't see
any other examples of nested template declarations.
Adam
Re: [webcomponents] HTML Parsing and the template element
Are you essentially suggesting partials? Basically, one template can
contain another only by reference? Then you have something like a
corresponding tag or macro-ish thing whereby you can reference
(functionally include) on themplate from another?
That sidesteps the whole nested template parsing pretty nicely and its what
a lot of logicless template approaches do.
On Feb 8, 2012 6:34 PM, Rafael Weinstein rafa...@google.com wrote:
On Wed, Feb 8, 2012 at 3:16 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 8, 2012 at 2:47 PM, Rafael Weinstein rafa...@chromium.org
wrote:
Here's a real-world example, that's probably relatively simple
compared to high traffic web pages (i.e. amazon or facebook)
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/template/api_template.html?revision=120962content-type=text%2Fplain
that produces each page of the chrome extensions API doc, e.g.
http://code.google.com/chrome/extensions/contextMenus.html
This uses jstemplate. Do a search in the first link. Every time you
see jsdisplay or jsselect, think template.
It's a bit hard for me to understand that example because I don't know
how jstemplate works.
Sorry. This example wasn't really meant to be understood so much as
observed for:
1) A general feel for levels of nesting.
2) That the nested components are defined where they are used.
3) How complex the templating already is, even given that templates
can be nested.
3) Imagine what this page might look like if each nested component was
pulled out and put somewhere else (possibly the top level).
I'm just suggesting that rather than trying to jam a square peg
(template) into a round hole (the HTML parser), there might be a way
of reshaping both the peg and the hole into an octagon.
I get that. Unfortunately, I'm useless on this front because I know
next to nothing about HTML parsing.
All I can offer is an opinion as to how well various declarative
semantics will address the templating use case.
Maybe the best analogy I can give is this: try to imagine if someone
proposed that C looping constructs couldn't contain a body -- only a
function call. e.g.
for (int i = 0; i count; i++) doMyThing();
You can still write all the same programs, but it'd be an
unfortunately feature to give up.
Adam
On Wed, Feb 8, 2012 at 2:36 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 8, 2012 at 2:20 PM, Erik Arvidsson a...@chromium.org
wrote:
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote:
... Do you have a concrete example of
where nested template declarations are required?
When working with tree like structures it is comment to use recursive
templates.
http://code.google.com/p/mdv/source/browse/use_cases/tree.html
I'm not sure I fully understand how templates work, so please forgive
me if I'm butchering it, but here's how I could imagine changing that
example:
=== Original ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template ref=t1 iterate=children/template
/ul
/li
/template
/ul
=== Changed ===
ul class=tree
template iterate id=t1
li class={{ children | toggle('has-children') }}{{name}}
ul
template-reference ref=t1
iterate=children/template-reference
/ul
/li
/template
/ul
(Obviously you'd want a snappier name than template-reference to
reference another template element.)
I looked at the other examples in the same directory and I didn't see
any other examples of nested template declarations.
Adam
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 5:20 PM, Brian Kardell bkard...@gmail.com wrote: Are you essentially suggesting partials? Basically, one template can contain another only by reference? Then you have something like a corresponding tag or macro-ish thing whereby you can reference (functionally include) on themplate from another? That sidesteps the whole nested template parsing pretty nicely and its what a lot of logicless template approaches do. I think that's what Adam is suggesting and Erik, Dimitri, and Rafael are advocating nested templates. - Ryosuke
Re: [webcomponents] HTML Parsing and the template element
Then why not something like template id=aworld/template template id=bhello partial with=a/template On Feb 8, 2012 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 8, 2012 at 5:20 PM, Brian Kardell bkard...@gmail.com wrote: Are you essentially suggesting partials? Basically, one template can contain another only by reference? Then you have something like a corresponding tag or macro-ish thing whereby you can reference (functionally include) on themplate from another? That sidesteps the whole nested template parsing pretty nicely and its what a lot of logicless template approaches do. I think that's what Adam is suggesting and Erik, Dimitri, and Rafael are advocating nested templates. - Ryosuke
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 7:31 PM, Brian Kardell bkard...@gmail.com wrote: Then why not something like template id=aworld/template template id=bhello partial with=a/template Right. If we were to disallow nested templates, that's the way to go. The question is whether we should disallow nested templates or not. - Ryosuke
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 8:16 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 8, 2012 at 7:31 PM, Brian Kardell bkard...@gmail.com wrote: Then why not something like template id=aworld/template template id=bhello partial with=a/template Right. If we were to disallow nested templates, that's the way to go. The question is whether we should disallow nested templates or not. Okay, I am changing my mind. I don't think we should gate this discussion on whether nested template elements should be allowed. First, it's a very drastic design decision that will do doubt hinder the developers of templating libraries. Honestly, I wonder if we should always aim to avoid making these types of decisions at a platform level. Second, it possibly doesn't even matter. If and only if we decide that the contents of template element MUST be perceived as a string--not a DOM subtree--will we face the question of disallowing nested templates. As demonstrated in IDEA 2, we can still totally still produce usable--nested or not--inert chunks of DOM, per initial requirements. So I think we should get back to answering the question: is it crucial that template contents are parsed as a character stream? From there, we can walk either toward puzzling over nested templates or just moving along, nothing to see here. :DG - Ryosuke
Re: [webcomponents] HTML Parsing and the template element
On Thu, Feb 9, 2012 at 13:45, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Feb 8, 2012 at 8:16 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 8, 2012 at 7:31 PM, Brian Kardell bkard...@gmail.com wrote: Then why not something like template id=aworld/template template id=bhello partial with=a/template Right. If we were to disallow nested templates, that's the way to go. The question is whether we should disallow nested templates or not. Okay, I am changing my mind. I don't think we should gate this discussion on whether nested template elements should be allowed. First, it's a very drastic design decision that will do doubt hinder the developers of templating libraries. Honestly, I wonder if we should always aim to avoid making these types of decisions at a platform level. Second, it possibly doesn't even matter. If and only if we decide that the contents of template element MUST be perceived as a string--not a DOM subtree--will we face the question of disallowing nested templates. As demonstrated in IDEA 2, we can still totally still produce usable--nested or not--inert chunks of DOM, per initial requirements. So I think we should get back to answering the question: is it crucial that template contents are parsed as a character stream? From there, we can walk either toward puzzling over nested templates or just moving along, nothing to see here. In my experience, things like asymmetrical templates (e.g., containing an opening tag only) look very useful at first, but turn out to cause more headaches than they are worth in the long run. E.g., causing ugly errors when you instantiate a start template, but not an end template, or even simply the point of time between instantiating the start and the end. You cannot clone such a template's content, etc. To raise another facet (and please excuse if this has already been discussed and settled): Do we want to be able to manipulate the contents of a template via JS? This would seem more useful to me than character streams. I remember good arguments pro and contra on this a while back. Cheers, - Roland
Re: [webcomponents] HTML Parsing and the template element
On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == Not this! Here's why: Making something look like markup but then not tokenizing it as markup is confusing. The confusion leads to authors not having a clear mental model of what's going on and where stuff ends. Trying to make things just work for authors leads to even more confusing here be dragons solutions. Check out http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state Making something that looks like markup but isn't tokenized as markup also makes the delta between HTML and XHTML greater. Some people may be ready to throw XHTML under the bus completely at this point, but this also goes back to the confusion point. Apart from namespaces, the mental model you can teach for XML is remarkably sane. Whenever HTML deviates from it, it's a complication in the understandability of HTML. Also, multi-level parsing is in principle bad for perf. (How bad really? Dunno.) I *really* don't want to end up writing a single-pass parser that has to be black-box indishtinguishable from something that's defined as a multi-pass parser. (There might be a longer essay about how this sucks in the public-html archives, since the SVG WG proposed something like this at one point, too.) == IDEA 2: Just tweak insertion modes == I think a DWIM insertion mode that switches to another mode and reprocesses the token upon the first start tag token *without* trying to return to the DWIM insertion mode when the matching end tag is seen for the start tag that switched away from the DWIM mode is something that might be worth pursuing. If we do it, I think we should make it work for a fragment parsing API that doesn't require context beyound assuming HTML, too. (I think we shouldn't try to take the DWIM so far that a contextless API would try to guess HTML vs. SVG vs. MathML.) The violation of the Degrade Gracefully principle and tearing the parser spec open right when everybody converged on the spec worry me, though. I'm still hoping for a design that doesn't require parser changes at all and that doesn't blow up in legacy browsers (even better if the results in legacy browsers were sane enough to serve as input for a polyfill). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
