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
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
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
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
(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:
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
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
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
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
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:
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
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
* 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
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
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
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()
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
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
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:
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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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:
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
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:
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
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
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
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
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
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
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
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
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.
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
[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
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
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
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)
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)
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
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
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
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
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,
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
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
82 matches
Mail list logo
