W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Element.create(): a proposal for more convenient element creation

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 1 Aug 2011 21:19:02 -0700
Message-ID: <CAAWBYDDtwPVmA8L8ZhRys_PjUNUxq8A2T5jPfOW18FMjNatikg@mail.gmail.com>
To: João Eiras <joao.eiras@gmail.com>
Cc: WebApps WG <public-webapps@w3.org>
On Mon, Aug 1, 2011 at 8:52 PM, João Eiras <joao.eiras@gmail.com> wrote:
> On , Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard <chuck@jumis.com> wrote:
>>> Can we have it 'inherit' a parent namespace, and have chaining
>>> properties?
>>> Element.create('div').create('svg').create('g').create('rect', {title:
>>> 'An svg rectangle in an HTML div'});
>> Ooh, so .create is defined both on Element (defaults to HTML
>> namespace, just creates an element) and on Element.prototype (defaults
>> to namespace of the element, inserts as a child)?  That's pretty
>> interesting.  Presumably the new element gets inserted as a last child
>> of the parent.
>> I like it.
> While the idea is interesting, "create" is a too simple name to add on
> something as polluted as Element.
> I wonder if there is enough demand for this kind of chained coding to
> actually spec an API for this. I've rarely seen it being used, plus the
> notable exception that is jquery code.
> Perhaps createChild, would be better, but then one would need to
> differentiate Elements from Text.

createChild works for me too.  The important part is the chaining; it
makes it slightly terser and easier to read than nesting
Element.create() calls.

Received on Tuesday, 2 August 2011 04:19:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC