http://blog.gmane.org/gmane.comp.web.dom.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.web.dom.general/4434 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=17058 Summary: Namespace of document.createElement elements. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;annevk.nl ReportedBy: nicholas.stimpson&lt; at &gt;ntlworld.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org createElement has the namespace of the element being set to the HTML namespace. Shouldn't that only be the case if the context node is an HTML document? </pre> bugzilla< at >jessica.w3.org 2012-05-15T10:59:35 http://comments.gmane.org/gmane.comp.web.dom.general/4428 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=17044 Summary: Cloning algorithm doesn't indicate that the "already started" flag needs to be cloned for script elements Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Core AssignedTo: annevk&lt; at &gt;annevk.nl ReportedBy: hsivonen&lt; at &gt;iki.fi QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org If you read the "clone" algorithm in the DOM Core spec, you won't find a normative statement saying that you have to clone the "already started" flag on script elements. To make sure that readers of the spec find the right normative statement, please provide an informative pointer to http://www.whatwg.org/specs/web-apps/current-work/#already-started Please weasel in some language to suggest that SVG script elements should work consistently with HTML script elements in this regard. </pre> bugzilla< at >jessica.w3.org 2012-05-14T08:22:59 http://comments.gmane.org/gmane.comp.web.dom.general/4425 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16919 Summary: Make element traversal members available on more nodes Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: simonp&lt; at &gt;opera.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org If you have foo and want the next element sibling, it makes sense to just use nextElementSibling even if foo is not an element. Currently nextElementSibling is only defined on Element. The same argument goes for the other element traversal members. Specifically, I think the following makes sense: children firstElementChild lastElementChild childElementCount on Document, DocumentFragment, Element previousElementSibling nextElementSibling on DocumentType, Element, CharacterData I think this is similar to the new mutation methods (prepend() et al). </pre> bugzilla< at >jessica.w3.org 2012-05-03T14:25:49 http://comments.gmane.org/gmane.comp.web.dom.general/4422 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16910 Summary: Typo in MutationObserver constructor specification Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: waldron.rick&lt; at &gt;gmail.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org Created attachment 1128 --&gt; https://www.w3.org/Bugs/Public/attachment.cgi?id=1128 Screen shot Reads: "return it, and append it object to the scripting environment's list of MutationObserver objects." "append it object to the" is the specifically erroneous portion </pre> bugzilla< at >jessica.w3.org 2012-05-02T21:55:34 http://comments.gmane.org/gmane.comp.web.dom.general/4415 <pre>The DOM spec defines exception types for each of the DOMException codes. One of them is "SyntaxError", which corresponds to the SYNTAX_ERR code. But we also have the built-in SyntaxError exception, the one whose instances have [[Prototype]] == SyntaxError.prototype. (It would be nice if we could merge these somehow, but I think that would be difficult, since we can't have some DOMExceptions inheriting from SyntaxError.prototype and others from Error.prototype.) If they do remain separate, then should new specs that are throwing an exception due to a syntax error prefer to throw the "SyntaxError" DOMException or the built-in SyntaxError? I think I have a slight preference for the built-in one, just so we can avoid code properties in a few more places. </pre> Cameron McCormack 2012-04-26T23:49:20 http://comments.gmane.org/gmane.comp.web.dom.general/4414 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16847 Summary: Re-dispatching trusted events Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Keywords: LC Severity: normal Priority: P2 Component: DOM3 Events AssignedTo: travil&lt; at &gt;microsoft.com ReportedBy: travil&lt; at &gt;microsoft.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, annevk&lt; at &gt;opera.com, jrossi&lt; at &gt;microsoft.com, www-dom&lt; at &gt;w3.org As discussed here: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0295.html The spec has several legacy places where it forbids dispatching trusted events. These need to be corrected in order to align with DOM4: </pre> bugzilla< at >jessica.w3.org 2012-04-24T23:44:34 http://comments.gmane.org/gmane.comp.web.dom.general/4408 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16759 Summary: intersectsNode step 4 should return true, not throw Product: WebAppsWG Version: unspecified Platform: PC URL: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.ht ml#dom-range-intersectsnode OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: Olli.Pettay&lt; at &gt;gmail.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org Per the current spec intersectsNode may throw NotFoundError in step 4, yet there is a comment that it doesn't make sense. The API should be just fixed. </pre> bugzilla< at >jessica.w3.org 2012-04-17T11:09:21 http://comments.gmane.org/gmane.comp.web.dom.general/4405 <pre>2012-04-05 working draft of DOM4 (same in editor's draft) introduced: http://www.w3.org/TR/dom/ interface Document { NodeIterator createNodeIterator(Node root, optional unsigned long whatToShow = SHOW_ALL, optional NodeFilter? filter = null); }; SHOW_ALL is 0xFFFFFFFF, but it seems such use of named constant as default value is not allowed by WebIDL grammar, either working draft or editor's draft. Which of the following is true? 1. WebIDL specification should be updated. 2. DOM4 specification should be updated. 3. It is okay for DOM4 specifcation WebIDL to be non-conforming. It is for illustrative purpose. </pre> Seo Sanghyeon 2012-04-14T09:48:23 http://comments.gmane.org/gmane.comp.web.dom.general/4404 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16713 Summary: locate a namespace returns value of no-namespace xmlns="" attribute Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: simonp&lt; at &gt;opera.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#locate-a-namespace "or whose namespace prefix is null and local name is "xmlns"" maybe we should ignore xmlns attributes in no namespace. var elm = document.createElementNS('foo', 'x:y'); elm.setAttribute('xmlns', 'bar'); // no-namespace attribute elm.lookupNamespaceURI(null); // bar per spec </pre> bugzilla< at >jessica.w3.org 2012-04-12T11:42:46 http://comments.gmane.org/gmane.comp.web.dom.general/4403 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16712 Summary: locate a namespace returns default namespace even if prefix is non-null Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: simonp&lt; at &gt;opera.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#locate-a-namespace "or whose namespace prefix is null and local name is "xmlns"" should only apply if /prefix/ is null. &lt;x xmlns="foo"/&gt;.lookupNamespaceURI('bar') returns foo per spec currently. </pre> bugzilla< at >jessica.w3.org 2012-04-12T11:38:17 http://comments.gmane.org/gmane.comp.web.dom.general/4401 <pre>http://www.w3.org/TR/DOM-Level-3-Events/#events-focusevent-doc-focus doesn't say whether to fire focus/blur-related events on the documentt/documentElement/body if nothing inside the document is focusable. Relevant WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=83566. Test case: https://bug-83566-attachments.webkit.org/attachment.cgi?id=136545 . There are three cases: 1. No editable content. 2. contentEditable (i.e. focusable) body element. 3. contentEditable (i.e. focusable) html element. In all browsers, in all three test cases, if you click on the documentElement or on the body element, document.activeElement points to the body element (and in the contentEditable cases, you get a blinking cursor inside the body element). Given that, I think focus events should fire on the document, documentElement and body elements in all three cases. This is the IE9+ behavior. -WebKit only does this if you click on a focusable element in the frame. -Opera does the WebKit behavior, except doesn't fire focusin/focus in some cases (looks like a bug since focusout/blur are fired). -Gecko fires only on the document itself if there are no focusable elements, but otherwise, does the IE behavior (Gecko only ever fires focus/blur though, no focusin/focusout). On the other hand, if script explicitly focuses the documentElement, then we should only fire focus-related events on the documentElement and the document, since document.activeElement actually points to the documentElement in that case. In short, to keep the platform sane, I think focus-related events should match how we set document.activeElement. Curious to hear what other browser vendors think before we change WebKit to match IE. Ojan </pre> Ojan Vafai 2012-04-10T21:55:03 http://comments.gmane.org/gmane.comp.web.dom.general/4400 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16682 Summary: Don't throw for ]]&gt; with serializeAsCDATA Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: Ms2ger&lt; at &gt;gmail.com ReportedBy: simonp&lt; at &gt;opera.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org http://html5.org/specs/dom-parsing.html#concept-serialize-xml - instead of throwing for ]]&gt; in text node with serializeAsCDATA, i think you should serialize a cdata section up to the first "]]&gt;" not including the "&gt;", then emit the rest (including the "&gt;") as text </pre> bugzilla< at >jessica.w3.org 2012-04-10T13:16:17 http://comments.gmane.org/gmane.comp.web.dom.general/4398 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16680 Summary: DOMTokenList assumes clean underlying string Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: w3c&lt; at &gt;marcosc.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org The DOMTokenList assumes that the underlying string is always "clean" in that it contains no spaces at the start and at the end or in between. However, in the case of HTML's class attribute, the string can be "dirty", in that the underlying string is derived from a the class attribute. Consider: element.className = " class1 \n class2 \t class3 \t \n" In order to get a clean string, the spec needs to define something the following, so whitespace is removed: //Splits the underlying string into a list of tokens function splitUnderlyingString() { var underString = this.toString(); var cleanString = underString.replace(/\s\s+/g, "\u0020").trim(); return cleanString.split("\u0020"); } Implementation already do the above, it seems. But the above is not clear in the spec. </pre> bugzilla< at >jessica.w3.org 2012-04-10T10:46:10 http://comments.gmane.org/gmane.comp.web.dom.general/4389 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16648 Summary: Remove "xmlns" and "xml" checks from setAttributeNS()? Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: annevk&lt; at &gt;opera.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: bzbarsky&lt; at &gt;mit.edu, mike&lt; at &gt;w3.org, simonp&lt; at &gt;opera.com, jonas&lt; at &gt;sicking.cc, Ms2ger&lt; at &gt;gmail.com, www-dom&lt; at &gt;w3.org, ojan&lt; at &gt;chromium.org Since setAttribute() does no checks for them (see bug 16493), shall we remove them from setAttributeNS() or is it not worth the hassle? </pre> bugzilla< at >jessica.w3.org 2012-04-06T09:12:45 http://comments.gmane.org/gmane.comp.web.dom.general/4387 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16644 Summary: Invoking MutationObservers should always clear transient registrations even if no records are to be delivered Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: adamk&lt; at &gt;chromium.org QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, Olli.Pettay&lt; at &gt;gmail.com, www-dom&lt; at &gt;w3.org, rafaelw&lt; at &gt;chromium.org Just noticed while investigating GC behavior in WebKit that our implementation did this incorrectly, only clearing registrations if there are records to deliver. Turns out that concept-mo-invoke has the same bug: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-mo-invoke </pre> bugzilla< at >jessica.w3.org 2012-04-05T19:44:10 http://comments.gmane.org/gmane.comp.web.dom.general/4385 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16638 Summary: Define who owns what with MutationObserver Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: Olli.Pettay&lt; at &gt;gmail.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, jonas&lt; at &gt;sicking.cc, www-dom&lt; at &gt;w3.org, adamk&lt; at &gt;chromium.org, rafaelw&lt; at &gt;chromium.org Should MutationObserver own the nodes it is observing? I think not. If JS doesn't have a pointer to the node, it can't modify it. But if the original observe target is deleted, what should happen to the transient observers? I think they should still work (until the end of the microtask). That way GC/CC behavior isn't visible to the API user. Then MutationObserver object itself... I think the only way to hide GC/CC behavior is to keep MutationObserver object alive as long as the node(s) it is observing is/are alive. </pre> bugzilla< at >jessica.w3.org 2012-04-05T06:33:23 http://comments.gmane.org/gmane.comp.web.dom.general/4382 <pre>BCC: www-dom CC: public-webapps The original proposal to drop textInput included that beforeInput/input would have a data property of the plain text being inserted. Aryeh, how does that sound to you? Maybe the property should be called 'text'? 'data' is probably too generic. On Wed, Apr 4, 2012 at 11:01 AM, Andrew Oakley &lt;andrew&lt; at &gt;ado.is-a-geek.net&gt;wrote: </pre> Ojan Vafai 2012-04-04T19:07:18 http://comments.gmane.org/gmane.comp.web.dom.general/4378 <pre>The textInput event seems to have been removed from the latest versions of DOM 3 Events but I can't find any real explanation as to why it disappeared, or if it has been replaced by anything. I can find lots of suggestions for renaming it or merging it with other events but that isn't the change that has been made. Are browsers on devices without keyboards supposed to fake up keyboard events somehow? I think that would be very awkward, much more so than doing a fake click event when something is activated. </pre> Andrew Oakley 2012-04-04T16:54:46 http://comments.gmane.org/gmane.comp.web.dom.general/4373 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16608 Summary: Algorithms should rethrow the exception Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: Ms2ger&lt; at &gt;gmail.com ReportedBy: simonp&lt; at &gt;opera.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org "If this threw an exception, then terminate these steps." Both the innerHTML setter algorithm and the fragment parsing algorithm have this step. This means that setting innerHTML will silently do nothing if the XML fragment parsing algorithm throws. The fragment parsing algorithm should rethrow, and the innerHTML setter should rethrow. (The produce an XML serialization algorithm says "If this threw an exception, allow that exception to propagate out from this algorithm" which seems fine.) </pre> bugzilla< at >jessica.w3.org 2012-04-03T10:34:52 http://comments.gmane.org/gmane.comp.web.dom.general/4372 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16606 Summary: MutationObserver doesn't provide a safe way to suspend &amp; resume observation Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: rafaelw&lt; at &gt;chromium.org QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org It's a common use to want to have the mutation callback not report any changes it makes in the following invocation. This is trivially accomplished by calling disconnect() at the beginning of the callback and observe() immediately before exiting. disconnect() clears any queue records, but this is safe inside a mutation callback because the observer has just been delivered all mutations and is guaranteed that no other actor could have made new ones. However, if the observer would like to ignore changes which are made outside the mutation callback (say in response to a XHR callback), suspending observation by calling disconnect/observe risks losing mutation records already queued. [This came up via a user of the MutationSummary library whose use case is synchronizing a JSON structure with DOM. The problem arises when trying to ignore changes made by applying remote JSON changes to the DOM] It seems to me there are two approaches to this: 1) Add an explicit suspect/resume API to MutationObserver which does what you might guess. 2) Add some sort of pullMutations() call which would allow code to synchronously fetch any queued records, thus making it safe to use disconnect/observe. Editorial: 1) Has the benefit of being a fairly clear API given the use and might also allow the user agent to better optimize usage because what's needed is actually being expressed. However (as Adamk noted), it has the down side that suspend() may be confused with disconnect() and cause the DOM to be doing alot of unneeded work 2) Is less direct in its form, but it addresses this use case, and also another use which we've suspected we'd eventually need: the desire to "pull" mutations because you'd like to synchronize your state one an imperative API call. My $.02: I prefer adding something like pullMutations() because I think we'll need it for other reasons, and it kills two birds with one stone. Also, as much as I like the directness of suspend/resume, I'm worried about pages calling suspend and never calling resume. Opinions? </pre> bugzilla< at >jessica.w3.org 2012-04-03T00:22:28 http://comments.gmane.org/gmane.comp.web.dom.general/4371 <pre>https://www.w3.org/Bugs/Public/show_bug.cgi?id=16571 Summary: Define order for named properties Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM AssignedTo: annevk&lt; at &gt;opera.com ReportedBy: Ms2ger&lt; at &gt;gmail.com QAContact: public-webapps-bugzilla&lt; at &gt;w3.org CC: mike&lt; at &gt;w3.org, www-dom&lt; at &gt;w3.org &lt;http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration&gt; has | If the object supports named properties, then the object’s supported | property names are enumerated next, in the order given in the | definition of the set of supported property names. We don't give such an order. </pre> bugzilla< at >jessica.w3.org 2012-03-29T18:01:35 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.dom.general