- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 5 Oct 2011 15:51:09 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
On Tue, Oct 4, 2011 at 1:30 AM, 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"]]
>
> 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.
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.
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.
/ Jonas
/ Jonas
Received on Wednesday, 5 October 2011 22:52:18 UTC