Re: Simplifying element creation

On Tue, Oct 4, 2011 at 2:18 AM, Dominic Cooney <dominicc@chromium.org>wrote:

> On Tue, Oct 4, 2011 at 5:30 PM, Anne van Kesteren <annevk@opera.com>
> wrote:
> > So far we discussed having Element.create() and having new methods on
> Node
> > that would be more practical than what we have today. Maybe we should
> > combine these in some way?
>

I think that there is still benefit in having the create method in addition
to all the methods I proposed on the other thread. Having them all accept
the same argument type makes total sense to me.


> Charles proposed some kind of JSON serialization,
> > but I do not think it makes sense to tie it to JSON.
> >
> > It could be something like this:
> >
> > ELEMENT = [NAME, optional ATTRS, optional EVENT_HANDLERS, TEXT | ELEMENT
> > ...]
> >
> > E.g. <div>Hello <a href="/">World</a></div> is represented as:
> >
> >  ["div", "Hello ", ["a", {href:"/"}, "World"]]
>

Overall, I like it. I'd want to also allow the following types for the "TEXT
| ELEMENT" value:
-Nodes
-Numbers
-Null
-Undefined
-Booleans

Given ES6 spread, I don't think we need to allow NodeList or Array. Not
allowing arrays also means we avoid the issue that Roland brought up because
the first string in any array is an element name and not text and only the
first string in an array is an element name.

For example:
foo.append('div'); // appends the string 'div' to foo as a text node
foo.append(['div']); // appends a div element to foo

This is good in that it doesn't require any new bound identifiers.
>
> I think readability suffers a bit because element names and text are
> both strings.
>
> If you want to pass a list of children as a parameter, there is also
> no good serialization for it. Using a list is weak because it is the
> same type as an element.
>
> What about using constructor functions for elements? [HTMLDivElement,
> 'Hello ', [HTMLAElement, {href: '/'}, 'World']].
>

While I agree that this is more readable, it adds sufficient verbosity that
it significantly hampers the benefits of this API. A site can reduce the
verbosity of this or improve the readability of Anne's proposal by having
global variables (e.g. DIV='div' or DIV=HtmlDivElement).

Another advantage of using strings is that this is network serializable.
With the format being network serializable you can imagine this becoming the
fastest way to generate a DOM. Rather than sending HTML over the wire, you
mostly send this format. In theory, the browser can create this DOM faster
than parsing HTML.

On the topic of network serializability, the attributes object is
string-->string, so it's clearly serializable. What is the format for the
events object? Is it string-->string or string-->function? I propose it be
string-->(string | function). So the following is valid:

Element.create(['div', {}, {'onclick': 'return false;', 'onmousedown':
function() {}}]);

> Then the new methods we introduce could accept the above syntax to make it
> > easier to append new elements to the DOM.
> >
> >  ele.append(['div'])
> >
> > would append a <div> element. If you want to append several elements, you
> > would use
> >
> >  ele.append("Hello ", ["i", "World"])
> >
> > I.e. append() takes "infinite" arguments.
> >
> >
> > --
> > Anne van Kesteren
> > http://annevankesteren.nl/
> >
> >
>
>