- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 1 Dec 2005 23:30:48 -0800
- To: Curt Arnold <carnold@houston.rr.com>
- Cc: DOM mailing list <www-dom@w3.org>
- Message-Id: <F23722BA-A42A-402E-A44B-FE9C2CEE6DB4@apple.com>
On Dec 1, 2005, at 8:07 AM, Curt Arnold wrote: > > A lot of good traffic on today. Sorry I was asleep when much of it > happened and couldn't participate in real time. > > The DOM L1 test suite has a couple of tests that check for an empty > string return from getAttribute, specifically > elementgetelementempty, elementreplaceexistingattribute (and hc_ > variants), and hc_elementremoveattribute. > > C++ bindings using STL strings are one instance of a language that > does not have distinct representation of a NULL string. > > There is a legitimate end-user benefit for non-dominant browsers to > conform the de-facto behavior when it deviates from the spec. > However, HTML browsers are only one class of apps that implement > the DOM spec. If an errata was issued that made null a valid > return value for getAttribute, Java code that depended on the > behavior in the recommendation could break with a new comformant > Java implementation that decided to return null instead of empty. How about allowing null only for JavaScript implementations, then? It seems silly to make the spec incompatible with a vast body of existing JavaScript code for the sake of Java. If the DOM intends to ignore browser-based implementation issues, then we'll have to conclude that our best alternative is to seek a different standards forum that cares (e.g. <http://whatwg.org/mailing- list>). I will note that the CSS working group is much more flexible about evolving the spec based on browser implementation experience. Note that CSS 2.1 actually removes entire features from CSS2. > There may be some benefit from documenting where HTML+Javascript > implementations are known to deviate from the recommendation for > compatibility. However, if something is done, it should be done in > a way that XHTML+Javascript or SVG+Javascript browsers are required > to follow the recommendation since there isn't a significant body > of existing script. It seems like a recipe for disaster to have a subtle change of semantics like this between different documents. In particular, a browser may allow inserting SVG MathML elements into an HTML document via the DOM, or may import a node from an XHTML document into an HTML document via adoptNode - at this point should the semantics of getAttribute change? Requiring implementations to be inconsistent with themselves seems even worse than allowing inconsistency between different implementations. Regards, Maciej
Received on Friday, 2 December 2005 07:30:53 UTC