- From: Curt Arnold <carnold@houston.rr.com>
- Date: Thu, 1 Dec 2005 10:07:52 -0600
- To: DOM mailing list <www-dom@w3.org>
- Message-Id: <8AF25E9B-24FB-40CD-97ED-F5D5BFBC0F34@houston.rr.com>
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. 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.
Received on Thursday, 1 December 2005 16:08:18 UTC