Re: Special group of functions for NON-ELEMENT nodes in document

Matt Dockerty wrote:
>
> I agree that the specification leaves too much room for
> maneuverability. Reading this, my mind immediately jumped to the
> whitespace nodes that developers dislike in Firefox. Currently, a call
> to node.firstChild can return the first 'tag' child node, or a text
> node containing a carriage return, with the same document but a
> different implementation of the DOM.
>
> The Firefox discussion is here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=26179
>
> I'm not automatically agreeing with your solution but I would welcome
> a discussion on this list since I don't fully understand the issues.
> Why is whitespace an optional part of a DOM tree, and on what grounds
> would an implementation make the choice to keep or discard them? Also,
> has anything been done or will anything be done to ensure that a DOM
> user can get consistent results regardless of implementation?
>
> Best,
> Matt
Talk to browser vendors who discard it.  I worked on the code base of
Firefox, and no other.  I believe there is slack in the HTML DOM
specification allowing it to be discarded in some cases.  As long as
there is such slack, in any given year, there could be seemingly random
changes in browser behavior, with some trying to follow others who are
following something else.

Firefox is not the bad citizen here.  In my opinion, the best behavior
is to never discard whitespace.  When you start using the load and save
module with XML, I believe you have control over discarding
insignificant whitespace so you can request compatible behavior all the
time.  The DOM specification does not encourage it.  But it does not
come up as an issue that much in the HTML DOM, because people are doing
limited things and use IDs to find the nodes they want, and XML DOMs do
not discard it (unless requested as an option)  Standardization would
have to occur between browser vendors.

But anyone who serializes the result (firefox and others have some
situations where this is possible) might curse a DOM that threw away all
the whitespace because it was supposedly insignificant.

There is no possibility of just having it ignored but present during
serialization, except through something like the Level 2 Traversal API.

Any different behavior would have to be in a new API.  Good luck getting
the browser vendors to pay attention to it.  Some seem to thrive on
incompatibility, making one standard and implementing another and then
blame W3C for the incompatibilities.

There is really nothing to debate about the existing standard.  It is
what it is and the accessors see all nodes, not just elements.

.Ray Whitmer

Received on Tuesday, 26 September 2006 11:13:53 UTC