Re: Simplifying element creation

On Wed, Oct 5, 2011 at 9:39 AM, Ojan Vafai <ojan@chromium.org> wrote:
> 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

My point was just that having the same representation for node lists
and elements could lead to mode errors where someone splats when they
should not, etc. It would be nice if there was something extant in the
array that indicated intent. I know some constructors map to multiple
elements, but having some different type of object there lets you
write:

if (x instanceof Array && x.length && x[0] instanceof Function) {
  // it is an element
} else {
  // it is a node list
}

Verbose, yes. But does not rely on heuristics (in the tag names are
strings case, what if someone wanted to insert the text 'div'?)

>> 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() {}}]);

Functions are not generally serializable. I guess we only care about
deserialization.

>> > 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/
>> >
>> >
>>
>
>

Received on Wednesday, 5 October 2011 02:46:52 UTC