Re: Some thoughts on DOM 2.0, Simpler

Hi Jeff.

Jeff Schiller:
> As a developer, I'd be very much in favor of an E4X-like solution to
> creating elements (as evidenced by my DOMParser hack on the mailing
> list).

HTML 5 defines innerHTML to work on XML documents (where assigning to it
would parse the string parameter as XML, predeclaring any namespaces
that are available on the element).  I’m not sure if this applies to all
XML documents supported by the UA (like when showing a standalone SVG
document) or just XHTML documents.

> JSON also feels like a hack and (as mentioned on the wiki)
> creating nested elements would be painful and bring back shades of
> LISP-like brace counting.

Agreed, although I have been known to do similar things, like:

  function t(s) {
    return document.createTextNode(s);
  }

  function e(n, a) {
    var e = document.createElementNS(…, n);
    for (var p in a) {
      e.setAttribute(p, a[p]);
    }
    for (var i = 2; i < arguments.length; i++) {
      e.appendChild(arguments[i]);
    }
    return e;
  }

  e('svg',
    { viewBox: '0 0 400 400' },
    e('g',
      { transform: 'scale(2)' },
      e('text',
        { x: 100, y: 100, fill: 'red' },
        t('hi there'))));

Counting parens does suck though. :)

> In general I hate having to create languages using other
> language/syntax (PHP to create HTML/SVG is another example of this).
> 
> Speaking of creating child elements, I saw mention of a way to create
> and automatically insert an element in the DOM.  While this might seem
> good, if I wanted to create an animated Rect I'd probably have to
> create and insert the rect first, then create and insert the various
> animate child elements.  Each of these insertions into the DOM would
> take extra time.  Also, wouldn't they cause mutation events to fire or
> something?

I suppose you could use the create-and-don’t-insert one for the top
element in the subtree you are creating, and create-and-insert for the
descendants.  Then at the end you could manually insert the top one.

With methods that took parameters for child nodes, like the functions
above, you could avoid this problem.  But then there’s the matching
paren issue.

Personally, on the face of it, I like the idea of having “painting”
methods on container elements:

  g = /* get some <g> element */;
  g.drawCircle(100, 50, 50, { fill: 'red' });

Another wild idea: have the per-element interface objects also be
constructors:

  g = new SVGGElement();
  c = new SVGCircleElement(100, 50, 50, { fill: 'red' });
  g.appendChild(c);

where the constructors effectively do a document.createElementNS().

> Seems like it's better to allow the author to create his subtree all
> in JS and then push into the DOM with one call.

I think that is good practice in general, to avoid wasted processing.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 27 July 2009 03:43:05 UTC