- From: Rafael Weinstein <rafaelw@google.com>
- Date: Fri, 11 May 2012 12:14:22 -0700
- To: Webapps WG <public-webapps@w3.org>
- Cc: Henri Sivonen <hsivonen@iki.fi>, "Tab Atkins Jr." <jackalmage@gmail.com>, Yehuda Katz <wycats@gmail.com>, Scott González <scott.gonzalez@gmail.com>
Ok, so I have some preferences, but they are *mild* preferences and any permutation of the options below is acceptable to me. On Fri, May 11, 2012 at 12:04 PM, Rafael Weinstein <rafaelw@google.com> wrote: > Ok, > > So from the previous threads, there are appear to be three issues to > resolve, and I'll list the options that I've noted. > > I'll follow up with my perspective of pros/cons and ask others to do > the same. Please point out options or issues that I've missed. > > -------- > Issue 1: How to handle tokens which precede the first start tag > > Options: > a) Queue them, and then later run them through tree construction once > the implied context element has been picked I like option (a) because you always get identical output for any input relative to if you had applied it via innerHTML to the appropriate implied context element. E.g. myHTMLElement.innerHTML = "foo<body>bar"; myDocumentFragment.innerHTML = "foo<body>bar"; myHTMLElement.innerHTML == myDocumentFragment.innerHTML; // true; Also, most browsers are already speculatively tokenizing ahead for resource preloading purposes, so the implementation complexity isn't especially daunting. > > b) Create a new insertion like "waiting for context element", which > probably ignores end tags and doctype and inserts character tokens and > comments. Once the implied context element is picked, reset the > insertion mode appropriately, and procede normally. > > > ------- > Issue 2: How to infer a non-HTML implied context element > > Options: > a) By tagName alone. When multiple namespaces match, prefer HTML, and > then either SVG or MathML (possibly on a per-tagName basis) > > b) Also inspect attributes for tagNames which may be in multiple namespaces > > c) Allow for inline name spacing of elements which would normally > inherit the proper namespace from <svg> or <math> > > d) Somewhat orthogonal, but later allow for <template> to have an > optional context attribute (e.g. <template context="svg">), which > explicitly picks a context element. > > e) Some combination of the above. I have a mild preference for not getting to fancy here. I'll mostly stay out of this and let those who know more about SVG and MathML sort it out, but I'll just note that the main concern cited for needing this to work is with web components, and there I think Hixie's idea of a declarative context element (e.g. option (d)) above is a nice addition and might alleviate the need to get fancy. > > ------- > Issue 3: What form does the API take > > a) Document.innerHTML > > b) document.parse() > > c) document.createDocumentFragment() I'm torn here between (a) & (b). I like the familiarity of (a), but agree with Henri's point of about the namespace of the owner document being a downside. I don't like (c) for stylistic reasons.
Received on Friday, 11 May 2012 19:14:52 UTC