Re: Simplifying element creation

Ojan filled me in on this. I'm less negative to it now.

element.append(...pattern)  // var args of Pattern

With EBNF like definition

Pattern :
  Node
  String
  ElementPattern

ElementPattern :
 '[' TagName ( ',' Attrs? ( ',' EventHandlers? (, Pattern)* )? )? ']'

The Text production creates a Text node

The ElementPattern creates an Element with the given tag name, attribtues,
event handlers and its child nodes are provided by the rest patterns.

For example:

element.append('Hello', ['b', null, null, 'world'])

would be the same as

element.insertAdjacentHTML('beforeend', 'Hello <b>world</b>')

erik







On Tue, Oct 4, 2011 at 16:48, Erik Arvidsson <arv@chromium.org> wrote:

> Others have pointed this out put I find it very confusing that a
> string is not treated as Text node in all cases.
>
> I don't believe append should be responsible for creating new Elements.
>
> erik
>
>
>
>
>
>
>
>
> On Tue, Oct 4, 2011 at 16:28, Roland Steiner <rolandsteiner@google.com>
> wrote:
> > On Tue, Oct 4, 2011 at 6:18 PM, Dominic Cooney <dominicc@chromium.org>
> > wrote:
> >>
> >> On Tue, Oct 4, 2011 at 5:30 PM, Anne van Kesteren <annevk@opera.com>
> >> wrote:
> >> > E.g. <div>Hello <a href="/">World</a></div> is represented as:
> >> >
> >> >  ["div", "Hello ", ["a", {href:"/"}, "World"]]
> >>
> >> I think readability suffers a bit because element names and text are
> >> both strings.
> >
> > It also invites errors, e.g., ["style", "scoped"] (missing curly
> brackets)
> > But I think it's worse than just readability:
> > .) you cannot have text nodes that contain a string that could be an
> element
> > name, e.g., ["dl", ["dt", "object"], ["dd', "the base class of the type
> > hierarchy"]].
> > .) later on you cannot introduce new HTML elements, because someone might
> > have used that element's name as a text string with the above syntax.
> >
> > Cheers,
> > - Roland
> >
>