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

Re: Simplifying element creation

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 6 Oct 2011 14:14:57 -0700
Message-ID: <CA+c2ei8FDwkc8a-CcpfuVOcNJqAqFrP3FwZvPryeg1dW0MYKiw@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
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.

/ Jonas
Received on Thursday, 6 October 2011 21:15:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT