Anne van Kesteren

Released and published

In the released category we have Opera 9. It has several new developer features:

In the published category we have the second working draft of XMLHttpRequest. If you are planning to review the draft I suggest you read the editor’s draft of XMLHttpRequest instead. Selectors API has also been published, as a first public working draft. A review version is also available.


  1. Just curious: are the Canvas 3D extensions available in this release?

    Posted by Sjoerd Visscher at

  2. Opera 9 is a fantastic product for developers and users. I look forward to more stuff from Opera!

    Posted by Ethan Poole at

  3. I think the Selectors API needs more work. I’d like to see the match/matchAll methods applied to elements too. It would be nice if the returned resultset were filterable in the same way (i.e. StaticNodeList implements match/matchAll).

    lioreans comments deserve more atention.

    This spec seems a little rushed.

    Posted by Dean Edwards at

  4. Although -o-text-overflow:ellipsis is welcome, I have yet to find a means to revert overflow styling once it has been applied. Is this a known limitation is use of this CSS extension for Opera 9.0, or have I overlooked the obvious?

    Posted by someguy at

  5. Dean, actually, his comments have been discussed on public-webapi before publication. I think a day or so after he made them on his weblog. The comments you are making now are already noted in the open issues section. However, it’s unclear how these proposals would work given that the Selectors specification has not defined such concepts and we don’t want to introduce concepts that hinder the evolution of that language (that would be incompatible with future versions). StaticNodeList is like to be replaced with Array or DOMArray once there is a draft for that.

    It’s also unclear to me how you can qualify the current specification (it’s just a draft, as noted) as being rushed. In my opinion, being the editor, it’s actually quite mature and detailed. According to implementors it’s also quite implementable the way it stands now. The intend was also not to do something complex as you seem to desire, but rather providing two simple methods for retrieving Element nodes as the abstract states. Besides all that, this is the first public working draft (not stable at all). They don’t have to be perfect and can be used to let the public know it is being worked upon so that people like you (and others) can comment on it.

    Posted by Anne at

  6. woot, a feature just for me :*

    Posted by Tino Zijdel at

  7. contentEditable:
    When I enable contentEditable, all my IFRAMEs' contents goes invisible. I have the following boilercode for my IFRAMEs:
    f = document.createElement("iframe"); f.setAttribute("src",'about:blank'); f.setAttribute("id",id); document.body.appendChild(f); setTimeout('styleframe(\''+ id +'\',\''+ content +'\');', 0); function styleframe(id,content) { var f; f = document.getElementById(id); // = "transparent"; f.contentWindow.document.body.innerHTML = content; } This gets executed with a script-tag within the body of the main document. And then I enable editing (with some event):
    document.getElementById("wrapper").contentEditable = "true";

    Voilá! All my IFRAMEs which were displaying fine - just goes blank. *Blip*
    Debug-style outlines still show they are there, and alert'ing outerHTML on the BODY-tags still shows the content sources are intact.

    Too bad. I was so looking forward to using contentEditable with Opera, although the non-appearing images in the scripted IFRAMEs also is a showstopper (trying to open image by right-clicking placeholder-icon says address type is unknown/unsupported and properties says 0x0 px of unknown type - hopefully transparent PNGs no less). Guess I will have to wait for some hackish pointers, or some bugfix updates anyways.


    Posted by Rune Karlsen at

  8. contentEditable onClick-events:
    It seems one must also double-click within the edit-enabled element to get the registered onClick-event to fire. Seems a hassle if looking for caret-position and possible inserts etc.

    Posted by Rune Karlsen at

  9. Anne, I can’t see why you think that adding those methods to other objects is "unclear how they would work". To make it clear:

    1. Rename the DocumentSelector interface to NodeSelector
    2. apply the NodeSelector interface to Element
    3. apply the NodeSelector interface to StaticNodeList

    If you mean that this is difficult to implement then that is another matter of course.

    And this does seem rushed to me. You are about to break all sorts of records for publishing a W3C spec at this rate. ;-)

    Posted by Dean Edwards at

  10. No, that’s not the problem. The problem is that the concept of having a subtree is not part of Selectors. You always select within the whole document. Not a subtree of a document. It’s not clear how those selectors would affect the element you apply them on. For example, does obj.match('bar') create some kind of descendant combinator between obj and bar? What does obj.match('#bar') mean? Can you do obj.match('> bar')? Would obj.match(':root') never match anything? The CSS WG has not defined such concepts and therefore I don’t think it would be a good idea to add that at this stage.

    Now it might be a good idea to rename the interface to allow such things in the future without having to create a new interface or letting DocumentSelector be implemented by objects implementing Element which just looks wrong.

    Posted by Anne at

  11. Anne, these concepts exist in XPath. An XPath query can take a context node to evaluate against. I'm suggesting a similar thing for CSS based queries. I don't know about the politics of the CSS group but I'm happy to give them time to decide about this issue rather than push out an incomplete spec for the DOM.

    Posted by Dean Edwards at

  12. and to answer your questions:

    1. obj.match('bar') is equilvalent to obj.getElementsByTagName('bar')[0]
    2. obj.match('#bar') finds the first descendant of obj that has an id of "bar"
    3. obj.match('> bar') finds the first child element of obj that has a tag name of "bar"
    4. obj.match(':root') as you say matches nothing unless obj is the document itself

    Posted by Dean Edwards at

  13. I’m aware that XPath has a concept of context nodes. However, Selectors has not. That’s the whole point I’m making here.

    There is one other way to solve it and that is to say that when match or matchAll is invoked on an Element node it does exactly the same thing as if it was invoked on Document, but all nodes that are not descendants of that Element are filtered out of the result set. I’m not sure how useful that would be though.

    Posted by Anne at

  14. There are people that think that none of this is useful. ;-)

    Posted by Dean Edwards at

  15. Here's a simple implementation of Element.match(path): Give the element a unique ID, then the result is the same as Document.match("#unique-id " + path).

    Posted by Sjoerd Visscher at

  16. Ehm, it needs to be a little more complex: you have to split the path up in selectors (splitting on commas), then prefix every selector and then join them back together with commas between them.

    Posted by Sjoerd Visscher at

  17. Both your proposals, as I understand them, don’t allow checking if the current node matches :link for example. Now that might be ok…

    Posted by Anne at

  18. interface DocumentSelector {
      Node            match(in DOMString selectors, in XPathNSResolver nsresolver);
      StaticNodeList  matchAll(in DOMString selectors, in XPathNSResolver nsresolver);
    + NodeFilter      nodeFilterFromSelector(in DOMString selectors, in XPathNSResolver nsresolver);

    When scripting, it is dynamically creating Function that is difficult, i think the method like DocumentSelector#nodeFilterFromSelector is indispensable. But aggregating Nodes is not so difficult, i do not think Element#(match|matchAll) is inevitable.

    Posted by albert at