- From: L. David Baron <dbaron@fas.harvard.edu>
- Date: Fri, 24 Sep 1999 14:01:21 -0400 (EDT)
- To: www-dom@w3.org
On Thu, 23 Sep 1999 18:47:39 +0200, Arnaud Le Hors (lehors@w3.org)
wrote:
>
> the latest DOM Level 2 working draft is now available to the public at:
> http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/
>
> We are hoping that this will be close to the final spec. So comments are
> more then ever invited and should be sent to this list. I will make sure
> we do not leave your comments unanswered. Have a look at the status
> section on the cover page for more information.
I had been making some notes of DOM1 and DOM2 errata while I was
looking at the drafts over the summer, since I didn't want to spam the
list for every tiny error I found. The release of the WD into last
call (surprisingly fast, to me) has prompted me to clean up my list,
add a few more items, and send it to the list.
If any of the comments are unclear, please ask me what I meant. I
don't really want to explain all of them in full detail when most of
them are probably quite clear (although perhaps my grammar fails at
some points, since I wrote them rather fast).
I originally kept these lists in separate files, so the references
are numbered by section.
-David
In general, I think the DOM2 Core and HTML sections should have
detailed change lists from DOM Level 1 (a quick summary of what's been
added and and a detailed list of what's been changed or clarified).
This would be very useful.
DOM2 CORE
---------
DOMImplementation::hasFeature [1] should enumerate all the possible
values for feature. Some of the sections specify them, but some do
not. Perhaps the chapters should all specify the feature as well.
[1] http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/core.html#ID-102161490
DOM2 HTML
---------
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.
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
2.1, 3d paragraph - Does the DOM2 HTML not guarantee interoperability
when the strict DTD is used? I think it should.
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?
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"?
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?
HTMLSelectElement::add() - what happens when element is not an
HTMLOptionElement? when before is not in the list? can element
be an HTMLOptGroupElement? can before?
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.
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?
Similarly, how does rowIndex treat TFOOT? Does it give the index in
document tree order or display order?
Similarly, what exactly do the index parameters in the following functions
mean:
* HTMLTableElement::insertRow
* HTMLTableElement::deleteRow
* HTMLTableSectionElement::insertRow
* HTMLTableSectionElement::deleteRow
* HTMLTableRowElement::insertCell
* HTMLTableRowElement::deleteCell
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
DOM2 StyleSheets
----------------
See my previous message [1] about why a major part of this section
competes with rather than complements the stylesheet linking methods
defined in HTML4 and xml-stylesheet.
[1] http://lists.w3.org/Archives/Public/www-dom/1999JulSep/0032.html
DOM2 CSS
--------
CSSStyleDeclaration::cssText shouldn't have "{" and "}" since it is
used for HTMLElement::style. Thus "including" should be changed
to "excluding" in [1].
There are messy issues with the border-color property. See
http://lists.w3.org/Archives/Public/www-style/1999Sep/0082.html
http://lists.w3.org/Archives/Public/www-style/1999Sep/0085.html
I think the following statement in [2] is unnecessary because the special
system font shorthand values *can* be decomposed (and must, since
some of the equivalent longhand properties can be changed, leaving
others intact). I think it should be removed:
If the value of a shorthand property can not be decomposed into its
component longhand properties, as is the case for the font property
with a value of "menu", querying for the values of the component
longhand properties should return the empty string.
Furthermore, I think it would be good if [2] explicitly said that
querying a longhand property when a corresponding shorthand property
has set the value of that longhand property should return the
appropriate value rather than the empty string. That seems to be
implied, but not clearly so.
[1] http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/css.html#CSS-CSSStyleDeclaration-cssText
[2] http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/css.html#CSS-CSS2Properties
DOM2 EVENTS
-----------
* In 6.6.2, UIEvent::detail in relation to mouse events seems vague.
What is it for the mouseup and mousedown? When is it incremented,
exactly?
* In 6.6.2, what do the different values of button mean?
<URL: http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-MouseEvent-button >
* In 6.6.3, keyCode and charCode are listed in the "Context Info" for
all event types, but nothing else is listed in the "Context Info" even
though other things are valid.
* The meaning of relatedNode [1] on the mouseout Mouse Event should be
explicitly stated. My guess is that it should contain the node into
which the mouse has moved. However, this node may or may not be
receiving a mouseover event because of that movement (i.e., it won't if
it's the parent). Should it be null in those cases?
* what is the point of MutationEvent::relatedNode? The only thing it
is used for duplicates event.target.parent. (It could be more useful
if it were used for more of the events, I think.) Or are there some
things missing in "Context Info" sections? (It seems that this is
the case from the description of relatedNode [2].)
* When are mousemove events fired? If the mouse moves while it is over
a p (pElem) inside a div (divElem) inside body (bodyElem), do you get
three mousemove events (one with event.target==pElem, one with
event.target==divElem, and one with event.target==bodyElem) or just one
on the most deeply nested element? Having three can be useful for
out-of-flow children, but that's a lot of events (especially with
bubbling), so I'm not sure if that is what is meant.
* If an event is at the target, are both capturing and non-capturing
event listeners called? Is event.eventPhase AT_TARGET in both
cases?
* Is the order of events for keypresses:
keydown, (keypress,)* keyup, keypress
Or is it:
keydown, [ (keypress,)+ keyup | keyup, keypress ]
Or is it UA-dependent? I think this should be explicitly stated
(even if it's UA-dependent).
* In what order are onmouseout/onmouseover fired when the pointer
moves simultaneously out of one node and into another? What about
when it moves simultaneously into two nodes (parent/child) or out
of two?
[1] http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-MouseEvent-relatedNode
[2] http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-MutationEvent-relatedNode
DOM2 ECMAScript bindings
------------------------
Are the ECMA bindings for {add,remove}EventListener correct? Should
it take a function pointer or an EventListener object?
L. David Baron Sophomore, Harvard (Physics) dbaron@fas.harvard.edu
Links, SatPix, CSS, etc. <URL: http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC <URL: http://www.webstandards.org/css/ >
Received on Friday, 24 September 1999 14:01:22 UTC