Re: New DOM Level 2 Working Draft

David,

Thanks for the comments and suggestions. Responses and clarifications are detailed below.

> Since DOM2 has ways of handling multiple documents, why not have
> methods in DOM1 HTML that are like the DOM Level 0 methods for frames?
> My memory of those interfaces is a little fuzzy, so I can't really
> describe them.  I could try and find out more if you're interested.

One of the items under consideration for DOM Level 3 is a "Views and Formatting" section that will
possibly cover, among other issues, the browser "window" object. I believe the new section will cover
the Level 0 frames methods.

> You should state that the following are 0-based (if they are):
>  * HTMLOptionElement::index (which makes a few other things 0-based since
>      they refer to it, i.e., HTMLSelectElement::selectedIndex and the
>          index argument to HTMLSelectElement::remove())
>  * HTMLTableCellElement::cellIndex
>  * HTMLTableRowElement::rowIndex
>  * HTMLTableRowElement::sectionRowIndex

I'll make the 0-base explicit.

> 2.1, 3d paragraph - Does the DOM2 HTML not guarantee interoperability
> when the strict DTD is used?  I think it should.

The claim is that not all implementations need to enforce the strict DTD. Any program that makes the
assumption that the strict DTD is in use may not work across all implementations.

> 2.5.1 - what happens if the attributes are unspecified and they have no
> default value?  I assume "" for those that are DOMString, but what about
> boolean and number?

You're right - the empty string for string values and false for booleans. For numbers, the default
value will depend on the attribute in question. For the size attribute of HTMLSelectElement (the only
HTML attribute for which we return a numerical value), the default value is 0. I'll add these
clarifications to the spec.

> 2.5.1 - In the table, "e. g., border" is very misleading for the
> one-value value list example.  There is no boolean border attribute.
> How about "e.g., disabled"?

Fair enough. I'll change the spec.

> 2.5.4 - These elements are missing the X'ed attributes, and thus aren't
> really fit for HTMLElement (at least in 4.0 Strict):
>           T C
>           I L L
>           T A A D
>         I L S N I
>   Attr. D E S G R
> Elem.
> BR            X X
> PARAM     X X X X
> HR            X X
> HEAD    X X X
> TITLE   X X X
> BASE    X X X X X
> META    X X X
> STYLE   X X X
> SCRIPT  X X X X X
> HTML    X X X
>
> What happens when these attributes are accessed or set?

Since there's nothing that precludes the modification or access of these attributes (or any other
attribute) for an arbitrary element, the conveniences provided in HTMLElement translate to
setAttribute() and getAttribute() calls for these elements.

> HTMLSelectElement::add() - what happens when element is not an
>   HTMLOptionElement?  when before is not in the list?  can element
>   be an HTMLOptGroupElement?  can before?

Since the DOM doesn't enforce HTML validity, the method does not throw an exception if the element is
not an HTMLOptionElement. The method is equivalent to Node::appendChild() on the HTMLSelectElement if
before is NULL. It is equivalent to a Node::insertBefore() on the parent of before for any type of
element. The method should throw a DOMException with error code NOT_FOUND_ERR if the before parameter
is not a descendant of the HTMLSelectElement. I'll add the relevant prose and add the exception to the
IDL for the method, after confirming this with the other co-editors.

> The definition of HTMLTextArea::defaultValue doesn't explicitly say
> that changing the defaultValue changes the child text Node of the
> element.  I think it should, to be equivalent to the defaultValue,
> defaultChecked, and defaultSelected attributes.

True. I'll change the spec.

> How does HTMLTableCellElement.cellIndex deal with rowspans and
> colspans?  That is, is it the child number of the cell within its
> row or is it the column where the cell starts?

The cellIndex is the child number of the cell within its row in doucment tree order. I'll make this
more explicit in the spec.

> Similarly, how does rowIndex treat TFOOT?  Does it give the index in
> document tree order or display order?

The rowIndex attribute is the index in document tree order.

> Similarly, what exactly do the index parameters in the following functions
> mean:
>  * HTMLTableElement::insertRow
>  * HTMLTableElement::deleteRow

The index is relative to all TR elements in the table in document order, regardless of the existence
or absence of table sections.

>  * HTMLTableSectionElement::insertRow
>  * HTMLTableSectionElement::deleteRow

The index is relative to all TR elements in that table section in document order.

>  * HTMLTableRowElement::insertCell
>  * HTMLTableRowElement::deleteCell

The index is relative to all TD and TH element in that table row in document order.

> Also, the following fixed error should probably be added to the DOM1
> Errata (I was working on a list of DOM1 errors):
> HTMLOptionElement::selected should not be readonly.  I think this is
> clear from the prose in the errata, but it should be stated for those
> using the IDL

You're correct. I'll change the spec.

Thanks again!
--Vidur

Received on Tuesday, 9 November 1999 20:03:25 UTC