Re: Simplifying element creation

On 7/10/11 9:00 AM, Erik Arvidsson wrote:
> https://gist.github.com/1268805
>
> erik
>
>
>
>
>
>
>
> On Thu, Oct 6, 2011 at 14:29, Erik Arvidsson <arv@chromium.org 
> <mailto: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 <mailto: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.
>

I'm glad that at least you've dispensed with the event-listeners part of 
the proposal.

Sean