W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 11 May 2012 11:55:27 +0300
Message-ID: <CAJQvAuecyPFmEZ_Kc4PasxG6DdkqnChXmzqMLM_Q3=mf63mN0Q@mail.gmail.com>
To: Rafael Weinstein <rafaelw@google.com>
Cc: Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein <rafaelw@google.com> wrote:
> I'm very much of a like mike with Henri here, in that I'm frustrated
> with the situation we're currently in WRT SVG & MathML & parsing
> foreign content in HTML, etc... In particular, I'm tempted to feel
> like SVG and MathML made this bed for themselves and they should now
> have to sleep in it.

I think that characterization is unfair to MathML.  The math working
group tried hard to avoid local name collisions with HTML.  They
didn't want to play namespace games.  As I understand it, they were
forced into a different namespace by W3C strategy tax arising from the
"NAMESPACE ALL THE THINGS!" attitude.

SVG is the language that introduced collisions with both HTML and
MathML and threw unconventional camel casing into the mix.

On Fri, May 11, 2012 at 1:44 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> The innerHTML API is convenient.  It lets you set the entire
> descendant tree of an element, creating elements and giving them
> attributes, in a single call, using the same syntax you'd use if you
> were writing it in HTML (module some extra quote-escaping maybe).

I'm less worried about magic in an API that's meant for representing
tree literals in JavaScript as a sort of E4H without changing the
JavaScript itself than I am about magic in APIs that are meant for
parsing arbitrary potentially user-supplied content.

If we are designing an API for the former case rather than the latter
case, I'm OK with the following magic:
 * Up until the first start tag parser behaves as in "in body" (Tough
luck if you want to use <![CDATA[  or U+0000 before the first tag,
though I could be convinced that the parser should start in a mode
that enables <![CDATA[.)
 * if the first start tag is any MathML 3 element name except "set" or
"image", start behaving as if setting innerHTML on <math> (details of
that TBD) before processing the start tag token further and then
continue to behave like when setting innerHTML on <math>.
 * otherwise, if the first start tag is any SVG 1.1 element name
except "script", "style", "font" or "a", start behaving as if setting
innerHTML on <svg> (details of that TBD) before processing the start
tag token further and then continue to behave like when setting
innerHTML on <svg>.
 * otherwise, set the insertion mode per HTML-centric <template> rules
proposed so far.

Open question: Should it be possible to use a magic attribute on the
first tag token to disambiguate it as MathML or SVG? xmlns="..." would
be an obvious disambiguator, but the values are unwieldy.  Should
xlink:href be used as a disambiguator for <a>? If the use case is
putting tree literals in code, it probably doesn't make sense to use
<script> or <style> (either HTML or SVG) in that kind of context
anyway. And SVG <font> has been rejected by Mozilla and Microsoft
anyway.

I still think that having to create a DocumentFragment first and then
set innerHTML on it is inconvenient and we should have a method on
document that takes a string to parse and returns the resulting
DocumentFragment, e.g. document.parse(string) to keep it short.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Friday, 11 May 2012 08:55:57 GMT

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