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. Many discussions took place on the www-dom@w3.org mailing list and are in tthose archives. The comments are listed in no particular order.

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 [1] 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 [1] 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. (David Brownell) 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.

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 in 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:

Nothing. (see Re: DOM2 implementation questions)

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.

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.

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 Bill dehOra

Resolution:

We resolved this issue during the Last Call period.

Issue CSS-3:

In CSSRuleList.item() why not throw an exception (INDEX_SIZE_ERR), instead of returning null? There is a method available to determine the number of rules in the list, and thus no reason to accommodate erroneous clients in this regard. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

There is a precedent for this in NodeList etc.

Issue CSS-4:

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 comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

It should be comma delimited. This is fixed.

Issue CSS-5:

In CSSStyleSheet a new rule can be inserted using insertRule() but there is no corresponding insertion method available for CSSRuleList, which means you can't use the CSSRuleList interface to delegate inside an implementation of CSSStyleSheet, and thus decouple the implementations. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

There is a precedent in child lists in Node. You can't use the public interface; you could use a private one.

Issue CSS-6:

CSSMediaRule rule has a deleteRule() method (that applies to a RuleList field), but there is no corresponding deletion method to order a RuleList to delete a rule. This is essentially the same problem as described in issue css-3. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

Also a precedent on Node.

Issue CSS-7:

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-8:

Can CSSStyleDeclaration.setText(String) be used to add new properties? The method is not discussed in the draft. I think that it can, but a more explicit description would help. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

We think the description is sufficient.

Issue CSS-9:

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-10:

The availability of a CSSProperty interface would be useful. CSSProperties would be stored by a CSSStyleDeclaration styled as a list, which simplifies the construction and adjustment of CSSStyleDeclaration greatly and eliminate issues CSS-7 and css-8. in comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

We considered this issue and think we've come up with a good compromise between ease of scripting and efficiency of implementation.

Issue CSS-11:

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.

Issue CSS-12:

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-13:

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-14:

CSSPrimitive.setFloatValue(short), states in its comments: 'If the property attached with this value can not accept the specified unit or the float value, the value will be unchanged and a DOMException will be raised'. There is nowhere in the CSSOM that such a property explicitly exists, other than in arguments into CSSStyleDeclaration, but more of that in a minute.

The CSSValue object states: 'A CSSValue object only occurs in a context of a CSS property'. Since values cannot explicitly refer to their targets, in the object model at least, values *do* occur in the absence of a property.

The main workaround as things stand is for a client to call the getPropertyValue(DOMString) or getPropertyCSSValue(DOMString) from CSSStyleDeclaration, hold a reference to the argument string and let the client check itself that the new value is sound. Apart from being a poorly encapsulated design, this beggars the question of the need for CSSPrimitiveValue's signature to demand an exception in the first place. It's also not much use when implementing CSSPrimitiveValue itself. How is it to know that the incming unit type is ok? As things stand with CSSPrimitiveValue, I can try and induce whether the incoming new value is ok *only* in term of the existing value, *not* the 'attached' property.

I suggest either a) adding the method getParentProperty(): DOMString to CSSValue. A direct reference is of great advantage since a lot of CSSOM processing time is going to be spent manipulating CSSValue and its subclasses. Or b) as I have mentioned before, creating a full CSSProperty object, and making CSSStyleDeclaration a list container for such objects. Adjustments to values can be controlled from this object. in Re: comments: DOM Level2 19991210 (long) from Bill dehOra

Resolution:

The object model doesn't restrict what's possible in the implementation. We expect a CSS value to have a reference to its corresponding property in the implementation, although this isn't exposed in the interface.

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)

6. Range

Issue Range-1:

1. DOM Range : Java bindings are great but why the static final variables are not converted to upper case (like in DOM core) ? see : StartToStart, StartToEnd, ...
2. the Range interface has an IDL method called isCollapsed. Why the Java binding is getIsCollapsed() ? isCollapsed() sounds better.

in DOM Range comments from Thierry Kormann

Resolution:

Constants in IDL are now in uppercase. isCollapsed is now 'collapsed'

Issue Range-2:

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-3:

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]

Issue Range-4:

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)

Issue Misc-2:

The text uses the word "platform" inappropriately. in Notes on DOM L2 CR from David Brownell

Resolution:

Cleaned up the usage of "platform" to be consistent with the meaning "Windows, Macintosh, Linux, etc."