Re: Simplifying element creation

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