Re: [webcomponents] More backward-compatible templates

On Wed, Oct 31, 2012 at 2:45 PM, Adam Barth <w3c@adambarth.com> wrote:
> 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
> examples.
>
> 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.
>
> Adam
>

If there were a defined partials mechanism with idref you could get
around this.  Most templating systems have this sort of thing for this
same reason.  Right?  Then nesting is a non-problem and it could be
shimmed too.  Personally, I think templates should include that
anyway, but I've not heard a lot of support for that when I mentioned
it before.

Received on Wednesday, 31 October 2012 19:33:05 UTC