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

RE: comment on Element Traversal Spec

From: Travis Leithead <travil@windows.microsoft.com>
Date: Wed, 13 Aug 2008 10:14:56 -0700
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
CC: "olli@pettay.fi" <olli@pettay.fi>, Webapps <public-webapps@w3.org>
Message-ID: <0003CB8B8FE2154EB50431DB2B8F69C00EB1303444@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

Ah, I think I see now.

You don't want the nextElementSibling API to _return_ non-elements, you just want the nextElementSibling to be available on all nodes so that no matter where you land in the DOM, you can always get to the next element. Gotcha.

-----Original Message-----
From: Daniel Glazman [mailto:daniel.glazman@disruptive-innovations.com]
Sent: Wednesday, August 13, 2008 10:05 AM
To: Travis Leithead
Cc: olli@pettay.fi; Webapps
Subject: Re: comment on Element Traversal Spec

Travis Leithead wrote:
> I thought that Node.nextSibling / previousSibling work this way? Isn't the whole reason for ElementTraversal to explicitly do element navigation only (a use case that nextSibling/previousSibling made more complicated for web developers)?

Having nextElementSibling available on Text and other nodes
will provide a great replacement for a code chunk the whole
web and JS chrome is full of :

   while (node && node.nodeType != Node.ELEMENT_NODE)
     node = node.nextSibling;

</Daniel>
Received on Wednesday, 13 August 2008 17:15:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT