W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2006

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

From: Matt Dockerty <news@nistrum.co.uk>
Date: Tue, 26 Sep 2006 15:47:18 +0100
Message-Id: <074B2425-5A7E-4157-84E4-16BB594C87F1@nistrum.co.uk>
Cc: www-dom@w3.org
To: Ray David Whitmer <ray@jhax.net>

On 26 Sep 2006, at 12:13, Ray David Whitmer wrote:

> 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.

Agreed. I think the slack has to be tightened because users can  
currently (inadvertently or otherwise) write non-portable, yet valid,  
DOM programs.

> Firefox is not the bad citizen here.

I wouldn't suggest there was a bad citizen. Everybody is doing a good  
job, but still there are some inconsistencies that could use ironing  

>   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.

normalizeDocument or normalize() seemed like the perfect answer but  
calling it crashes Internet Explorer 6 immediately meaning it's use  
on real Web pages is out, until IE6 is out of the picture anyway.

>   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.

Taking something common and hierarchical like a treeview or a tiered  
menu system and doing processing with DOM methods would be so much  
more useful than any ID based approach. Currently, the only way to do  
this is by using a suite of helper functions, much like old-school  
DHTML. I'm disappointed that, in practice, a standards-based approach  
has brought no consistency to this important area.

> 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.

They would curse a DOM which serialized differently from another DOM  
certainly, which is the current situation.

Despite the fact that firstChild returning an empty whitespace node  
makes no sense for browser application developers, I can see the use  
for this node in pre-formatted node content, pretty-printers, IDEs  
etc. If there was only one true way to implement the DOM, I would say  
'with whitespace' would have to be it, but that now leaves a legacy  
of browsers that don't work like that.

> 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.

Where does it state that please? All I could find in the spec was a  
statement that these nodes 'may' be retained. I think that a 'must'  
or a 'should' would have prevented this inconsistency.

> .Ray Whitmer
Received on Tuesday, 26 September 2006 15:07:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:13 UTC