This is the official issues list for the DOM specifications.
This document contains a list of issues regarding the DOM specifications. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives).
An XML version of this issues' list is also available.
Color key: error warning note
Id: Title | State | Type |
---|---|---|
ls-3 : well-formed, and namespaces parameters | no decision (raised) | clarification |
ls-4 : parseURI and null return value | no decision (raised) | clarification |
core-3 : adoptNode and failure | no decision (raised) | clarification |
html-1 : focus and DOM Level 2 HTML | no decision (raised) | clarification |
events-1 : DOMFocusIn|Out, DOMActivate | no decision (raised) | clarification |
core-6 : compareDocumentPosition and DocumentPosition | no decision (raised) | clarification |
ls-1 : appendix E or B? | no decision (raised) | editorial |
ls-2 : well-formed parameter and errors | no decision (raised) | error |
core-4 : Memory leak in DOMImplementationRegistry | no decision (raised) | error |
core-5 : NO_DATA_ALLOWED_ERR is not used?!? | no decision (raised) | error |
core-1 : DOMImplementationRegistry description | no decision (raised) | proposal |
core-2 : User data handling for adoption, deletion and renaming? | no decision (raised) | proposal |
It might be worth mentioning in the spec the potential well-formedness errors that may arise during serialization when "namespace-declarations" is set to false, "namespaces" to true and "well-formed" to true.
The parseURI
method from the DOM Level 3 LS
states: "If the LSParser is a synchronous LSParser,
the newly created and populated Document is returned, or
null if an error occurred." Seems a bit odd, should
null be returned when validation errors occur? The L3
Candidate Recommendation did not contain the condition "or
null if an error occurred." What was the rationale behind
this change to the PR?
According to the DOM Level 3 Core Recommendation for
Document.adoptNode
, "Return Value: The
adopted node, or null if this operation fails, such as
when the source node comes from a different
implementation." and "Exceptions:
NO_MODIFICATION_ALLOWED_ERR
: Raised when the
source node is read-only." So should an attempt to
adopt a read-only node across DOM implementations return
null
or throw a DOMException
or
is this implementation dependant?
As part of the DHTML accessibility Roadmap effort we determined that one of the most critical issues with JavaScript is that user agents do not allow the author to give focus change to any element within the DOM. JavaScript authors treat all elements as active and will quite often place onclick and onmouseover event handlers on virtually any element, including DIVS and SPANS. Assistive technologies are designed to follow the users focus. It is the responsibility of the author to ensure that focus is given to an element so that the user and assistive technology can follow focus. In US Public law 508 this is provided indirectly by requiring that keyboard equivalents for all mouse actions.
DOM level 2 HTML indicates that the focus method is only provided for on anchors and form elements. In discussing the issue with Raman this document only reflects common practice on the web rather than what actually may be done. I feel this is the source of confusion. DOM level 2 for any element to be active within the DOM. If this is true then all elements should have the ability to receive focus.
Please clarify if the current implementation by user agents is incorrect? May all document elements receive focus?
If the response by the group is that the current interpretation is incorrect and that all elements may receive focus then the Mozilla team has agreed to correct this problem by adding the focus() method to all elements. If the response is that the interpretation is correct then we need to have reform.
User agents should also allow the author to dispatch DOMFocusIn, DOMFocusOut, and DOMActivate events to any element within the DOM. Currently Mozilla does not allow this. While it claims to support DOM2, DOMFocusIn, DOMFocusOut, and DOMActivate are not generated from the browser in response to an onclick or a mouse click. This make the script authoring more complex. In order to provide equal access to the keyboard, the author must map a handler for the keyboard click and mouseclick rather than simply responding to a DOMActivate.
Should the user agent:
compareDocumentPosition
does not say that
its returned value is defined by the DocumentPosition
constants.
The document references appendix E of XML 1.1 when it meant to reference appendix B.
The "well-formed" parameter in DOM Level 3 Load and Save references the "well-formed" parameter in Core. This means that when a not well-formed error of type "wf-invalid-character-in-node-name" and "wf-invalid-character" occurs while loading or saving a document, the value of DOMError.severity should be SEVERITY_ERROR since Core specifies this. Should the description of the "well-formed" parameter in the LS specification be modified to report an error of severity SEVERITY_FATAL_ERROR instead?
There exists a possibility of a memory leak that can
originate from
DOMImplementationRegistry.java
. If an
IOException
is thrown when the
getServiceValue()
method from
DOMImplementationRegistry.java
attempts to
read a service provider to retrieve the resource
META_INF/services/org.w3c.dom.DOMImplementationSourceList
,
the underlying InputStream
is never closed
and this may result in a memory leak. The method
getServiceValue
should read:
private static String getServiceValue(final ClassLoader classLoader) { String serviceId = "META-INF/services/" + PROPERTY; InputStream is = null; BufferedReader rd = null; String serviceValue = null; // try to find services in CLASSPATH try { is = getResourceAsStream(classLoader, serviceId); if (is != null) { try { rd = new BufferedReader(new InputStreamReader(is, "UTF-8"), DEFAULT_LINE_LENGTH); } catch (java.io.UnsupportedEncodingException e) { rd = new BufferedReader(new InputStreamReader(is), DEFAULT_LINE_LENGTH); } serviceValue = rd.readLine(); } } catch (Exception ex) { return null; } finally { if (rd != null) { try { // try to close the reader. rd.close(); } // Ignore the exception. catch (Exception ex) {} } } if (serviceValue != null && serviceValue.length() > 0) { return serviceValue; } else { return null; } }
is the DOMException
NO_DATA_ALLOWED_ERR
referenced anywhere in
the specs?
The description of DOMImplementationRegistry
in the DOM Level 3 Core Java binding, does not mention
that a service provider will be used if the system
property is not set.
It would have been nice if it mentioned something similar
to the description for the newInstance()
method ... "The
DOMImplementationRegistry
is initialized by
the application or the implementation, depending on the
context, by first checking the value of the Java system
property
org.w3c.dom.DOMImplementationSourceList
and
then the service provider whose contents are at
META_INF/services/org.w3c.dom.DOMImplementationSourceList
.
The value of this property is a white-space separated list
of names of available classes implementing the
DOMImplementationSource
interface."
Though the specification does not mention it, when a node is adopted, the UserData associated is carried over, right? A minor editorial point, noticed that the description for DOMUserDataHandler - handle(...) [1] mentions "This method is called whenever the node for which this handler is registered is imported or cloned". Is there any need to mention other operations namely adopted, deleted and renamed for which the method is invoked.
Last update: $Date: 2005/05/10 14:07:40 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.