Web Notifications, do we need a new spec?
Keeping in line with the design goals to enable Widget-related technologies to be used on the Web, I'm wondering if we should spawn a separate specification for notifications? We could use the current text in the AE [1] as the basis, which is based heavily on what was originally in HTML5 (or just take the old HTML5 text, create the new spec, add the hooks for Widgets). Although notifications have been taken out of HTML5, rumblings that they may need reviving occurred recently on the WHAT-WG list: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html As a followup to the above, the following code was submitted by Google to WebKit to support notifications: https://bugs.webkit.org/show_bug.cgi?id=25463 So, the question is: do we need a new/separate spec? One that covers both Web and Widgets? Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-api/#the-shownotification-method-
Re: Is localStorage read and write-able offlne?
Everything in file:// is the same origin. I think Mozilla has been experimenting with changing this, but I can't remember how they handle localStorage (if it's even different at all). No. Everything on file:// has the origin defined by the origin serialization algorithm. http://dev.w3.org/html5/spec/Overview.html#origin The spec tells If scheme is file, then the user agent may return a UA-specific value. In Opera's case we use file://machine/ where machine can be localhost, an ip, or a remote computer with a shared folder. If you're on a local network which cannot be fully trusted, accessing a page at file://peer/ that manages to access your local harddrive is as serious as a cross-domain attack, or even more. So saying that everything on file has origin file:// is a misconception of the problem origin tries to solve.
[widgets] BUG ALERT for P+C spec: deprecated, grandfathered, and redundant tags should be skipped.
Opera QA has found the following bug in the Widgets 1.0: Packaging and Configuration W3C Candidate Recommendation 23 July 2009 [1]. Description of bug: In Step 5, UAs are _not_ instructed to skip deprecated, grandfathered, or redundant language tags: if I have a language list of x-foobar,en, the processed list would end up as x-foobar,x,en. It is the x entry that shouldn't be there. Proposed solution: Add to Step 5, in the algorithm, after 2 A: B. If this range begins with the subtag i, x, or the range is marked as deprecated in the IANA Language Subtag Registry, skip all the steps in this algorithm below, and move onto the next range. [1] http://www.w3.org/TR/2009/CR-widgets-20090723/ -- Marcos Caceres http://datadriven.com.au
Re: Web Notifications, do we need a new spec?
On Fri, Jul 31, 2009 at 1:52 AM, Marcos Caceres marc...@opera.com wrote: Keeping in line with the design goals to enable Widget-related technologies to be used on the Web, I'm wondering if we should spawn a separate specification for notifications? We could use the current text in the AE [1] as the basis, which is based heavily on what was originally in HTML5 (or just take the old HTML5 text, create the new spec, add the hooks for Widgets). Although notifications have been taken out of HTML5, rumblings that they may need reviving occurred recently on the WHAT-WG list: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html There was a lot of talk about notifications in this more recent thread as well: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/thread.html#21421 (The thread is long and talks about a lot of things besides notifications, but I think there are some key insights in that thread about the requirements for notifications.) As a followup to the above, the following code was submitted by Google to WebKit to support notifications: https://bugs.webkit.org/show_bug.cgi?id=25463 So, the question is: do we need a new/separate spec? One that covers both Web and Widgets? I think we do need to start thinking about specing this out. Off the top of my head, it seems like the requirements for the web and widgets will be pretty similar. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-api/#the-shownotification-method-
[webdatabase] SQLError codes
Hi.
The IDL for SQLError defines a code property with the values described at
http://dev.w3.org/html5/webdatabase/#errors-and-exceptions
Currently, the table with those values only has numbers (error codes) and
textual descriptionss.
It would be nice if those errors were enumerated in the SQLError interface, and
be given a persistent name, like with DOMException.
interface SQLError {
readonly attribute unsigned long code;
readonly attribute DOMString message;
static const unsigned long TRANSACTION_FAILED = 0;
static const unsigned long DATABASE_ERROR = 1;
};
Thank you.
