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

Re: Review of the <template> spec

From: Rafael Weinstein <rafaelw@google.com>
Date: Fri, 21 Dec 2012 12:35:53 -0800
Message-ID: <CABMdHiRyWnybDfUZz_osVG3qzaem-Vdc9ezyXj43PdB7dszvvQ@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-webapps WG <public-webapps@w3.org>
Thanks for reviewing this (and sorry for the delay -- I was on vacation,
and blissfully unable to read email).

I'm happy (and a little surprised) that there's no comment here about the
HTML parser changes. Is that because it all looks good, or because you
didn't dig that deep into it yet?

The XML/XSLT/XDM stuff is missing only because we didn't have time to get
to it yet. It's next on my priority list now that I'm back. The spec bugs
for describing the additional semantics are included inline below.

Also, FYI: Although we've landed code for the current spec in WebKit and
Chrome Canary, it's behind a compile flag, only enabled for the Chromium
port and will not go to beta or release until the spec is reasonably
settled (including the XML/XSLT/XDM stuff).

On Tue, Dec 11, 2012 at 5:00 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

> I reviewed
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template
> . Sorry about the delay.
>
> Comments:
>
> XML parsing isnít covered. (Should have the wormhole per the
> discussion at TPAC.)


https://www.w3.org/Bugs/Public/show_bug.cgi?id=19889


>


> XSLT output isnít covered. (When an XSLT program trying to generate a
> template element with children, the children should go through the
> wormhole.)


> Interaction with the DOM to XDM mapping isnít covered per discussion
> at TPAC. (Expected template contents not to appear in the XDM when
> invoking the XPath DOM API (for consistency with querySelectorAll) but
> expected them to appear in the XDM when an XSLT transformation is
> being processed (to avoid precluding use cases).)
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20483


>
> > 1. If DOCUMENT does not have a browsing context, Let TEMPLATE CONTENTS
> OWNER be DOCUMENT and abort these steps.
> > 2. Otherwise, Let TEMPLATE CONTENTS OWNER be a new Document node that
> does not have a browsing context.
>
> Is there a big win from this inconsistency? Why not always have a
> separate doc as the template contents owner?
>
> Do we trust the platform never to introduce a way to plant a document
> that does not have a browsing context into a browsing context?
> (Unlikely, but do we really want to make the bet?)



>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
Received on Friday, 21 December 2012 20:36:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:56 GMT