Re: Simplifying element creation

https://gist.github.com/1268805

erik







On Thu, Oct 6, 2011 at 14:29, Erik Arvidsson <arv@chromium.org> wrote:

> 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.
>
> --
> erik
>