This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I collect some small fixes: === In [Each NodeIterator object has these removing steps with oldNode, oldParent, and oldPreviousSibling:] 2. >Set the referenceNode attribute to firs.... << remove this ">" sign. The same algo in 2.2, 2.4 we see "terminate these steps", but maybe better use "terminate these substeps", and change green box "Steps are not terminated here." to "Substeps are not terminated here." We have this in "invoke the event listeners" http://dom.spec.whatwg.org/#concept-event-listener-invoke === In Element.closest(selectors): http://dom.spec.whatwg.org/#dom-element-closest 2. For each element in elements, if match a selectors string selectors against element returns true, return element, . << this "," before "." can be remove. === Maybe add some info that NamedNodeMap are always live (like some Collections). We have this info in previous spec: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1780488922 http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1780488922 The same is for DOMTokenList, but this is new in DOM. === In 3.3 Error names http://dom.spec.whatwg.org/#dom-element-hasattributes INUSE_ATTRIBUTE_ERR (9) << should be INUSE_ATTRIBUTE_ERR (10) === In algo "remove an attribute by name" and "remove an attribute by namespace and local name": 2. If attr is non-null, remove it from element's attribute list. << just use "from element", because "remove" algo do it later. http://dom.spec.whatwg.org/#concept-element-attributes-remove-by-name http://dom.spec.whatwg.org/#concept-element-attributes-remove-by-namespace === In Document interface: http://dom.spec.whatwg.org/#interface-document Attr createAttribute(DOMString localName); change to [NewObject] Attr createAttribute(DOMString localName); and Attr createAttributeNS(DOMString namespace, DOMString name); change to [NewObject] Attr createAttributeNS(DOMString? namespace, DOMString name); The same in Element interface: http://dom.spec.whatwg.org/#interface-element Attr? getAttributeNodeNS(DOMString namespace, DOMString localName); change to Attr? getAttributeNodeNS(DOMString? namespace, DOMString localName); === In "validate and extract" algo: http://dom.spec.whatwg.org/#validate-and-extract all "name" variable should be "qualifiedName" (step 5., 8. and 9.). === Maybe use new [Exposed] syntax in DOM too? https://github.com/whatwg/url/commit/d59c1ade1684a68b64f868de819b22459467ef96 http://heycam.github.io/webidl/#dfn-extended-attribute === How we can deduce from IDL, that some interface are not available in global. Look: callback interface NodeFilter << have access (and example we can read constant) callback interface EventListener << don't have access There exist some extended attribute that inform about this? Maybe [NoInterfaceObject] do this? === Why in table for Document.createEvent(interface): http://dom.spec.whatwg.org/#dom-document-createevent we have [UIEVENTS] ref for some events, not [DOM3EVENTS]? And why TouchEvent don't reffer to any spec (is markered)?
(In reply to Arkadiusz Michalski (Spirit) from comment #0) > I collect some small fixes: Amazing, thanks! > The same algo in 2.2, 2.4 we see "terminate these steps", but maybe better > use "terminate these substeps", and change green box "Steps are not > terminated here." to "Substeps are not terminated here." The steps are terminated here, not the substeps. > In Element.closest(selectors): > http://dom.spec.whatwg.org/#dom-element-closest This will likely be rewritten based on discussion on www-dom list. > Maybe add some info that NamedNodeMap are always live (like some > Collections). I'd prefer that to simply follow from the method definitions. > How we can deduce from IDL, that some interface are not available in global. > Look: > > callback interface NodeFilter << have access (and example we can read > constant) > callback interface EventListener << don't have access > > There exist some extended attribute that inform about this? Maybe > [NoInterfaceObject] do this? Not sure, file a separate bug? > Why in table for Document.createEvent(interface): > http://dom.spec.whatwg.org/#dom-document-createevent > > we have [UIEVENTS] ref for some events, not [DOM3EVENTS]? And why TouchEvent > don't reffer to any spec (is markered)? DOM3EVENTS should be replaced by something called UIEVENTS down the line. It's not clear where the latest of touch events is defined.
https://github.com/whatwg/dom/commit/246ff37fed31680acadbfc96666e519bdda3c24e
(In reply to Anne from comment #1) > > How we can deduce from IDL, that some interface are not available in global. > > Look: > > > > callback interface NodeFilter << have access (and example we can read > > constant) > > callback interface EventListener << don't have access > > > > There exist some extended attribute that inform about this? Maybe > > [NoInterfaceObject] do this? > > Not sure, file a separate bug? There is no need, I found answer in Web IDL: http://heycam.github.io/webidl/#dfn-interface-object > > Why in table for Document.createEvent(interface): > > http://dom.spec.whatwg.org/#dom-document-createevent > > > > we have [UIEVENTS] ref for some events, not [DOM3EVENTS]? And why TouchEvent > > don't reffer to any spec (is markered)? > > DOM3EVENTS should be replaced by something called UIEVENTS down the line. > It's not clear where the latest of touch events is defined. Hmm now UIEVENTS was cleaned and only extended DOM3EVENTS: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#h2_abstract Planning to replace DOM3EVENTS is still valid? About touch events I see only three: http://www.w3.org/TR/touch-events/ https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html https://dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html Extension is no longer being developed, Recomendation mention something about initTouchEvent property, but don't defined them (draft doesn't add anything new in this case). So we can suppose that this Recomendation allows for the possibility to create TouchEvent event by Document.createEvent() and can be use as refer. Any other sources exist for touch events?
Not sure how IDL clarifies matters there. UIEVENTS has to fully replace DOM3EVENTS. We should not accept delta specifications. They are terrible. As for touch events, not sure. I guess I'll wait for it to be picked up again before updating that section.
This is done, right?
Yep, you can close.