This document contains a list of issues regarding the DOM Level 2 HTML specification Last Call period. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives) before January 7, 2002.
Nearby: about DOM . www-dom@w3.org archives
Issues are classified in 3 categories:
| Id: Title | Concerning | State |
|---|---|---|
| i1 : How to create an XHTML document? | XHTML | resolved |
| i2 : lack a method to easily access the HEAD element | improvement | rejected |
| i3 : Convenient methods to create elements | improvement | rejected |
| i4 : methods that return instances of specific elements should have a specific return type | improvement | rejected |
| i5 : HTMLFrameElement::src should dynamically update | improvement | rejected |
| i6 : HTMLFormElement::submit | clarification | active |
| i7 : HTMLInputElement::size | type error | resolved |
| i8 : HTMLTableElement: there are tFoot, tHead and caption should be readonly. | readwrite/readonly? | rejected |
| i9 : select.options.length should be read/write | readwrite/readonly? | resolved |
| i9b : select.options array | array manipulation | rejected |
| i10 : HTMLInputElement.indeterminate | new property | Subsumed by issue i24 |
| i11 : XHTML 1.0 | General | resolved |
| i12 : HTML DOM and DTDs | clarifications | resolved |
| i13 : XHTML 1.0 DTDs | clarification | resolved |
| i14 : HTML 4, 4.0, and 4.01 | clarification | resolved |
| i15 : name or id | clarification | resolved |
| i16 : HTMLDocument.anchors | convenience | resolved |
| i17 : HTMLDocument.images | convenience | resolved |
| i18 : Element.className | textual issue | resolved |
| i20 : HTMLInputElement.indeterminate, checked and the form itself | incompatibility | rejected |
| i21 : HTMLSelectElement.add | clarification | resolved |
| i22 : setting tFoot, tHead and caption | clarification | resolved |
| i23 : classid | HTMLObjectElement | rejected |
| i24 : indeterminate | technical | active |
| i25 : Java package name | technical | resolved |
Description:
HTMLDOMImplementation::createHTMLDocument creates only a bare
html document: no way to create a XHTML document or to specify a DTD. OK, I
can turn to the superclass (DOMImplementation), but I loose the
HTMLDocument as resulting document (it's "only" a Document).
Resolution: [email]
DOMImplementation.createDocument() is free to create a "XHTML
document" if you pass in the appropriate doctype and namespace URI for the
root element.
Use a casting binding-specific method to convert the Document into HTMLDocument.
Description:
in HTMLDocument there are convenient methods to access some
of the document's elements, but surprisingly lacks a method to easily access
the HEAD element (that is created by
HTMLDOMImplementation::createHTMLDocument) the way you can
access the BODY element.
Resolution: [email]
Accessing the head element is not something that's done nearly as often as
accessing the "body" element (see below), therefore there's no quick accessor
for that. Use document.getElementsByTagName('head').item(0).
Description:
somewhere (probably in HTMLDocument) there should be methods
to create instances of specific elements (for example, a
createHTMLParagraphElement method). While a workaround exists
via the method Document::createElement, the specification does
not mandate (and I don't see how can it do it) that the new element must be
of the right type (at least Xerces is smart enough to return a proper
specific instance instead of a generic Element). Also, this has
the drawback that you must specifiy the HTML tag, thus losing abstraction
Resolution: [email]
Using document.createElement(_tag_name_) (or
document.createElementNS()) is not a workaround, that's how you
create HTML elements in a HTML document, that's how it's always been, and
this method is much more flexible and extendable than providing factory
methods for every single HTML element. Doing that would just not be
practical.
Description:
methods that return instances of specific elements (as
HTMLDocument::getBody) should have a specific return type: in
the example HTMLDocument::getBody should return a
HTMLBodyElement, not just a HTMLElement.
Resolution: [email]
If you read the definition of document.body you'll see that it is not
always a HTMLBodyElement, if the document is a frameset
document, document.body will return a HTMLFramesetElement, thus
the type of the 'body' attribute must be one of the common inherited
interfaces, HTMLElement is the obvious type.
Description:
In the HTML specs, it says that the src attribute should be the original content of the frame, but it doesn't say whether you are allowed to dynamically update it. If you aren't officially allowed to dynamically update it, then it is an error with the standard, otherwise it is an error with the documentation. You should be allowed to update frames in DOM and if that isn't the intent of the DOM standard, then it needs to be added. Is there any errata on this?
Resolution: [email]
For security reasons, it is important not to let the user access the URI of the other document. src is not dynamically updated and we don't plan to add a new attribute for that effect.
Description:
Microsoft (MSDN site) claims that the submit method of a form does not invoke the onsubmit event handler.
Microsoft goes on to claim on the same page that this method (submit method) is defined in the W3C DOM Level 1.
The reference I find for the HTMLFormElement in the DOM is section 2.5.5. Object Definitions. Here it defines the submit method as performing the same action as a submit button which implies invoking the onsubmit event.
I cannot find any specific reference here for whether or not the onsubmit event should or should not be included.
Can you clarify this please because I believe not calling an onsubmit method if one is defined for a form would be a violation of the W3C L1 DOM?
Resolution: [email]
Unfortunately, given the differences between implementations, it was not possible to find a common ground on this issue. No changes were in the specification. You cannot rely on having an event when invoking the submit() method.
Description:
the definition of HTMLInputElement says that the attribute "size" is of type "DOMstring":
Browser practice differs on this though. Mozilla 0.9.6 defines the attribute as a string (element.size.toSource() return 'new String()) while Microsofts reference defines the attribute as an integer.
Resolution: [email]
size is now an unsigned long.
Description:
In HTMLTableElement there are tFoot, tHead and caption.
Why are they *not* readonly?
You can set these elements with the create* methods. Assigning an element from a different table to one of the three properties would either mean changing the document's structure (one element cannot be child of two table nodes, can it?) or copying the contents of one (e.g.) HTMLTableCaption element into a new one (but the spec doesn't say so).
Should they be readonly (IMHO yes) or is there a certain intent why they are not?
Resolution: [email]
You can always remove the elements in the table by using the removeNode methods. It doesn't seem necessary to make them readonly without a rational and these attributes are already readwrite in implementations.
The decision was not to accept the requested changes.
Description:
From O'Reilly's JavaScript Definitive Guide book [p. 646]:
[begin quote]
The options[] property contains an array of
Option objects, each of which describes one of the selection
options presented within the Select object select. The
options.length property specifies the number of elements in the
array, as does the select.length property. See the
Option object for further details.
In JavaScript 1.1 [Navigator 3.0], you can modify the options displayed in
a Select object in any of the following ways:
If you set options.length to 0, all options in the
Select object will be cleared.
If you set options.length to a value less than the current
value, then the number of options in the Select object will be
decreased, and those and the end of the array will disappear.
[end quote]
Each of the browsers that I tested, Netscape, Win IE, Mac IE, and WebTV, all work as above. I tested older versions of browsers as well as the latest versions of these browsers.
Resolution: [email]
Added an HTMLOptionsCollection in the specification.
HTMLOptionsCollection.length and select.length are read-write and can throw exceptions on setting if not supported.
Description:
From O'Reilly's JavaScript Definitive Guide book [p. 646]:
[begin quote]
If you set an element in the options[] array to null, then
that option will be removed from the Select object, and the
elements above it in the array will be moved down, changing their indices, to
occupy the new space in the array.
If you create a new Option object with the
Option() constructor (see the Option reference
entry), you can add that option to the end of list of options in the
Select object by assigning the newly created option to a
position at the end of the options[] array. To do this, set
options[options.length].
[end quote]
Additionally, if you set options.length to a value higher
than the current value, then the number of options in the Select
object will be increased by adding new options to the end of the array.
Each of the browsers that I tested, Netscape, Win IE, Mac IE, and WebTV, all work as above. I tested older versions of browsers as well as the latest versions of these browsers.
Resolution: [email]
Modifying arrays is an ECMAScript feature only and it is not possible to represent it in all languages. No changes will be made to the specification, but this behavior will not be disallowed in ECMAScript implementations.
Description:
As you may (or may not) know, checkboxes and radio buttons in user interfaces may not only be "on" or "off", they may also be an in "indeterminate" state which means that they are neither checked nor unchecked. Their state is - indeterminate, and becomes determinate when a user checks them. This is useful for example when you have an option for which there is no reasonable default (for a checkbox) or for a collection of radio buttons for which none should be initially selected.
The CSS working group has allowed the styling of the various states of checkboxes and radio buttons with two new pseudo-classes in the Selectors Candidate Recommendation:
":checked - selects elements which are considered toggled
on in the user interface. "
":indeterminate - selects elements which are considered
neither checked nor unchecked in the user interface. "
From UIstates
What we thought already existed were the respective properties in the DOM on the <input> interface.
There is a "checked" property
attribute boolean checked;
...but there is no corresponding "indeterminate" property.
The official feedback on DOM Level 2 HTML is a request to add an "indeterminate" property to Interface HTMLInputElement.
attribute boolean indeterminate;
It can be defined as follows:
When the type attribute of the element has the value "radio" or "checkbox", this represents whether the form control is in an indeterminate state (neither checked nor unchecked), in an interactive user agent. Changes to this attribute change the state of the form control, but do not change the value of the HTML value attribute of the element.
As far as implementation status, we will note that there are at least two different implementations. Both IE/Mac and IE/Windows (which have separate DOM implementations) implement input.indeterminate since version 4 (5-6 years ago).
Thus the addition of this property should pose no problem for DOM Level 2 HTML exiting CR since there are already two interoperable implementations that have been shipping for quite some time.
Mozilla currently lacks this proposed property because when Mozilla's DOM was implemented, the property was not listed in the DOM specification. However, recent changes mean that the support for indeterminate check boxes will be available soon, at least internally (this support may not be exposed in the HTML DOM unless the "indeterminate" property is added to the DOM spec).
The DOM is also missing support for some other UI pseudo-classes, such as :hover and :active, and for pseudo-elements, such as ::indeterminate. However, we do not think it would be wise to force this issue at the moment. In our opinion, those issues are not yet mature. There is ongoing work in the CSS working group to find solutions to these problems.
Adding .indeterminate to the DOM2 HTML spec is, in our opinion, a reasonable thing to do for now, since there already exists several years' worth of implementation experience.
Resolution: [email]
In November 2000, DOM Level 2 HTML was delayed for backward compatibility reasons and our intent is to capture the current practice in several implementation, which is not the case for indeterminate. Only IE implementations are supporting this indeterminate feature for the moment. The TriState implementation does support indeterminate property but it is not equivalent to the one in IEs. So, even if other implementation are going to implement indeterminate in the future, we prefer not to add this new feature for the moment. This certainly needs to be on the list for an XForms API at some point.
Subsumed by issue i24Description:
make it clear that the DOM2 HTML only applies to HTML 4 and XHTML 1.0. For instance in 1.6.3 it mentions "XHTML 1.0 or above" -- this should just read "XHTML 1.0"; in 1.6.1 it mentions "future versions of XHTML". Another example is possibly in 1.5, for method 'Open' of interface HTMLDocument, where it says "The following methods may be deprecated at some point", which suggests future versions.
Resolution:
Changes approved. section 1.6.3 and 1.6.1 changed. HTMLDocument.open changed.
Description:
We would like some text explaining the relationship between the use of the
DOM and the relevant DTD for the document in question, and what the
processing consequences are when generating elements that are not valid for
the current document. In particular we would like to see some explanation of
"The text is parsed into the document's structure model" in
HTMLDocument.write and writeln.
Resolution:
the sentence was removed in HTMLDocument.write and HTMLDocument.writeln.
Description:
XHTML 1.0 has 3 DTDs too: section 1.1 seems to suggest otherwise ("the XHTML 1.0 DTD").
Resolution:
change approved.
Description:
Please refer to HTML 4 (as a generic) or HTML 4.01 (as a particular); HTML 4.0 has been superceded by HTML 4.01. Please use the HTML 4.01 recommendation as the reference.
Resolution:
Changes approved. now referes HTML 4.01.
Description:
Mixture of semantics: name and id. The 'name' attribute has zero semantics in XHTML. So HTMLCollection.namedItem should only search for id attributes in XHTML, and ignore 'name' attributes. For XHTML, name is only relevant in form controls, therefore HTMLDocument.getElementsByName should only return form controls with matching name.
Resolution:
Changes approved.
Description:
HTMLDocument.anchors: all elements with an id are anchors in HTML 4 and
XHTML; what is the convenience of only returning the a elements?
Furthermore, since the name attribute has no semantics in XHTML, the returned
set should always be empty for XHTML documents.
Resolution:
Even if it has no semantics, the attribute name is still part of XHTML 1.0. Addition to the specification:
" The attribute name was deprecated in XHTML 1.0, therefore it is recommend to not use this attribute for XHTML 1.0 documents. Users should prefer the iterator mechanisms provided by DOM Level 2 Traversal and Range instead. "
Description:
Since <object> is the recommended method for including images in a
document, what is the convenience of HTMLDocument.images only
returning <img> elements?
Resolution:
The reason is backward compatiblity since this attribute is supported by both IE3.0 and NS3.0. However, since as the HTML WG mentioned, we
The following paragraph was added to the description:
"Note: As suggested by [HTML4.0], to include images, authors may use
the OBJECT element or the IMG element. Therefore,
it is recommended not to use this attribute to find the images in the
document but getElementsByTagName with HTML 4.0 or
getElementsByTagNameNS with XHTML 1.0."
Description:
1.6.2 suggests that there is some general naming technique applied, and yet it seems only to apply to htmlFor, and not, for instance, to Element.className, which according to 1.6.2 should be called htmlClass.
Resolution:
For backward compatibility, the name cannot be renamed.
Description:
Wording for Tristate:
"When the type attribute of the element has the value "radio" or "checkbox", this represents whether the element's checked state is undetermined. Changes to this attribute [do not] affect the checked property. When this attribute is true, the form control cannot be successful."
in IE's implementation:
" When the type attribute of the element has the value "radio" or "checkbox", this represents whether the element's checked state is undetermined. Changes to this attribute do not affect the checked property or the submission of the form control. "
We should probably choose a different name [ie different from indeterminate] so as not to break the web and the Tristate implementation.
Resolution: [email]
This is a follow-up on issue i10.
Description:
HTMLSelectElement.add raises a DOMException(NOT_FOUND_ERR) if the "before" argument is not a descendant of the SELECT element. OK.
But what happens if I try to add an element (passed in the "element" argument), that is not an OPTION element? Currently, add is directly delegated to Node.appendChild or Node.insertBefore - that is, I can add HEAD, IMG, FORM elements to the options array... That makes no sense.
If the standard specifies a special operation for adding OPTIONs, it should deal with errors specially and raise an exception if an element other than OPTION is passed.
MSIE 5.1.3 (Mac) throws a "type mismatch" error in this case.
Resolution: [email]
Added
This method may have no effect if the new element is not an
OPTION or an OPTGROUP.
Description:
DOM2-HTML should specify what happens if one tries to assign a wrong element type ("raises DOMException on setting, if a wrong element is assigned")
Mozilla 0.9.8 throws a conversion error in this case.
Resolution: [email]
If the element type is wrong, those attributes will raise a
HIERARCHY_REQUEST_ERR error.
Description:
The classid attribute of the object element, is listed in the HTML 4.01 recommendation and DOM Level 1 working draft but is not listed in the DOM Level 2 html working draft.
Resolution: [email]
It appeared that the Netscape implementation does not support the classid attribute. Therefore, the WG decided to not add the attribute in DOM Level 2 HTML.
Description:
The CSS WG is disapointed with the DOM WG's decision and maintains its opinion that "indeterminate" should be added. In detail:
Checkboxes and radio buttons in user interfaces may not only be "on" or "off", they may also be an in "indeterminate" state which means that they are neither checked nor unchecked. Their state becomes determinate when a user checks them. This is useful for example when you have an option for which there is no reasonable default (for a checkbox) or for a collection of radio buttons for which none should be initially selected.
This note documents a proposed addition to the HTML DOM that the CSS working group believes would provide access to this state to content authors. The state is already stylable using the :indeterminate pseudo-class found in the Selectors specification.
The proposal consists of the following addition to the HTMLInputElement interface:
attribute boolean indeterminate;
The attribute is defined as follows:
When the type attribute of the element has the value "radio" or "checkbox", this represents whether the form control is in an indeterminate state (neither checked nor unchecked), in an interactive user agent. Changes to this attribute change the state of the form control, but do not change the value of the HTML value attribute of the element.
An indeterminate control is neither checked or unchecked: although the value of the checked attribute is not affected when the indeterminate attribute is set, it is irrelevant.
(A separate question is whether an indeterminate control should be considered successful for the purposes of form submission, but that doesn't affect the issue at hand.)
As far as implementation status is concerned, we will note that there are at least two different implementations. Both IE/Mac and IE/Windows (which have separate DOM implementations) implement input.indeterminate since version 4 (circa 1996).
Thus the addition of this property should pose no problem for DOM Level 2 HTML exiting CR since there are already two interoperable implementations that have been shipping for quite some time.
Mozilla (and Netscape 6.x) currently lacks this proposed property because when Mozilla's DOM was implemented, the property was not listed in the DOM specification. However, recent changes mean that the support for indeterminate check boxes will be available soon, at least internally (this support may not be exposed in the HTML DOM if the "indeterminate" property is not added to the DOM spec).
The DOM is also missing support for some other UI pseudo-classes, such as :hover and :active, and for pseudo-elements, such as ::selection. However, we do not think it would be wise to force this issue at the moment. In our opinion, those issues are not yet mature. There is ongoing work in the CSS working group to find solutions to these problems.
Adding .indeterminate to the DOM2 HTML spec is, in our opinion, a reasonable thing to do for now, since there already exists several years' worth of implementation experience.
Resolution: [email]
No addition.
Description:
Given that DOM Level 2 HTML is not backward compatible with DOM Level 1 HTML, it is not possible to run a DOM Level 1 HTML and a DOM Level 2 HTML implementation within the same Java Virtual Machine. We suggest to change the Java package name of the DOM Level 2 HTML interfaces.
Resolution:
New Java package name: "org.w3c.dom.html2".
Last update: $Date: 2002/05/30 21:06:39 $