In the released category we have Opera 9. It has several new developer features:
opacity;
<canvas>;
Audio;
contenteditable (and designMode);
xml:id;
-o-text-overflow:ellipsis;
:default, :valid, :invalid, :in-range, :out-of-range, :required, :disabled et cetera are now supported and can be used together with Web Forms 2;
iframe and object;
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.
Just curious: are the Canvas 3D extensions available in this release?
Opera 9 is a fantastic product for developers and users. I look forward to more stuff from Opera!
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.
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?
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.
woot, a feature just for me :*
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);
//f.contentWindow.document.body.style.backgroundColor = "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.
;-)
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.
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:
DocumentSelector interface to NodeSelector
NodeSelector interface to Element
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. ;-)
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.
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.
and to answer your questions:
obj.match('bar') is equilvalent to obj.getElementsByTagName('bar')[0]
obj.match('#bar') finds the first descendant of obj that has an id of "bar"
obj.match('> bar') finds the first child element of obj that has a tag name of "bar"
obj.match(':root') as you say matches nothing unless obj is the document itself
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.
There are people that think that none of this is useful. ;-)
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).
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.
Both your proposals, as I understand them, don’t allow checking if the current node matches :link for example. Now that might be ok…
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.