Introduction

The comments have been divided into modules. Comments received which indicate misspellings in the text, or requests for clarification, are not necessarily in this disposition of comments, but were fixed. Most of the requests for clarification which uncovered divergence or misunderstanding are listed in this disposition of comments, some pure misunderstandings were cleared up in email. The comments are listed in no particular order.

Except if there is a disagrement (the issue is marked in red), all issues are resolved with the agreement of the issue sender (or we didn't receive any disagrement after the resolution of the issue).

1. Core

Issue Core-1:

Request for DOMString Element.getStartTag(); and DOMString Element.getEndTag(); in Methods Request from Andrew n marshall

Resolution:

This issue will be addressed during the serialization work in Level 3. (see Re: Methods Request)

Issue Core-2:

What happens when Node.replaceChild is invoked with its newChild being a DocumentFragment? in Node.replaceChild with newChild being a DocumentFragment from Takuki Kamiya

Resolution:

The contents of the DocumentFragment are inserted, and the empty DocumentFragment is left behind, just the same as for insertChild etc.

Issue Core-3:

How does DOM know whether to accept or reject a name based on namespace support? in Re: Comments on DOM level 2 from David Brownell

Resolution:

Done. See section 1.1.8

Issue Core-4:

xmlns & createElementNS - The current spec allows creating an element with the prefix "xmlns". I think a NAMESPACE_ERR exception should be raised. in xmlns & createElementNS from Arnaud Le Hors

Resolution:

The namespace error doesn't cover all cases. This case will be addressed in DOM Level 3 (during serialization and/or document validation).

Issue Core-5:

NAMESPACE_ERR missing from createDoctype and createDocument - In the current spec neither createDocumentType nor createDocument raises a NAMESPACE_ERR exception ever. This is inconsistent with createElementNS and createAttributeNS. in NAMESPACE_ERR missing from createDoctype and createDocument from Arnaud Le Hors

Resolution:

Fixed.

Issue Core-6:

For elements and attributes without a namespace, setPrefix should throw an exception (preferably NO_MODIFICATION_ERR). in Notes on DOM L2 CR from David Brownell

Resolution:

Fixed.

Issue Core-7:

A fundamental bug in the document type creation model. SUGGESTED FIX: createDocumentType doesn't belong as a method on the DOMImplementation object. It belongs on Document, since the DTD is feature internal to the Document. in Notes on DOM L2 CR from David Brownell

Resolution:

No changes. The current model implies that you'll need to create the document _after_ the document type, in others words, to memorize all informations before the document type (XMLDecl, PIs, ...). We simply changed the definition of internalSubset to say that this is implementation dependant.

Issue Core-8:

The example under "element" is incorrect; it says that there are only element nodes, while it's clear that there should also be three Text nodes (holding whitespace). in Notes on DOM L2 CR from David Brownell

Resolution:

A white space can be ignorable (depends on the DTD). The example has been changed.

Issue Core-9:

Text::splitText() - The "Return Value" section should probably say "The new node." instead of "The new Text node.", considering the addition of the comment that the new node is of the same nodeType. in Comments on DOM2 (Core, HTML, CSS) from L. David Baron

Resolution:

Fixed.

Issue Core-10:

What is the difference between Attr::nodeValue and Attr::value? DOM2 implementation questions from Raph Levien

Resolution:

There is no difference. (no need to clarify the spec).

Issue Core-11:

There should be a more user friendly way for clients to determine whether a CSSOM or Stylesheet object is read only other than forcing clients to guess and then handle NO_MODIFICATION_ALLOWED_ERR. A cleaner, less brittle approach is to allow a query to the objects using an isReadOnly() method prior to attempting a write call, and this could be specified as a general policy. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

Read-only style declarations are only found for computed style, and the context should tell the user where they are. The NO_MODIFICATION_ALLOWED_ERR is superfluous in most cases but could be used by a read-only implementation. BTW, read only DOMs are on the issue list for DOM Level 3.

Issue Core-12:

internalSubset and interactions with the DTD: the March 2000 CR will take out the internal subset parameter that was added in the December 1999 CR. This was posted to www-dom, and there was some disagreement expressed to losing this parameter in private email to the chair since it did enable a limited range of uses.

Resolution:

Since DOM Level 2 doesn't address DTDs, we decided to remove the parameter in createDocumentType. We also add a sentence to indicate that the internalSubset attribute in DocumentType should provide as much information as possible. The createDocumentType() method that's provided by DOM Level 2 is only meant to be used when creating a document from scratch in memory. It isn't suitable for all cases. We discussed the possibility of rehashing the design of createDocumentType to better address these needs of those loading a document through a parser. However, it was deemed too late, and it was decided that this would be addressed in DOM Level 3.

Issue Core-13:

Why not Node.insertAfter()

Resolution:

node.insertAfter(newKid,refChild), if it existed, would be precisely equivalent to node.insertBefore(newKid,refChild.getNextSibling()).So insertAfter might be convenient, but isn't strictly necessary.

Issue Core-14:

Copying a node from one doc to another

Resolution:

Part of requirements for DOM Level 3 (Document3.adoptNode).

Issue Core-15:

Should be a createEntity() method on Document or, the comments on importNode() regarding importing Entities should be changed to indicate that an attempt to import an entity is not supported.
In createEntity and ImportNode from Keith W. Boone

Resolution:

Basically, DOM Level 2 left what we had done in Level 1 unchanged.
createEntity and createNotation, and whether it makes sense to allow importing these nodes, will be addressed as part of DOM Level 3's Content Model work.

Issue Core-16:

Neither DOM Level 1 nor Level 2 makes any promises about supporting multithreading. It should be stated clearly in the DOM specification.
In RE: Questions about import and Multithreading issues. from Keith W. Boone

Resolution:

We added in the introdcution:

"DOM Level 2 does not specify multithreading mechanisms."

Issue Core-17:

I was wondering why DOMException extends RuntimeException
In DOMException extends RuntimeException (DOM Java binding) from Julian Reschke

Resolution:

There's simply no good reason to check for DOMException in most cases, because if you get one it means you probably need to rewrite your program.

Issue Core-18:

Some clarification please. In the DOM2 spec of December 10, 1999, section 1.2 describing the Attr interface [p.57] contains the following paragraph:
"In XML, where the value of an attribute can contain entity references, the child nodes of the Attr node provide a representation in which entity references are not expanded. These child nodes may be either Text [p.66] or EntityReference [p.71] nodes. Because the attribute type may be unknown, there are no tokenized attribute values."
I don't understand the meaning of the last sentence. Does it mean that attribute values MUST be atomic? Can anyone provide a clearer explanation and possibly illustrate the meaning with an example?
In Attr: Tokenized attribute values. from Blaine Brodie

Resolution:

We clarified as following:
"Because the Core DOM is not aware of attribute types, it treats all attribute values as simple text strings, even if the DTD or Schema declares them as having a tokenized type."
We also decided to add (and link for the paragraph) the following definition in the glossary:
"tokenized: The description given to various information items (for example, attribute values of various types, but not including the StringType CDATA) after having been processed by the XML processor. The process includes stripping leading and trailing white space, and replacing multiple space characters by one. See the definition of tokenized type."

Issue Core-19:

What is the result of document.createAttribute("a").getNodeValue()?
In Two questions from Lars Marius Garshol

Resolution:

Clarified. "".

Issue Core-20:

What is the result of calling element.removeAttribute("non-existent")?
In Two questions from Lars Marius Garshol

Resolution:

Nothing (i.e. no exception since this method doesn't have any return value).

Issue Core-21:

Several methods in DOM2 interfaces, e.g. Element.getAttributeNS, has a namespaceURI. If the element or attribute one want to fetch has no namespace, should the namespaceURI parameter be null or the empty string?
in namespaceURI parameter from Mikael Staldal

Resolution:

An element with no namespace has a null namespaceURI.

2. HTML

Issue HTML-1:

Issue HTML-3 doesn't seem to be mentioned in the spec. I think it should be. It isn't obvious, especially for certain number values (HTMLSelectElement::size, etc.). in Comments on DOM2 (Core, HTML, CSS) from L. David Baron

Resolution:

Fixed.

Issue HTML-2:

Issue HTML-6 doesn't seem to be resolved as stated in [2]. in Comments on DOM2 (Core, HTML, CSS) from L. David Baron

Resolution:

Fixed.

Issue HTML-3:

HTMLTextAreaElement::defaultValue - (from issue HTML-7) - Should this say explicitly that changing defaultValue *does* change the contents of the element? That's what the comment that HTMLTextAreaElement::value doesn't do so makes me think. in Comments on DOM2 (Core, HTML, CSS) from L. David Baron

Resolution:

Fixed.

Issue HTML-4:

HTMLTableCellElement::cellIndex - (from issue HTML-8) - this doesn't seem to be clarified as mentioned in issue HTML-8 [2]. in Comments on DOM2 (Core, HTML, CSS) from L. David Baron

Resolution:

Fixed.

Issue HTML-5:

All methods mentioned in issue HTML-9 - shouldn't they also throw INDEX_SIZE_ERR if index is negative? in Comments on DOM2 (Core, HTML, CSS) from L. David Baron

Resolution:

Fixed.

3. StyleSheets

Issue Style-1:

Remove the value 'all' from MediaList. I've posted on this subject before (http://lists.w3.org/Archives/Public/www-dom/1999OctDec/0249.html), with no response (from this list or www-style). Again. The value 'all' is logically dubious, if not absurd. It seems expedient to just eliminate 'all' from both the Stylesheets OM and the CSS specs, and assume that any CSS/stylesheet rule that is not media targeted is applicable to any available end-media that the client UA has available to it. In implementation it requires mucking about with list members, and is dependent on one's interpretation of the semantics of 'all'. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

The value 'all' is specified by the CSS spec and the DOM can't change the CSS spec.

4. CSS

Issue CSS-1:

Various; most were cleared up except for Re: comments/questions/suggestions/bug reports for DOM Level 2 from Garret Wilson - It might be clearer if A) "e.g." is changed to "i.e." in both places to indicate that the lists for CSSPrimitiveValue.setFloatValue() and CSSPrimitiveValue.setStringValue() are both exhaustive. B) CSS_STRING is added to the list of possible values for CSSPrimitiveValue.setStringValue().

Resolution:

Done.

Issue CSS-2:

My concern about issue CSS-2 in the Last Call disposition is that it makes it impossible to build a compliant CSS implementation using only the CSSOM data structures for stylesheet storage. Maybe the CSS WG would care about that? I still disagree on issue CSS-3 in the Last Call disposition, but there's no point saying the same thing over again. All I can say is that the third sentence of the response in [2] doesn't follow from the quote in the second. in some confusion with the 'all' medium from L. David Baron

Resolution:

We resolved this issue during the Last Call period:

"The border-color gets its value from the color property when the border property doesn't contain a color, but the value of the color is the _specified_ value of the color property and not the value in the style sheet. Since we don't compute the inheritance in the CSS OM (except for the computed style declaration), the border color should be empty. We can't invent a new value for this case. The border-color will be only effective in the computed style but the specified style will give you an empty string."

Issue CSS-3:

DOMImplementationCSS.createCSSStyleSheet() accepts a string of media as its argument, but does not specify that this list is comma delimited, whereas the MediaList object that presumably stores this list insists on a comma separated values. Specifying that createCSSStyleSheet() use a CSS string avoids the inefficiency that the string be parsed and rebuilt before sending it to the MediaList. in some confusion with the 'all' medium from Bill dehOra

Resolution:

It should be comma delimited. This is fixed.

Issue CSS-4:

CSSPageRule and CSSStyleRule have precisely the same method signatures. This would imply refactoring to a common interface, or renaming the methods if maintaining a logical mapping between interfaces and CSS rules is highly desirable. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

They look the same but aren't the same.

Issue CSS-5:

CSSStyleDeclaration.setText(String) again. Is this method essentially an iterated version of setProperty()? If so, while a result of the IDL, it's unnecessary, since a client can simply iterate on setProperty(). Removing it also avoids asking the CSSOM to perform an initial parse into separate arguments for setProperty(). Taking things a little further, why specify how this object stores its properties at all? That is, remove the attribute cssText and turn this interface into a list. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

This is a helpful convenience method.

Issue CSS-6:

CSSPrimitiveValue has a convoluted way of setting its values when its a Counter, RGB or Rect instance, essentially:

• XX.getRGBValue().getBlue().setFloat(float);
• XX.getRGBValue().getRed().setFloat(float);
• XX.getRGBValue().getGreen().setFloat(float);

What is the reason for this as opposed to supplying set methods for the three complex instances? in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

The "getBlue" etc comes about because the value can be a percentage or a number. An easier method to set these values would be a convenience, which we don't think is necessary now, but will put on the list to consider in future enhancements. Also, the RGBValue interface exists for clarity (instead of having the three methods on the CSSPrimitiveValue interface.

Issue CSS-7:

CSSStyleDeclaration.removeProperty() returns the empty string if it has been given an invalid CSS2 property. It seems preferable that an exception (SYNTAX_ERR) is used to inform the client explicitly that it is passing in junk. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

We try to not throw exceptions if we can return a reasonable error value.

Issue CSS-8:

CSSPrimitive.getStringValue() says that "this method is used to get the string value in a specified unit. " Note that the method does not have such a specified unit argument, as does CSSPrimitive.getFloatValue(short).
Thus there is either 1) an error in the description, and an unspecified string is returned (change the description) or 2) a missing short argument specifying the desired unit type (change the method). in Re: comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

The description is wrong.

Issue CSS-9:

However the interface only has DOMString attributes. Shouldn't all of these attributes CSSPrimitiveValue's instead?

Resolution:

counter functions can only contains identifiers and strings. Both of them are clearly identify in counter and counters. Changing them to CSSPrimitive values will add a unuseful layer to access the identifiers.

Issue CSS-10:

The CSSStyleDeclaration interface fails to state what a valid index range is. Does it begin at 0?

Resolution:

Yes. Fixed.

Issue CSS-11:

The list type interfaces in the spec. are somewhat inconsistent in the way that they define their valid ranges.

Resolution:

Fixed.

Issue CSS-12:

MediaList: Since delete is a keyword in C++, perhaps this method should be named "deleteMedium" instead.

Resolution:

Fixed.

Issue CSS-13:

"The getComputedStyle method of the ViewCSS interface [1] is somewhat difficult to implement because it requires the computed values, which in some implementations are handled to some degree outside the style system. I propose below an additional method (for the DocumentCSS interface [2]) that could offer much of the same functionality and would be easier to implement. Below that, I will comment on what I see as the biggest problem with getComputedStyle." (in getComputedStyle vs. getCascadedStyle from L. David Baron).

Resolution:

If the value is inherited, you use the computed value of the parent so you will need the computed style in any case. the proposal is useful but it needs more clarifications.

5. Events

Issue Events-1:

Bubble and Capture are two propagation mechanisms in event model, but why not broadcast or others? Also, are there any implementations? in Tow questions about dom event model from wq

Resolution:

We had some requirements which bubbling and capturing fulfill.

Issue Events-2:

Some events should be ordered: in Re: Events ordering: Largely undefined? from David Brownell

Resolution:

You may have some events in which there is only one way to do things, and thus we don't need to specify order. In others, where there is more than one way, we don't want to constrain implementations.

Issue Events-3:

Concrete proposal for MVC-capable DOM event flow from Raph Levien

Resolution:

Going into requirements for DOM Level 3 events.

Issue Events-4:

EventTarget::removeEventListener What happens if there are two listeners A and B on a target, and A removes B? Is B guaranteed to be called? What if A and B are bubble listeners on an an ancestor of the target? What if A and B are bubble listeners on two different ancestors of the target (B ancestor of A)? in DOM2 implementation questions from Raph Levien

Resolution:

Yes, B is guaranteed to be called. The chain of EventListeners is determined _before_ the initial dispatch. i.e: your EventListener list is "cloned" at the beginning of the dispatch process. If A and B are bubble listeners, it's the same. If A and B are bubble listeners on different ancestors (B an ancestor of A), the ancestor listener won't be called in bubbling phase. Notice that in capturing phase it's the child listener that won't be called. Re: DOM2 implementation questions from Thierry Kormann

Issue Events-5:

Node::normalize What events are appropriate? Deletion of additional Text nodes followed by mutation of the first Text node? (this is what I perceive to be the reverse of Text::splitText). DOM2 implementation questions from Raph Levien

Resolution:

All events corresponding to the changes being made to the document. The exact sequence of events is unspecified, since the exact sequence of operations performed by the normalize operation is unspecified. (see Re: DOM2 implementation questions)

Issue Events-6:

eventType: provide basic guidance about how to avoid name collisions.

Resolution:

We added:
"Any new event type must not begin with any upper, lower, or mixed case version of the string "DOM". This prefix is reserved for future DOM event sets. It is also strongly recommended that third parties adding their own events use their own prefix to avoid confusion and lessen the probability of conflicts with other new events."

Issue Events-7:

One thing that I noticed when implementing Level 2 Mutation events is that there are no events specified for adding and removing attributes, only for modifying an attribute. The DOMAttrModified event states that newValue or prevValue may be the empty string to indicate these conditions, but the empty string is a valid attribute value, so how does that help?
in DOM Level 2 Events from Steve Ball

Resolution:

We added the attrChangeType attribute on the MutationEvent interface. It allows you to know if the attribute was just added, modified in place or removed.

 // attrChangeType
 const unsigned short      MODIFICATION                   = 1;
 const unsigned short      ADDITION                       = 2;
 const unsigned short      REMOVAL                        = 3;
                  
 readonly attribute unsigned short   attrChange;
     

Issue Events-8:

it would be very useful to have something like offsetX, offsetY that would show mouse coordinates relative to the origin of the element (e.g. a DIV element) within which the event occured.
in Mouse events - coordinate systems from Boris Motik

Resolution:

You may be able to extract that information using the DOM Level 3 "Views" features, when that becomes available.

6. Range

Issue Range-1:

Lack of consistency between whether Attr can be a parent of a Range or not. in Still some DOM Range comments from Thierry Kormann

Resolution:

Attr can be a Range ancestor (see Re: Still some DOM Range comments)

Issue Range-2:

A node type is missing for the INDEX_SIZE_ERR exception type. It may be obvious, anyway I think the Text node type must be added to this sentence. in Again new comments on DOM Range from Thierry Kormann

Resolution:

[not addressed yet]. This is a documentation consistency issue, not a change. The first item to add to the DOM WG list for fixing in the Rec.

Issue Range-3:

range.getCommonAncestorContainer() Which common ancestor the method is supposed to return ? in Another DOM Range comment from Thierry Kormann

Resolution:

It's the deepest common ancestor. The word "deepest" has been added to the text. (see Re: Another DOM Range comment)

7. Miscellaneous

Issue Misc-1:

Should there be a bootstrappable DOM? We would like to be able to describe the DOM itself in a XML document conformant to a DTD. DOM level 1 Core could be described by one XML doc, DOM level 1 core+html by another one, and so on. It not yet clear to us if all the DOM can be bootstrapable or if a core is has to be determined.
in Proposal for bootstrapable DOM and CSSOM from Daniel Glazman

Resolution:

The DOM bindings are described in XML. (see Re: Proposal for bootstrapable DOM and CSSOM)
bootstrappable DOM is part of the requirements for DOM Level 3.

Issue Misc-2:

Improved XML format for the DOM spec.
in XML definitions for DOM2 - improvements from Terje Norderhaug

Resolution:

This is an interesting idea but, due to the restricted ressources of the DOM WG, we cannot garantee anything in these area. Any help is welcome.