- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 06 Apr 2009 11:19:56 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 --- Comment #5 from Henri Sivonen <hsivonen@iki.fi> 2009-04-06 11:19:56 --- (In reply to comment #4) > Could I get this clear? You are asking for W3C specifications to change in such > a way that they match the behaviour of a Microsoft-defined API? I don't know of any Microsoft origins of document.evaluate(). It seems that Netscape was the first to expose it to HTML documents, and Netscape also contributed the editor for the relevant DOM Level 3 spec. The origin doesn't matter, though. Gecko, WebKit and Opera support the API and expose it to Web content, so breaking existing content that uses the API would not be good. It is easier to change specs than to change existing content. I chatted with Alexey Proskuryakov about this on IRC. The following points came up: * It is desirable to put the change in the XPath evaluation phase, because this way the XPath expression compiler doesn't need ahead of evaluation time whether a given name expression will be tested against an element or against an attribute. * This way, it is still possible to match a no-namespace element node should an author want to actually match one. (This is mostly theoretical.) * DOM Level 3 XPath is defined in terms of XPath 1.0 and browsers implement XPath 1.0. XPath 2.0 is incompatible with XPath 1.0, so browsers can't implement XPath 2.0 for the document.evaluate() API. Therefore, XPath 2.1 probably isn't the right place to specify this for the purposes of the existing API unless XPath 2.1 restores compatibility with existing XPath 1.0 content. I'll follow up with the Web Apps WG that now manages the maintenance of DOM specs. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 6 April 2009 11:20:07 UTC