W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [webcomponents] More backward-compatible templates

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 31 Oct 2012 11:45:13 -0700
Message-ID: <CAJE5ia-RKVKsDM4hc42Tt6FycUBLV54xZvYPsN5rwi=XKXfW9A@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Maciej Stachowiak <mjs@apple.com>, "public-webapps@w3.org WG" <public-webapps@w3.org>
On Wed, Oct 31, 2012 at 11:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Oct 31, 2012 at 7:23 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Then maybe I don't understand how parsing will work.  How does the
>> parser know when the "Folder i" template stops?  It can't just scan
>> ahead for <\/scirpt> if we're using <\/script> to terminate the "Email
>> i" template.  Similarly, it can't just match <script> and <\/script>
>> tags because then nested templates will parse differently than
>> top-level templates...
> You'd need to special case nested templates. But you need to do that
> anyway as you're inside a <script> element that normally only emits
> character data.

I don't really understand what sort of parsing rules you're imagining.
 If you explain them concretely, I can try to provide problematic

Trying to hijack <script> for this purpose works well if you don't
need to nest templates.  Once you have nested templates, you either
end up in an escaping nightmare or you need to start hacking up how
HTML parsing works inside of <script type=template>.  If you go that
route, you're in bad shape because these hacks need to work
consistently with how <script> parses in a normal HTML parser.  As you
can tell by looking at the number of states that <script> requires in
the HTML tokenizer, that's not a simple thing.

Received on Wednesday, 31 October 2012 18:46:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC