Re: Simplifying element creation

On Tue, Oct 4, 2011 at 03:52, James Graham <jgraham@opera.com> wrote:
> On Tue 04 Oct 2011 11:18:18 AM CEST, Dominic Cooney 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? 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"]]
>>
>> 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.
>
> You can use Element.append.apply. It's not wonderful but it's OK I think.

And with ES6 spread it becomes even easier.

element.append(...myArrayLikeObject)

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

>> What about using constructor functions for elements? [HTMLDivElement,
>> 'Hello ', [HTMLAElement, {href: '/'}, 'World']].
>
> That doesn't work because they're not constructor functions; they're
> interface objects and multiple elements can have the same interface
> (HTMLHeadingElement for example).

Call them what you will but they are defined and exposed to JS.

That they are not constructable is a bug which there are plenty of
centi threads about.

-- 
erik

Received on Tuesday, 4 October 2011 18:29:39 UTC