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

On Thu, May 10, 2012 at 5:13 PM, Rafael Weinstein <rafaelw@google.com>wrote:

> On Thu, May 10, 2012 at 4:58 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 10 May 2012, Rafael Weinstein wrote:
> >>
> >> Also, I'm curious why it's ok to peak at the first few characters of the
> >> string, and not ok to peak at the token stream until we see the first
> >> start tag?
> >
> > Because it's predictable and easy to debug. When you're dealing with a
> > weird effect caused by some accidental markup hundreds of lines down a
> > string, it's really hard to work out what's going on. When the effect is
> > caused by the very first thing in the string, it's much easier to notice
> > it. (You see this kind problem sometimes on Web pages where text/plain
> > files are sent as text/html, or text files are slightly augmented with
> > HTML without properly escaping everything -- they render fine until they
> > get to something that accidentally looks like markup, and the parser does
> > its stuff, and you wonder why half of the 100-page document is bold.)
>
> In the abstract, I actually agree with you, but this happens to be a
> case when this is effectively never going to be a problem. Just have a
> look at *any* templating langauge. Any time you see some kind of
> conditional, or loop construct, look at it's contents and imagine that
> that's what'll be passed to innerHTML here.
>
> 99.9% of the time it's going to either be all character tokens, or
> whitespace followed by a start tag.
>
> You're letting an non-existent problem kill a perfectly useful proposal.
>
> I'm not a huge fan of everything jQuery does either, but regardless of
> it's objective "goodness", it has already done the test by offering
> this functionality. The kind of bug your describing hasn't been
> observed at all. Someone with more jQuery-cred correct me if I'm
> wrong.


I think our best final solution is something roughly like
http://wiki.ecmascript.org/doku.php?id=harmony:quasis. Look at safehtml as
an example. If browsers provide that method, that strikes the best balance
of security and convenience.

That said, innerHTML is here. That it doesn't work on DocumentFragment just
makes people have to use dummy container elements and write less efficient
code. I don't think implementing this will have any effect on whether
people will use our eventual safehtml solution. In the interim, it's just
confusing and clunky that innerHTML works everywhere except
DocumentFragment. IMO it should work on Document as well.

As a web developer who has done a lot of work with both Element.create
style APIs and with jQuery string-based APIs, it's really much more of a
pleasure to use the latter. It makes for much more concise and readable
code. Those benefits are high enough that it justifies the clunkiness and
the need to be XSS-careful.

Template element has none of the issues of horrifying string-based
approaches and is only related to this discussion in that it needs
context-free parsing.

Ojan