Re: Testing Progress Events and CR
On Wed, 22 Jun 2011 17:36:07 +0200, Anne van Kesteren ann...@opera.com wrote: I just checked in the proposal https://bitbucket.org/ms2ger/dom-core/changeset/b9bb17789db9 into DOM Core but I suspect it needs some refining and reviewing. I suspect we need another Progress Events LC for this as technically it is a new feature :/ I updated Progress Events as well since it was not much work and then you can get an idea of what is changed since the latest WD: http://dev.w3.org/2006/webapi/progress/ All the changes have been in section 4 and in the terminology section. -- Anne van Kesteren http://annevankesteren.nl/
Re: Testing Progress Events and CR
On Jun/23/2011 6:45 AM, ext Anne van Kesteren wrote: On Wed, 22 Jun 2011 17:36:07 +0200, Anne van Kesteren ann...@opera.com wrote: I just checked in the proposal https://bitbucket.org/ms2ger/dom-core/changeset/b9bb17789db9 into DOM Core but I suspect it needs some refining and reviewing. I suspect we need another Progress Events LC for this as technically it is a new feature :/ In case people aren't following the above discussion in www-dom, note the above changset has been applied to DOM Core: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-event-init I updated Progress Events as well since it was not much work and then you can get an idea of what is changed since the latest WD: http://dev.w3.org/2006/webapi/progress/ All the changes have been in section 4 and in the terminology section. The changes will indeed require a new LC WD so I will (separately) cancel the CfC to publish a CR and start a pre-LC RfC for the PE spec and include a link to the DOM Core change. -AB
Canceled! CfC: publish Candidate Recommendation of Progress Events; deadline June 24
Because of the changes Anne applied to this spec, a new Last Call Working Draft will be needed so this CfC is _Canceled_: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1247.html On Jun/17/2011 9:57 AM, ext Arthur Barstow wrote: As noted earlier this month [1], the Progress Events spec's Last Call comment period ended with no comments. As such, Anne proposes the spec be published as a Candidate Recommendation and this is a Call for Consensus (CfC) to do so: http://dev.w3.org/2006/webapi/progress/ This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs The exit criteria is in the Draft CR and is based on the criteria in the XHR CR: http://dev.w3.org/2006/webapi/progress/#crec As with all of our CfCs, positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is June 24. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0807.html
Seeking pre-LC comments for Progress Events spec; deadline June 30
Anne's recent changes to the Progress Events spec means a new Last Call Working Draft must be published and he is not planning any additional changes. Please review the latest ED and send all comments to the list by June 30: http://dev.w3.org/2006/webapi/progress/ Note the recent changes to the PE spec depend on new changes to DOM Core (see [1] for some additional information): http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-event-init -AB [1] http://lists.w3.org/Archives/Public/www-dom/2011AprJun/0192.html
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Sun, Jun 19, 2011 at 2:35 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@mcc.id.au wrote: Adam Barth: WebKit is looser in this regard. We probably should change the default for new IDL, but it's a delicate task and I've been busy. :( What about for old IDL? Do you feel that you can make this change without breaking sites? One of the “advantages” of specifying the looser approach is that it’s further down the “race to the bottom” hill, so if we are going to tend towards it eventually we may as well jump there now. I can't remember getting a single bug filed on Geckos current behavior. There probably have been some which I've missed, but it's not a big enough problem that it's ever been discussed at mozilla as far as I can remember. Unfortunately, there's a bunch of WebKit-dominate content out there that folks are afraid to break. We discussed this topic on some bug (which I might be able to dig up). The consensus was that the value in tightening this for old APIs wasn't worth the compat risk (e.g., in mobile and in Mac applications such as Dashboard and Mail.app). For new APIs, of course, we can do the tighter things (which I agree is more aesthetic). It mostly requires someone to go into the code generator and make it the default (and then to special-case all the existing APIs). I'd like to do that, but it's a big job that needs to be done carefully and I've got other higher priority things to do, so it hasn't happened yet. If there is agreement that new APIs should throw for omitted non-optional parameters, then it seems clear that WebIDL should use that behavior. That leaves the work for safari (and possibly other webkit devs) to go through and mark parameters as [optional] in their IDL. Possibly also filing bugs for cases where you want the relevant spec to actually make the argument optional. I realize that this is a large amount of work, but this is exactly what we have asked in particular of microsoft in the past which has been in a similar situation of large divergence from the DOM specs, and large bodies of existing content which potentially can depend on IE specific behavior. Think folks are agreed that's the path we should follow. My only concern is that we don't have anyone signed up to do the work on the WebKit side. Just to update this thread, Mark Pilgrim has stepped forward to get the ball rolling on this work, so WebKit is making progress on this front. I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. -Mark
[widget] technology/specification name
I do not want to start a name bikeshedding. The name doesn't bother me so far, but I have seen that comment again and again. On Thu, 23 Jun 2011 14:06:24 GMT In Bruce Lawson’s personal site : Installable web apps and interoperability At http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/ Installable apps (in W3C parlance, Widgets – which is a terrible name) allow authors to write apps using HTML(5), CSS, JavaScript, SVG etc, and package them up into a glorified Zip file with some configuration details which can then be installed on a computer. It seems that extensions or addons would be more cognitively connected with Web developers. y'know, so terrible is the W3C “Widgets” name that I didn't even think it referred to the same thing as Chrome’s apps, et al. — http://twitter.com/nevali/status/83866541388603392 -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [widget] technology/specification name
In the webinos project [1] we are using installed vs hosted web apps. On 23/06/11 15:58, Karl Dubost wrote: I do not want to start a name bikeshedding. The name doesn't bother me so far, but I have seen that comment again and again. On Thu, 23 Jun 2011 14:06:24 GMT In Bruce Lawson’s personal site : Installable web apps and interoperability At http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/ Installable apps (in W3C parlance, Widgets – which is a terrible name) allow authors to write apps using HTML(5), CSS, JavaScript, SVG etc, and package them up into a glorified Zip file with some configuration details which can then be installed on a computer. It seems that extensions or addons would be more cognitively connected with Web developers. y'know, so terrible is the W3C “Widgets” name that I didn't even think it referred to the same thing as Chrome’s apps, et al. — http://twitter.com/nevali/status/83866541388603392 [1] http://webinos.org/ -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: [widget] technology/specification name
Part of the issue is that its a fairly generic technology that can be applied to areas including: - Browser extensions - Installable web apps - Desktop widgets - Site gadgets - TV/STB widgets - Mobile webapps I think the name widgets came from the heritage of Opera Widgets, Nokia Widgets, Apple Dashboard Widgets (etc). Personally I don't think its all that bad as a name, but I don't feel especially attached to it either. If there is a better option, lets go for it. On the other hand, if there are barriers to adoption other than branding, lets address them. Unfortunately, I suspect a fair amount of it is just NIH syndrome. S On 23 Jun 2011, at 17:26, Dave Raggett wrote: In the webinos project [1] we are using installed vs hosted web apps. On 23/06/11 15:58, Karl Dubost wrote: I do not want to start a name bikeshedding. The name doesn't bother me so far, but I have seen that comment again and again. On Thu, 23 Jun 2011 14:06:24 GMT In Bruce Lawson’s personal site : Installable web apps and interoperability At http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/ Installable apps (in W3C parlance, Widgets – which is a terrible name) allow authors to write apps using HTML(5), CSS, JavaScript, SVG etc, and package them up into a glorified Zip file with some configuration details which can then be installed on a computer. It seems that extensions or addons would be more cognitively connected with Web developers. y'know, so terrible is the W3C “Widgets” name that I didn't even think it referred to the same thing as Chrome’s apps, et al. — http://twitter.com/nevali/status/83866541388603392 [1] http://webinos.org/ -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: [XHR2] load events on XMHttpRequestUpload
On Tue, Jun 21, 2011 at 12:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/21/11 3:01 PM, Darin Fisher wrote: Isn't there already a signal to tell you when response headers are available? Yes; I believe the readystate changes at this point and onreadystatechange is fired. Isn't it a bit redundant for the upload complete notification to be tied to the same signal? Yes, sure. But that the point when the browser knows the upload is complete It really depends on how you define complete. I think it is useful to know when all of the data has been sent. That seems useful to applications. An application might wish to switch from a progress meter for upload percentage to a static notification indicating that the application is now simply waiting for a response. Chrome for instance does exactly this in its status bar for HTML form submissions. Why shouldn't web apps be able to present the same kind of detailed upload progress UI? To support the use case of showing a progress meter, it seems helpful to know when the browser has finished writing bytes on the wire. If you're willing to restart the meter from 0 in some cases, perhaps. Yeah :-) It also seems like it would be useful for there to be a resend event indicating that the upload will be resent. Otherwise, one has to guess this. Yep. -Boris So, anyways... I think I like how Chrome is behaving. I haven't checked to see if this is a property of WebKit or Chromium's networking layer. I suspect it is a WebKit detail. Anyways, I think it would be useful to update the spec to support this behavior. It seems useful :-) -Darin
[indexeddb] IDBTransaction.oncomplete event type equals commit
We noticed that section 4.3 Steps for committing a transaction talks about setting the event type for the IDBTransction.oncomplete event handler to commit. Did we intend for the handler to be named oncommit or should the event type be complete. The current wording implies that the reason the transaction completed was because it was committed. The different terms made the section a little inconsistent. Do we want to change any names or keep it as is? Israel
Re: [indexeddb] IDBTransaction.oncomplete event type equals commit
I think complete should be the correct type string. -Ben Turner
[indexeddb] Behavior when calling IDBCursor.continue multiple times
We noticed that the spec doesn't say anything about what needs to happen if IDBCursor.continue is called multiple times. We noticed that both FF and Chrome throw a NOT_ALLOWED_ERR exception. If the exception is not caught, the cursor doesn't continue to iterate, an error event is triggered (errorCode = ABORT_ERR), and the transaction is aborted. However, if the exception is caught, the cursor will iterate normally. This model makes sense to us. It seems this is something we should document on the spec. Do you agree? Israel
[Bug 13035] New: on http://www.w3.org/TR/css-print/#s.8.4 It seems this line: br { content: \A } is missing :before If I am wrong please update http://www.w3.org/TR/CSS21/generate.html#propd
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13035
Summary: on http://www.w3.org/TR/css-print/#s.8.4 It seems this
line: br { content: \A } is missing :before If
I am wrong please update
http://www.w3.org/TR/CSS21/generate.html#propdef-conte
nt thx
Product: WebAppsWG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top
Comment:
on http://www.w3.org/TR/css-print/#s.8.4
It seems this line:
br { content: \A }
is missing :before
If I am wrong please update
http://www.w3.org/TR/CSS21/generate.html#propdef-content
thx
Posted from: 86.67.172.71
User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko)
Chrome/14.0.795.0 Safari/535.1
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: [widget] technology/specification name
One issue which comes up is that widget is also used in ARIA to describe ui elements. I suspect we'll see apps used ubiquitously; widget seems to e reserved to early experiments in linked apps; apps via iframe. Like many on this thread, I don't have a strong objection against the name. I rather appreciate the thread, it's bringing out more distinctions as to what we're talking about and targeting. -Charles On Jun 23, 2011, at 11:17 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Part of the issue is that its a fairly generic technology that can be applied to areas including: - Browser extensions - Installable web apps - Desktop widgets - Site gadgets - TV/STB widgets - Mobile webapps I think the name widgets came from the heritage of Opera Widgets, Nokia Widgets, Apple Dashboard Widgets (etc). Personally I don't think its all that bad as a name, but I don't feel especially attached to it either. If there is a better option, lets go for it. On the other hand, if there are barriers to adoption other than branding, lets address them. Unfortunately, I suspect a fair amount of it is just NIH syndrome. S On 23 Jun 2011, at 17:26, Dave Raggett wrote: In the webinos project [1] we are using installed vs hosted web apps. On 23/06/11 15:58, Karl Dubost wrote: I do not want to start a name bikeshedding. The name doesn't bother me so far, but I have seen that comment again and again. On Thu, 23 Jun 2011 14:06:24 GMT In Bruce Lawson’s personal site : Installable web apps and interoperability At http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/ Installable apps (in W3C parlance, Widgets – which is a terrible name) allow authors to write apps using HTML(5), CSS, JavaScript, SVG etc, and package them up into a glorified Zip file with some configuration details which can then be installed on a computer. It seems that extensions or addons would be more cognitively connected with Web developers. y'know, so terrible is the W3C “Widgets” name that I didn't even think it referred to the same thing as Chrome’s apps, et al. — http://twitter.com/nevali/status/83866541388603392 [1] http://webinos.org/ -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Tue, 21 Jun 2011, Ian Hickson wrote: How about we just make postMessage() take the object to clone in the first argument, an array of objects to transfer in the second; on the other side, the author receives the object cloned, with anything listed in the array and in the structured data being transferred instead of cloned, and, in addition, in the event.ports array, a list of the ports that were given in the transfer array. This has the advantage of being completely backwards-compatible. So for example, on the sending side: postMessage(['copied', copiedArrayBuffer, transferredArrayBuffer, transferredPort1], // could be an object too [transferredArrayBuffer, transferredPort1, transferredPort2]); ...on the receiving side, the event has data == ['copied', newCopiedArrayBuffer, newTransferredArrayBuffer, newTransferredPort1]; ports == [newTransferredPort1, newTransferredPort2]; It's not going to win any design awards, but I think that boat has sailed for this particular API anyway, given the contraints we're operating under. Since no serious problems were raised with this and it seems to address all the constraints, I've now specced this. One edge case that wasn't mentioned above is what happens when a non-port Transferable object is in the second list but not the first. I defined it such that it still gets cloned (and thus the original is neutered), but it is then discarded. (That definition more or less fell out of the way one'd have to implement this to make it simple to understand, but I'm happy to do it a different way if there's a good reason to.) http://html5.org/tools/web-apps-tracker?from=6272to=6273 kbr: Feel free to ping me if you need advice on how to use this with ArrayBuffer in the short term. On the long term I'm happy to just spec this in the same spec as the rest of this stuff. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[Bug 12947] Extend postMessage to support general transfer-of-ownership semantics
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12947 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[indexeddb] Count property on IDBCursor
Is there a reason why we don't have a count or number of records property on IDBCursor? Pablo told me that we used to have one. What happened to it? It will be great to bring it back. Israel
Re: Mouse Lock
And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? On 6/20/11, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote: The use-case is non-fullscreen games and similar, where you'd prefer to lock the mouse as soon as the user clicks into the game. Minecraft is the first example that pops into my head that works like this - it's windowed, and mouselocks you as soon as you click at it. And how would user unlock when some evil sites locks the mouse? Could you give some concrete example about It's probably also useful to instruct the user how to release the lock. I'm assuming that the browser reserves some logical key (like Esc) for releasing things like this, and communicates this in the overlay message. ~TJ -- Sent from my mobile device
Re: Mouse Lock
timeless, I agree, it'd be nice to know. I'd really like to see this put toward the AG (Accessibility Guidelines) people, as they're the ones who follow this kind of things. It's absolutely the case that a user needs an ability to escape from the mouse lock context, and to have one which lies outside of any processing handled by the untrusted scripting environment. The *AG practices are always the first to document these needs. Requiring keyboard for something that locks a mouse is not acceptable; a user must be able to release their pointer device without requiring a keyboard. The same applies for keyboard locks. Assistive technologies (AT) have their place in this, and can give some leeway to the user agent (UA), as long as the UA provides enough semantics to allow the AT to handle this kind of work. Again, these issues are always brought up by AG documents. I'll give you two examples for pointer device escape: 1) Right click/context menu; always works. 2) Click and hold; X number of seconds could pop up a context menu. 3) extreme coordinate and hold; x seconds on an extreme coordinate pops up a menu. On the extreme-coordinate; an input device which may only signal changes in x/y positioning may still be used to activate UA menus. Developers are by all practical purposes, required by existing standards and technologies, to leave space on the edges of the screen. Though this is mostly related to safe areas on televisions, the principle applies beyond that, and is de facto required by existing full screen semantics [wherein the top extremes create a dialog to escape]. So, by luck of history; extreme coordinates are encouraged and in practice, required as a means of escaping mouse lock. There are certainly cases where extreme coordinates could be useful to an application. Those corner cases will have to be thought about, by those implementing such apps. All the best, -Charles On 6/23/2011 6:29 PM, timeless wrote: And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? On 6/20/11, Tab Atkins Jr.jackalm...@gmail.com wrote: On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettayolli.pet...@helsinki.fi wrote: On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote: The use-case is non-fullscreen games and similar, where you'd prefer to lock the mouse as soon as the user clicks into the game. Minecraft is the first example that pops into my head that works like this - it's windowed, and mouselocks you as soon as you click at it. And how would user unlock when some evil sites locks the mouse? Could you give some concrete example about It's probably also useful to instruct the user how to release the lock. I'm assuming that the browser reserves some logical key (like Esc) for releasing things like this, and communicates this in the overlay message.
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Cheers! On 6/23/11, Mark Pilgrim pilg...@google.com wrote: On Sun, Jun 19, 2011 at 2:35 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack c...@mcc.id.au wrote: Adam Barth: WebKit is looser in this regard. We probably should change the default for new IDL, but it's a delicate task and I've been busy. :( What about for old IDL? Do you feel that you can make this change without breaking sites? One of the “advantages” of specifying the looser approach is that it’s further down the “race to the bottom” hill, so if we are going to tend towards it eventually we may as well jump there now. I can't remember getting a single bug filed on Geckos current behavior. There probably have been some which I've missed, but it's not a big enough problem that it's ever been discussed at mozilla as far as I can remember. Unfortunately, there's a bunch of WebKit-dominate content out there that folks are afraid to break. We discussed this topic on some bug (which I might be able to dig up). The consensus was that the value in tightening this for old APIs wasn't worth the compat risk (e.g., in mobile and in Mac applications such as Dashboard and Mail.app). For new APIs, of course, we can do the tighter things (which I agree is more aesthetic). It mostly requires someone to go into the code generator and make it the default (and then to special-case all the existing APIs). I'd like to do that, but it's a big job that needs to be done carefully and I've got other higher priority things to do, so it hasn't happened yet. If there is agreement that new APIs should throw for omitted non-optional parameters, then it seems clear that WebIDL should use that behavior. That leaves the work for safari (and possibly other webkit devs) to go through and mark parameters as [optional] in their IDL. Possibly also filing bugs for cases where you want the relevant spec to actually make the argument optional. I realize that this is a large amount of work, but this is exactly what we have asked in particular of microsoft in the past which has been in a similar situation of large divergence from the DOM specs, and large bodies of existing content which potentially can depend on IE specific behavior. Think folks are agreed that's the path we should follow. My only concern is that we don't have anyone signed up to do the work on the WebKit side. Just to update this thread, Mark Pilgrim has stepped forward to get the ball rolling on this work, so WebKit is making progress on this front. I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. -Mark -- Sent from my mobile device
Re: [indexeddb] Count property on IDBCursor
On Thu, Jun 23, 2011 at 5:34 PM, Israel Hilerio isra...@microsoft.com wrote: Is there a reason why we don’t have a count or number of records property on IDBCursor? Pablo told me that we used to have one. What happened to it? It will be great to bring it back. The problem is that counting the number of records in a given range can be a very expensive operation. There are various database implementations out there that lets you get an approximate count for a given key range, but that isn't good enough if since we want interoperability across implementations. Since getting an exact count is a pretty expensive operation generally, we don't want to force implementations to always calculate the count every time a cursor is created. Hence getting the count would have to be an asynchronous operation, which would look pretty awkward as an API on the cursor object I think. What could possibly make more sense is to add IDBRequest count(in IDBKeyRange range) on IDBObjectStore and IDBIndex. My main concern with that is that while that seems like a pretty cheap operation, in the order of get(), it might be as slow as creating a cursor and iterating each entry while increasing a counter (minus the overhead of crossing between C++ and JS for every callback). But maybe that's ok. / Jonas
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
Mark Pilgrim: I'm happy to report that WebKit's implementation of IndexedDB now follows WebIDL and throws TypeError on all functions when called with missing required arguments. We have grandfathered in all existing IDL files to use the old, looser code generator, but we are actively working on migrating *all* 521 IDL files to use the new, stricter generator (with [Optional] flags in places where we can't break compatibility). IndexedDB is the first success in this process; as an experimental API, we feel no need to maintain compatibility and have opted for the stricter semantics everywhere, matching the WebIDL and IndexedDB specs exactly. Next will be other experimental APIs like the web audio API and the File API, where we hope to have similar levels of success. Great work! I’m really happy to see some of the more complex requirements of Web IDL start to get implemented, so that we can find out sooner whether there are any problems that require spec changes. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Mouse Lock
On Thu, Jun 23, 2011 at 10:10 PM, Charles Pritchard ch...@jumis.com wrote: There are certainly cases where extreme coordinates could be useful to an application. Those corner cases will have to be thought about, by those implementing such apps. Moving the cursor to the top of the screen doesn't make sense when there's no cursor. The mouse no longer has a position onscreen; mouse lock essentially turns it into a delta-based input device. (FWIW, I've always found the top-edge mechanic used by browsers to exit fullscreen to be a bad case of best we could think of. It interferes badly with a ton of common UI mechanisms: menus, toolbars, tabs, address bars, and so on.) 2) Click and hold; X number of seconds could pop up a context menu. Hold escape for 3 seconds would probably work well, with a fade-in keep holding escape to exit fullscreen overlay while holding, so the user knows something's happening. I try to avoid do-something-and-wait interfaces, but it's reasonable for an escape mechanism. This also avoids eating the escape key entirely, so it's still available to applications, though of course browsers could choose a different key. And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? Mouse lock seems irrelevant on a touchscreen... -- Glenn Maynard
Re: Testing Progress Events and CR
On 6/23/11, Arthur Barstow art.bars...@nokia.com wrote:
On Jun/23/2011 6:45 AM, ext Anne van Kesteren wrote:
On Wed, 22 Jun 2011 17:36:07 +0200, Anne van Kesteren
ann...@opera.com wrote:
I just checked in the proposal
https://bitbucket.org/ms2ger/dom-core/changeset/b9bb17789db9 into DOM
Core but I suspect it needs some refining and reviewing. I suspect we
need another Progress Events LC for this as technically it is a new
feature :/
In case people aren't following the above discussion in www-dom, note
the above changset has been applied to DOM Core:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-event-init
That very closely resembles something that I proposed years ago,
albeit with keeping the two method approach instead of
createInitedEvent -- one method
http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0164.html
Detecting and Creating Events
| There should be a simple way to create and fire an event.
| interface DocumentEvent {
| Event createInitedEvent(in domstring type, in Object options)
| raises(dom::DOMException);
| }
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0031.html
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0086.html
There are probably many other threads.
http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0191.html
Based on my interactions, I left with a poor impression of w3c employees.
Please attribute proper credit where it is due.
Also, I do not see why `Dictionary` is needed. It is an Object;
nothing more, nothing less. Though I did not subscribe to those
threads.
--
Garrett
