[D3E] Comments

Hi all,

here are few comments about the latest editor's draft


1.1
- Perhaps "document mutation notifications" could be removed.
   That is a deprecated part of the draft, so might be better to
   not mention that in introduction.
- I'm not sure why there is need to mention DOM0. Is that just something
   copy-pasted from DOM 2 Events?

1.2
- No need to mention XML namespaces
- Is the requirement to conform DOM 3 core module too much.
   There are parts in DOM 3 core which aren't likely to be implemented in
   browsers; for example setIdAttribute* and support for multiple ID
   attributes per element. I also doubt that the parts handling XML
   Schema are going to be implemented.
- "complete set of character values and key names in the Key Values Set"
   Does browser need to support all the key values? In practice a
   browser running on OSX may not ever dispatch an event which has key
   'Win'. Or is it enough if script creates the event and initializes the
   right values?


1.3
- Feature detection doesn't work in all cases; there are events which
   use different interfaces but same type, for example load and Progress
   event load.
   I know it looks a bit ugly, but would it make sense to change the
   event detection so that also the interface name is required.
   Something like hasFeature(Events:ProgressEvent.load, "3.0")

2
- "event type" Event type doesn't actually say anything about
   attributes or interfaces.

4.2
- Why should custom event be non-trusted, if the UA implementation
   decides to dispatch an event implementing it.

4.3
- No need to mention addEventListenerNS

4.5
- Returning DocumentEvent when +Event, "3.0" is used. Do we really need
   that? Could it be just said that language specific casting may be
   needed?

5.1.1
- blur, focus and resize aren't async.
- I don't remember or know why scroll and resize were changed from
   being Events to be UIEvent

5.1.1 and 5.2.1 are inconsistent. The first one says that load etc
implements Event (like it is in DOM 2), but latter one says that
load is an UIEvent.
I don't understand the comment "UIEvent if generated from a user 
interface, Event otherwise." Why not just always Event.

5.2.2
- I think we want relatedTarget to be null when it would point to
   an element outside the current document.
- In many events it is specified that target and relatedTarget point to
   the same object. Could the relatedTarget be just null in those cases.

5.2.3.1
- Needs review from SVG WG, or perhaps nx/ny could be moved to
   the whatever-spec SVG/CSS taskforce will have.
   (I don't recall now what we agreed)

I think there should be a new chapter started after
5.2.3.2 but before the definition of 'click'.

mouseenter and mouseleave
- They still need to be defined more precisely.
   When mouse is moved for body element to
   <h1><h2><h3>foobar</h3></h2></h1> will there be
   3 mouseenter events dispatched?
   And when mouse is again moved to body, will there
   be 3 mouseleave events?
   If the DOM tree is very deep, the will lots of events,
   though not sure I case about that.
- "Note: This is the event type equivalent of the CSS :hover
    pseudo-class [CSS2]. See also the mouseleave event type."
   Not sure about this. :hover is sort-of a state.
   mouseenter and -leave aren't.
   :hover and mouseenter/leave do have something in common,
   but saying "equivalent" is perhaps too strong.

5.2.4
- I think wheel event doesn't need to be sync.
- Could we say that UA may dispatch many wheel events with different
   deltaModes. Especially if there are enough "pixel scrolling",
   a "line scroll" event could be dispatched.
   And also when "line scrolling", also "pixel scroll" events
   could be dispatched. This way web app needs to handle only one type
   of wheel events. So far web apps use line scrolling mainly, AFAIK.
- DOMMouseScroll.detail = WheelEvent.deltaFOO / 3 is wrong, I think.
   The '3' comes from the OS/browser settings, and that is about how
   much to scroll when one "roll" happens.
   At least on Windows 3 is the default, but if I change that to 4,
   gecko reports 4 in the detail when doing one "roll".
   MozMousePixelScroll is either whatever the OS reports (supported by
   OSX and Win7+touchscreen), or lines_delta*current_lineheight.
   (For page scrolling constant +-32768 is used.)
   I think in Wheel events we want line scroll events to report how many
   "lines" OS would want to scroll.

5.2.5
- I think textInput needs some more clarification when
   for example <b>foo</b> is pasted to contentEditable area.
   There is certainly new text in the contentEditable, but there
   is also some new elements (<b>). Currently the draft says that
   textInput should be dispatched only when character data is pasted,
   but I wonder why.



5.2.6
- "if the key is the 'Enter' key and the current focus is on a state-
   changing element, the default action is to dispatch a DOMActivate
   event"
   Replace DOMActivate with click.

  - "if the key is associated with any other event type, such as the
    scroll event, the default action is to dispatch an event of that
    type." I don't think any key is associated with scroll event.
    Keys maybe associated with scrolling, and scrolling causes
    scroll event to be dispatched.

6.2.4
- The example gives the impression that key events are always
   dispatched with IME. Is that actually the case? What if the
   IME somehow opens a new dialog window for IME input?


Appendix B
- canDispatch() isn't defined anywhere. Just remove it
   from the text?



-Olli


(I need to still re-read key event handling and composition events)

Received on Sunday, 31 January 2010 18:22:11 UTC