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 09:59:47 -0700
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "olli@pettay.fi" <olli@pettay.fi>
CC: Webapps <public-webapps@w3.org>
Message-ID: <0003CB8B8FE2154EB50431DB2B8F69C00EB1303421@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

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)?

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Daniel Glazman
Sent: Wednesday, August 13, 2008 9:57 AM
To: olli@pettay.fi
Cc: Webapps
Subject: Re: comment on Element Traversal Spec

Olli Pettay wrote:

> On all nodes? Doesn't make sense to have nextElementSibling on a
> #document or #attribute or
> #documentFragments etc.
> Perhaps those could be available on #text nodes, though, even in that
> case when node is under
> attribute, next/previousElementSibling would be a bit strange.

To be precise, I would like to have these on

   EntityReference, Element, ProcessingInstruction, Comment,
   Text, CDATASection, Entity, Notation

Of course, you're right, it does not make real sense on Document,
DocumentFragment, DocumentType and Attr. But we could fire an
exception or reply null.

Received on Wednesday, 13 August 2008 17:00:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC