W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: Simplifying element creation

From: Erik Arvidsson <arv@chromium.org>
Date: Thu, 6 Oct 2011 14:29:32 -0700
Message-ID: <CAJ8+Goh09VnzkDRaKpAkgUpN+wYOy3u-bGwQBBZ-hqEp6zfuTQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@opera.com>, "www-dom@w3.org" <www-dom@w3.org>
On Thu, Oct 6, 2011 at 14:14, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Oct 6, 2011 at 1:46 AM, Anne van Kesteren <annevk@opera.com>
> wrote:
> > On Thu, 06 Oct 2011 00:51:09 +0200, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>
> >> It sounds to me like we're creating a JSON format for the DOM and
> >> making element.append accept the JSON format. This doesn't sound great
> >> to me. It basically sounds like too high level to fit enough use
> >> cases.
> >
> > How it too high-level? Inserting elements and text nodes is the 80/20 of
> the
> > DOM. And providing a viable simple alternative to innerHTML seems like a
> > major win.
> >
> >> It seems better to have an API for creating a single element (with
> >> attributes and event handlers), and then let people combine calls to
> >> that to do their own JSON->DOM conversion.
> >>
> >> Possibly it would make sense for the function to take an additional
> >> string-argument is used to create a text node which is inserted as a
> >> child. But I don't think we should add complexity in the form of
> >> sometimes interpreting that string as a node-name and sometimes as a
> >> textnode value.
> >
> > I'm not sure what complexity you see. The first argument of the array
> sets
> > the local name, later arguments set its children (which can in turn be
> other
> > arrays). To allow multiple elements to be inserted we will use varargs.
> I don't like the varargs approach. It makes it a much less appealing
> alternative to innerHTML. Today you can do something like:
> x = someFunc();
> mynode.innerHTML = x;
> A similar flow doesn't work with any of the proposals. In fact, the
> varargs approach seems to only work if you are typing the whole DOM in
> the function call. Basically the equivalent of only allowing innerHTML
> to take string literals, as opposed to any expression that returns
> something that can be converted to a string.
> I wouldn't really say that this meets the 80% requirement. I.e. I
> think more than 20% of the innerHTML uses out there use something
> other than a string literal.
> You can work around this using the Function.call function, however
> that's very error prone, especially with varargs this complex (as
> opposed to for example Array.concat where all arguments have the same
> meaning).
> Additionally, as has been pointed out elsewhere. It seems like a very
> bad idea for a string argument to either be interpreted as a text-node
> value or as a tag name. It seems very likely to cause mistakes where
> people want to display strings that happen to match a HTML tag name.
> It's also not very future proof since it'll make it harder to
> introduce new element names.
> In fact, I'd even call it a security problem since people could end up
> creating <script> elements, when they intend to display the string
> "script" in a page.

There seems to be some confusion going around here. The value of the string
does not matter.

I'll write a JS shim so that people can get a clearer picture of what the
semantics is.

Received on Thursday, 6 October 2011 21:30:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:59 UTC