ISSUE-106 (mouse capture): Consider adding mouse capture/release API [DOM3 Events]
ISSUE-106 (mouse capture): Consider adding mouse capture/release API [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/106 Raised by: Doug Schepers On product: DOM3 Events It's sometimes desirable to redirect all events of a certain type to a particular element (for example, when dragging a scrollbar or a shape, you may want to allow the mousemove events to all be directed to that element). To do this, IE implements SetCapture, ReleaseCapture, and GetCapture: * http://msdn.microsoft.com/en-us/library/ms646262%28VS.85%29.aspx * http://msdn.microsoft.com/en-us/library/ms646261%28VS.85%29.aspx * http://msdn.microsoft.com/en-us/library/ms646257%28VS.85%29.aspx Mozilla has recently added this as well: http://enndeakin.wordpress.com/2009/08/27/mouse-capturing/ We should consider adding this to DOM3 Events or DOM4 Events.
Re: Using progress events for other purposes
On Mon, 19 Oct 2009 06:43:18 +0200, Ian Hickson wrote: On Mon, 19 Oct 2009, Charles McCathieNevile wrote: OK, I'll work on it to try and get an editor's draft out tomorrow. My rough idea is that you can send an event which has lengthComputable false and totalItems / loadedItems, and IFF they have lengthComputable true then the loaded and total refer to the particular item - (does itemCount start from zero or one?) So in a hypothetical system that gives progress for multiple large files in a row, you can't have a case where some of the files have unknown sizes? Yes, you can. You also don't necessarily need to get the things in sequential order, actually. (At least the way it is in my head - I ahve to turn it into words on the web still). cheers Chaals ISSUE-105 -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
DOM4 Core (was: childElements, childElementCount, and children)
Hi, Folks- John Resig wrote (on 10/18/09 1:50 PM): They already do. Which casts some amount of doubt on Maciejs argument that it was too performance heavy to implement in WebKit. :) Well, it does work in HTML, but not in SVG [1]... which may or may not be desirable, since .children returns an HTMLCollection, and SVG elements are not HTML elements. p.s. It also works in Opera and IE. Sure, but I mentioned that already. :) (Note to self... write pithier emails.) Yeah, .children is already the de facto standard here - implemented in every major browser. It's a real shame that it hasn't (and won't?) make it in to a spec, especially considering that it's already implemented everywhere. Nothing to stop it from being specified, but I doubt that Internet Explorer will change its behavior, since that will likely break existing Web content (IE team, thoughts?). I generally agree with Garrett here, so I've followed up on my early promise to specify this by starting the DOM4 Core spec [2], and included 'children' as an HTMLCollection (to satisfy the case that John rightly describes), and 'childElements' as a new ElementCollection (to supply a more progressive interface that authors can rely on predictably). The WebApps WG is explicitly chartered [3] to produce the DOM4 Core spec, along with a new version of Element Traversal: [[ Element Traversal 2.0 an extension of Element Traversal 1.0 to provide a nodelist interface ]] However, I think it makes more sense at this point to simply include these new attributes in DOM4 Core, along with the indispensable bits of Element Traversal (that is, everything except the childElementCount, which is superfluous to childElements.length). I'd like this to also contain the work that Simon Pieters did on Web DOM Core [4], if he's willing to have that folded in (I left it out pending word from him... he's BCCed on this message). I'm happy to help editing this document, but I would be even happier if someone else would also step up to serve as co-editor. [1] http://www.schepers.cc/w3c/webapps/elementtraversal/tests/et-children.svg (cf. .html and .xhtml) [2] http://dev.w3.org/2006/webapi/DOM4Core/DOM4Core.html [3] http://www.w3.org/2008/webapps/charter/ [4] http://simon.html5.org/specs/web-dom-core Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Using progress events for other purposes
On Mon, 19 Oct 2009, Charles McCathieNevile wrote: > > OK, I'll work on it to try and get an editor's draft out tomorrow. My > rough idea is that you can send an event which has lengthComputable > false and totalItems / loadedItems, and IFF they have lengthComputable > true then the loaded and total refer to the particular item - (does > itemCount start from zero or one?) So in a hypothetical system that gives progress for multiple large files in a row, you can't have a case where some of the files have unknown sizes? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Using progress events for other purposes
On Mon, 19 Oct 2009 05:20:49 +0200, Simon Pieters wrote: On Mon, 19 Oct 2009 01:50:00 +0200, Charles McCathieNevile wrote: That would work for appcache, yeah. We'd need to make sure the spec was clear about what the other attributes should be set to in this situation, too, since in appcache they is only one event per file. OK, I'll work on it to try and get an editor's draft out tomorrow. My rough idea is that you can send an event which has lengthComputable false and totalItems / loadedItems, and IFF they have lengthComputable true then the loaded and total refer to the particular item - (does itemCount start from zero or one?) Isn't itemCount redundant with loadedItems? Yep - it is what I was thinking of calling loadedItems before, and snuck back into my brain. (I prefer the loadedItems / totalItems names because they match the loaded/total attributes, and because they go very well with the 70s-style ribbons in the spokes of my bike wheels). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Using progress events for other purposes
On Mon, 19 Oct 2009 01:50:00 +0200, Charles McCathieNevile wrote: That would work for appcache, yeah. We'd need to make sure the spec was clear about what the other attributes should be set to in this situation, too, since in appcache they is only one event per file. OK, I'll work on it to try and get an editor's draft out tomorrow. My rough idea is that you can send an event which has lengthComputable false and totalItems / loadedItems, and IFF they have lengthComputable true then the loaded and total refer to the particular item - (does itemCount start from zero or one?) Isn't itemCount redundant with loadedItems? -- Simon Pieters Opera Software
Re: Using progress events for other purposes
On Mon, 19 Oct 2009 00:08:38 +0200, Ian Hickson wrote: On Sun, 18 Oct 2009, Charles McCathieNevile wrote: I propose to add the attributes totalItems and loadedItems to preogress events, as a way of dealing with use cases like showing progress in downloading an application cache. This allows for firing progress events which have total/loaded values on individual items, by defining them as referring to the current item in the presence of the totalItems / loadedItems. Does that work for the use case? That would work for appcache, yeah. We'd need to make sure the spec was clear about what the other attributes should be set to in this situation, too, since in appcache they is only one event per file. OK, I'll work on it to try and get an editor's draft out tomorrow. My rough idea is that you can send an event which has lengthComputable false and totalItems / loadedItems, and IFF they have lengthComputable true then the loaded and total refer to the particular item - (does itemCount start from zero or one?) cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Using progress events for other purposes
On Sun, 18 Oct 2009, Charles McCathieNevile wrote: > > I propose to add the attributes totalItems and loadedItems to preogress > events, as a way of dealing with use cases like showing progress in > downloading an application cache. This allows for firing progress events > which have total/loaded values on individual items, by defining them as > referring to the current item in the presence of the totalItems / > loadedItems. > > Does that work for the use case? That would work for appcache, yeah. We'd need to make sure the spec was clear about what the other attributes should be set to in this situation, too, since in appcache they is only one event per file. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)
> They already do. Which casts some amount of doubt on Maciejs argument > that it was too performance heavy to implement in WebKit. :) > > / Jonas > > p.s. It also works in Opera and IE. Yeah, .children is already the de facto standard here - implemented in every major browser. It's a real shame that it hasn't (and won't?) make it in to a spec, especially considering that it's already implemented everywhere. --John
Re: Using progress events for other purposes
On Sun, 27 Sep 2009 21:04:04 +0200, Charles McCathieNevile wrote: On Sun, 27 Sep 2009 20:20:52 +0200, Ian Hickson wrote: On Sun, 27 Sep 2009, Charles McCathieNevile wrote: The alternative is to think now about extending Progress Events to deal with non byte-length progress (e.g. a series of transactions, each of which is very rapid alone but which add up to minutes). My preference would be to create new attributes for this case rather than overload the total/loaded attributes. I propose to add the attributes totalItems and loadedItems to preogress events, as a way of dealing with use cases like showing progress in downloading an application cache. This allows for firing progress events which have total/loaded values on individual items, by defining them as referring to the current item in the presence of the totalIems / loadedItems. Does that work for the use case? I have raised ISSUE-105 for this question. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)
On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers wrote: > So, rather than dwell on an admittedly imperfect spec, I personally suggest > that we urge WebKit developers to implement .children and .children.length, > in the anticipation that this will be in a future spec but can be useful to > authors today. They already do. Which casts some amount of doubt on Maciejs argument that it was too performance heavy to implement in WebKit. :) / Jonas p.s. It also works in Opera and IE.
childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)
Hi, Garrett-
Garrett Smith wrote (on 10/17/09 11:06 PM):
It has been so long that I cannot remember (over 8 years since I even
tried using that). It is a useless, pointless method that tells little
about the result of calling, say: getAttribute("checked").
I read Nicholas was struggling with that:
http://www.nczonline.net/blog/2007/05/08/safari-lies/
The rationale I've heard for implementations reporting inaccurately is
that features with too many "subfeatures" are ambiguous in how they
should be reported (how do you report support for "UIEvents" if you
implement some but not all event types defined for that interface
module?). I've tried to address this in DOM3 Events by allowing a finer
granularity of feature strings [1].
What is missing from Element Traversal API is a convenience property
to get child elements.
Wholeheartedly agreed.
There is a childElementCount. What is the
purpose of childElementCount?
One comment response from you (Doug Schepers):-
| While many uses of Element Traversal do not require this attribute, I
| speak from personal developer experience when I confirm that it is
| useful.
Does not describe the problem that "childElementCount" solves, nor
does it solve the problem of getting the childElements.
One use case is shown in the spec itself [2]; childElementCount allows
the author to find out how many element children there are without
looping through twice (). Since there were strong objections to adding
.childElements (as I originally suggested), I struck a compromise.
Usage patterns
for childElements are quite common; you want the elements, no text
nodes, no comments; only elements. This problem is trivially solved by
the one missing property: childElementCount.
I assume you mean childElements, not childElementCount.
This is not the first time childElements has been requested and
childElementCount has been questioned. it has been mentioned on
various w3c lists, on comp.lang.javascript, and on ejohn.org, numerous
times as far back as January 2008. That did not made it into the
specification. Here are a few:
No, not the first time at all... and farther back than that, to March
2007. I believe the first time it was mentioned was when I first
suggested the feature [3], back when I took over as editor (note, Chaals
checked it in and sent the message [4] to the list with the open
question, since I was busy at the time with my day job).
I readily admit that childElementCount would have been obviated by
childElements.length. I also agree that in a perfect world,
childElements would have been included. But some good arguments against
it were made (by Björn Höhrmann [5], Maciej [6], and the JSR folks); one
of the arguments from the mobile community was that such lists were too
computationally and memory intensive for some of their devices, and that
their code bases were optimized in a different direction. Finally, this
feature was quite old even when I took over the spec, and had been
shipping on devices for over a year, so I didn't want to change it too much.
There was a lot of history to this spec, and a lot of discussion; if you
read back through all of the email discussion and telcon/f2f minutes and
spec revisions, back to when it was part of SVG Tiny 1.2, you may
appreciate that there was no choice that was right for all stakeholders.
I suspect that I would make different choices now, but the climate at
the time was to ship the spec as it was, and revisit it in v2... in the
meantime, .children is implemented widely (IE, FF, Opera, but not
Safari/Chrome), so I reckon that's what we will standardize, either in
Element Traversal v2, or probably more sensibly in DOM4 Core/Web DOM Core.
So, rather than dwell on an admittedly imperfect spec, I personally
suggest that we urge WebKit developers to implement .children and
.children.length, in the anticipation that this will be in a future spec
but can be useful to authors today.
[1]
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#feature-detection
[2] http://www.w3.org/TR/ElementTraversal/#example-3.2
[3]
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/ElementTraversal/publish/ElementTraversal.html?rev=1.2&content-type=text/html;%20charset=iso-8859-1
[4] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0064.html
[5] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0065.html
[6] http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0013.html
p.s. More history for those who care: I was tricked into editing this
spec by Nandini from Sun, who had inherited the action from Robin
Berjon, and who asked me to be her "co-editor" at a Web API WG F2F at
MIT... little did I know at the time that I'd be the sole person to take
the spec from the meager sketch Robin had left us with, through all the
LC comments and into CR, and write the entire test suite on a sleepless
flight to a TPAC in Mandelieu to get us to PR and Re
