RE: [indexeddb] New WebIDL Exception Model for IndexedDB

[Israel Hilerio]

On Monday, September 26, 2011 2:36 AM Anne van Kesteren wrote:
> On Mon, 26 Sep 2011 09:31:36 +0200, Anne van Kesteren
> 
> wrote:
> > On Fri, 23 Sep 2011 00:52:39 +0200, Israel Hilerio
> >  wrote:
> >> This is our understanding on how the spec needs to change to support
> >> the new WebIDL exception handling model.  We would start by removing
> >> all of the constants from IDBDatabaseException.  After that, the only
> >> thing left would be message.  Do we still need to have this class
> >> definition?  It seems we can remove it.
> >>
> >> In either case, we would have to continue by defining a set of
> >> exception types and code mappings. Each exception type will have a
> >> code value of 0.
> >>
> >> The mapping will look like this:
> >> UnknownError(0)
> >> NonTransientError(0)
> >> NotFoundError(0)
> >> ConstraintError(0)
> >> DataError(0)
> >> NotAllowedError(0)
> >> TransactionInactiveError(0)
> >> AbortError(0)
> >> ReadOnlyError(0)
> >> TimeoutError(0)
> >> QuotaError(0)
> >> VersionError(0)
> >>
> >> If we believe the message attribute is still relevant, then we would
> >> define the IDBDatabaseException class like this:
> >> exception IDBDatabaseException: DOMException {
> >> DOMString  message;
> >> };
> >> Using this approach, IDBDatabaseException will inherit the name and
> >> code properties from DOMException.
> >>
> >> Is this what you had in mind?
> >
> > The new approach is outlined here:
> >
> >http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c14
> >
> > I should probably update DOM4 with some easy to use language,
> > including how this maps to the code member.
> 
> I've done that now.
> 
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw
> 
> If that is correct I would expect Indexed Database API to say e.g.
> 
> "throw a VersionError exception" in its prose.
> 
> We should probably keep these exceptions central somewhere so we do not
> mint similar exceptions twice. E.g. QuotaError looks like it could be the same
> as the existing QuoteExceededError.
> 
> The table in DOM4 could be that central place I suppose as other than the
> code numbers it is largely non-normative so we could update it as editorial
> changes whenever we want.
> 
> What do people think?
> 
> 
> --
> Anne van Kesteren
> http://annevankesteren.nl/

Like Cameron says in the link above and based on the WebIDL description, it 
seems we want the IndexedDB text to say, for example:
Throws a DOMException of type " VersionError". (vs. Throw a VersionError 
exception)
This assumes we don't have a need for an IDBDatabaseException.  Still yet to be 
decided on.

In addition, it seem that the names I outlined above match the expected naming 
convention outlined in the link you specified.  However, we shouldn't redefine 
any types which are already included in the DOM 4 exceptions section.  We 
should just use them and point to them.

For IndexedDB, we will include the following database specific exceptions in 
our spec:
UnknownError
NonTransientError
ConstraintError
DataError
NotAllowedError
TransactionInactiveError
ReadOnlyError
VersionError
All of these exceptions will have a code of 0.

In addition, we would reuse the following types from the DOM 4 Exception 
section:
NotFoundError
AbortError
TimeoutError
QuotaExceededError

While I can see the benefits of having an all-encompassing list of exceptions 
people can go to see the various types, it seems that this could grow very 
large and we'll see may exceptions which are not applicable to other 
technologies.  To that effect, we prefer all new feature specific exceptions to 
be included in the spec they are used instead of a centralized table. 

Israel 

Re: Storage Quota API

[Jonas Sicking]

On Mon, Sep 26, 2011 at 5:18 PM, Charles Pritchard  wrote:
> What's the alternative to the callback style from the proposal? It should be 
> async, as both requesting and checking quota may require async requests.

See IDBRequest.

http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#request-api

/ Jonas

Re: Storage Quota API

[Charles Pritchard]

On Sep 26, 2011, at 4:58 PM, Boris Zbarsky  wrote:

> On 9/26/11 7:53 PM, Charles Pritchard wrote:
>> The callback style is prevalent in the File API...
>> The enum style is also borrowed from
>> FileSystem.
> 
> Those are totally different things.  One of them is much saner than the 
> other; it's not clear that either one is worth emulating in other specs in 
> detail.

It occurs to me that permanent is just a priority indicator. Google's 
Chromebook systems have a warning in their file manager about how the archive 
can be wiped out. As an app developer, I've certainly noticed that a user 
-only- storing files inside of an application is taking a bigger risk than if 
they stored the files on their desktop.


What's the alternative to the callback style from the proposal? It should be 
async, as both requesting and checking quota may require async requests.

Re: Storage Quota API

[Michael Nordman]

On Mon, Sep 26, 2011 at 4:53 PM, Charles Pritchard  wrote:

> The callback style is prevalent in the File API, as well as IndexedDB. It
> seems quite fitting to me. Am I missing something?
>
> They are using vendor prefixing (WebKit).
>
> From what I read, WebSQL is temporary: I've not confirmed this.
>
> I'm super surprised that Chrome treats IDB as temporary. That seems like a
> major WebKit bug.
>

The storage policy is not a function of webkit. Chrome policies are distinct
from Safari or any other webkit based browsers.


>
> The enum style is also borrowed from
> FileSystem. I'd rather have strings too, but I've accepted the 0/1 enum
> values from File API as the way things are going to be.
>
> Any ideas on how to express temp v. Perm to IndexedDB?
>

There is no way to express that for IDB, ditto for WebSQL or AppCache. The
only storage api in which Perm can be expressed is in FileSystem. It's
possible to make a way to say "perm" for other types. We feel pretty
strongly that there's value in being able to use these interfaces w/o
prompts and that's the motivation for the general TEMP policy.


> AppCache is temp, I'm sure, though I'd want it as perm on installed web
> apps.
>
> -Charles
>
>
>
> On Sep 26, 2011, at 4:43 PM, Jonas Sicking  wrote:
>
> > Please don't use errorCallback/SuccessCallback. That's not used in any
> > other APIs that are part of the cross-browser web platform. Instead
> > return a request object on which events are fired.
> >
> > Don't use enums as the syntax sucks in JS. Use strings instead. We're
> > making the same transition in a lot of other APIs.
> >
> > There's also a problem in that Gecko treats IndexedDB as permanent
> > quota by default and Chrome treats it as temporary. Not sure how to
> > solve that problem.
> >
> > You guys have this prefixed in your implementation for now, right?
> >
> > / Jonas
> >
> > On Mon, Sep 26, 2011 at 2:49 PM, Charles Pritchard 
> wrote:
> >> Though unstable, Chromium via WebKit has introduced an API for working
> with
> >> storage quotas:
> >>
> >>
> https://groups.google.com/a/chromium.org/group/chromium-html5/msg/5261d24266ba4366
> >>
> >> In brief:
> >>
> >>  void queryUsageAndQuota(
> >>  unsigned short storageType,
> >>  optional StorageInfoUsageCallback successCallback,
> >>  optional StorageInfoErrorCallback errorCallback);
> >>  // Requests a new quota.  Requesting a larger quota may require user's
> >>  // explicit permission via UI prompting / infobar.
> >>
> >>  void requestQuota(
> >>  unsigned short storageType,
> >>  unsigned long long newQuotaInBytes,
> >>  optional StorageInfoQuotaCallback successCallback,
> >>  optional StorageInfoErrorCallback errorCallback);
> >> };
> >>
> >>
> >> This API works across all storage types except localStorage, as
> localStorage
> >> is unique.
> >>
> >> It spans IndexedDB, FileSystem, AppCache and for those that are carrying
> it,
> >> WebSQL.
> >>
> >>
> >> -Charles
> >>
> >>
> >
>
>

Re: Storage Quota API

[Boris Zbarsky]

On 9/26/11 7:53 PM, Charles Pritchard wrote:

The callback style is prevalent in the File API...
The enum style is also borrowed from
FileSystem.


Those are totally different things.  One of them is much saner than the 
other; it's not clear that either one is worth emulating in other specs 
in detail.


-Boris

Re: Storage Quota API

[Charles Pritchard]

The callback style is prevalent in the File API, as well as IndexedDB. It seems 
quite fitting to me. Am I missing something?

They are using vendor prefixing (WebKit).

From what I read, WebSQL is temporary: I've not confirmed this.

I'm super surprised that Chrome treats IDB as temporary. That seems like a 
major WebKit bug.

The enum style is also borrowed from
FileSystem. I'd rather have strings too, but I've accepted the 0/1 enum values 
from File API as the way things are going to be.

Any ideas on how to express temp v. Perm to IndexedDB?

AppCache is temp, I'm sure, though I'd want it as perm on installed web apps.

-Charles



On Sep 26, 2011, at 4:43 PM, Jonas Sicking  wrote:

> Please don't use errorCallback/SuccessCallback. That's not used in any
> other APIs that are part of the cross-browser web platform. Instead
> return a request object on which events are fired.
> 
> Don't use enums as the syntax sucks in JS. Use strings instead. We're
> making the same transition in a lot of other APIs.
> 
> There's also a problem in that Gecko treats IndexedDB as permanent
> quota by default and Chrome treats it as temporary. Not sure how to
> solve that problem.
> 
> You guys have this prefixed in your implementation for now, right?
> 
> / Jonas
> 
> On Mon, Sep 26, 2011 at 2:49 PM, Charles Pritchard  wrote:
>> Though unstable, Chromium via WebKit has introduced an API for working with
>> storage quotas:
>> 
>> https://groups.google.com/a/chromium.org/group/chromium-html5/msg/5261d24266ba4366
>> 
>> In brief:
>> 
>>  void queryUsageAndQuota(
>>  unsigned short storageType,
>>  optional StorageInfoUsageCallback successCallback,
>>  optional StorageInfoErrorCallback errorCallback);
>>  // Requests a new quota.  Requesting a larger quota may require user's
>>  // explicit permission via UI prompting / infobar.
>> 
>>  void requestQuota(
>>  unsigned short storageType,
>>  unsigned long long newQuotaInBytes,
>>  optional StorageInfoQuotaCallback successCallback,
>>  optional StorageInfoErrorCallback errorCallback);
>> };
>> 
>> 
>> This API works across all storage types except localStorage, as localStorage
>> is unique.
>> 
>> It spans IndexedDB, FileSystem, AppCache and for those that are carrying it,
>> WebSQL.
>> 
>> 
>> -Charles
>> 
>> 
> 

Re: Storage Quota API

[Jonas Sicking]

Please don't use errorCallback/SuccessCallback. That's not used in any
other APIs that are part of the cross-browser web platform. Instead
return a request object on which events are fired.

Don't use enums as the syntax sucks in JS. Use strings instead. We're
making the same transition in a lot of other APIs.

There's also a problem in that Gecko treats IndexedDB as permanent
quota by default and Chrome treats it as temporary. Not sure how to
solve that problem.

You guys have this prefixed in your implementation for now, right?

/ Jonas

On Mon, Sep 26, 2011 at 2:49 PM, Charles Pritchard  wrote:
> Though unstable, Chromium via WebKit has introduced an API for working with
> storage quotas:
>
> https://groups.google.com/a/chromium.org/group/chromium-html5/msg/5261d24266ba4366
>
> In brief:
>
>  void queryUsageAndQuota(
>      unsigned short storageType,
>      optional StorageInfoUsageCallback successCallback,
>      optional StorageInfoErrorCallback errorCallback);
>  // Requests a new quota.  Requesting a larger quota may require user's
>  // explicit permission via UI prompting / infobar.
>
>  void requestQuota(
>      unsigned short storageType,
>      unsigned long long newQuotaInBytes,
>      optional StorageInfoQuotaCallback successCallback,
>      optional StorageInfoErrorCallback errorCallback);
> };
>
>
> This API works across all storage types except localStorage, as localStorage
> is unique.
>
> It spans IndexedDB, FileSystem, AppCache and for those that are carrying it,
> WebSQL.
>
>
> -Charles
>
>

[Bug 14297] New: ja sam manijak iz gimnazijskog parka, već danima sakriven ja gledam te iz mraka

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14297

   Summary: ja sam manijak iz gimnazijskog parka, već danima
sakriven ja gledam te iz mraka
   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:
ja sam manijak iz gimnazijskog parka, već danima sakriven ja gledam te iz
mraka

Posted from: 31.147.146.151
User agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.9.168 Version/11.51

-- 
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.

Storage Quota API

[Charles Pritchard]

Though unstable, Chromium via WebKit has introduced an API for working 
with storage quotas:


https://groups.google.com/a/chromium.org/group/chromium-html5/msg/5261d24266ba4366

In brief:

  void queryUsageAndQuota(
  unsigned short storageType,
  optional StorageInfoUsageCallback successCallback,
  optional StorageInfoErrorCallback errorCallback);
  // Requests a new quota.  Requesting a larger quota may require user's
  // explicit permission via UI prompting / infobar.

  void requestQuota(
  unsigned short storageType,
  unsigned long long newQuotaInBytes,
  optional StorageInfoQuotaCallback successCallback,
  optional StorageInfoErrorCallback errorCallback);
};


This API works across all storage types except localStorage, as 
localStorage is unique.


It spans IndexedDB, FileSystem, AppCache and for those that are carrying 
it, WebSQL.



-Charles

Publishing specs before TPAC; Oct 14 is last day to start a CfC

[Arthur Barstow]

The upcoming TPAC meeting (Oct 31 - Nov 01) provides an opportunity for 
joint WG meetings and lots of informal sharing. As such, some groups 
make spec publications right before TPAC.


Note there is a 2-week publication blackout period around the TPAC week 
and Oct 24 is the last day to request publication before TPAC.  Given 
our 1-week CfC for new publications, weekends, etc., the schedule is:


* Oct 14 - last day to start a CfC to publish
* Oct 24 - last day to request publication
* Oct 27 - last publications before TPAC
* Nov 07 - publications resume

*A lot of groups wait until the deadline so if you want to publish 
before TPAC, I encourage you to propose publication as soon as possible 
and by October 14 at the latest.

*
Some specs I'd like to see published before TPAC 
():


* Clipboard APIs and Events - I think Hallvord has made quite a few 
changes since last publication on 12-Apr-2011. WDYT Hallvord?


* D3E - not sure if next pub is CR or LC. Doug, Jacob?

* File API (last published in 26-Oct-2010) - Arun, Jonas - what's up 
with this spec?


* File API: Writer and Directories & System - WDYT Eric? Are the changes 
since the April 2011 publication significant?


* Indexed Database API - is this ready for LC?

* Server-sent Events - 8 open bugs so I presume a new WD at this point.

* Web Messaging - 6 open bugs so I presume a new WD at this point.

-AB

Re: Mutation Observers: a replacement for DOM Mutation Events

[Adam Klein]

On Mon, Sep 26, 2011 at 12:08 PM, Olli Pettay  wrote:
> On 09/26/2011 09:09 PM, Adam Klein wrote:
>>
>> On Mon, Sep 26, 2011 at 11:05 AM, Olli Pettay
>>  wrote:
>>>
>>> On 09/24/2011 12:16 AM, Adam Klein wrote:

 Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
 Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
 proposal for a replacement for Mutation Events.

 This proposal represents our best attempt to date at making a set of
 sensible trade offs which allows for a new mutation observation
 mechanism that:

 - Is free of the faults of the existing Mutation Events mechanism
 (enumerated in detail here:
 http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)

 - Meets the goal of having the main “questions” that use-cases will
 need answered about the net-effect of changes, be computable in linear
 time complexity roughly proportional to the number of changes that
 occurred.

 Significant aspects of this design:

 - Delivery of MutationRecords happens asynchronously, at the end of
 the current “microtask”. This is between Options 2 and 3 from this
 discussion
 http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
 Instead of calling listeners at the end of outermost DOM operation or
 at the end of a Task, listeners are called at the end of outermost
 script invocation. If there are no script invocations, listeners are
 called at the end of Task.

 - Information about mutations is delivered to observers as an ordered
 sequence of MutationRecords, representing an observed sequence of
 changes that have occurred.

 - Subtree observation properly handles the case where nodes are
 transiently removed from, mutated outside of and then returned to the
 subtree.

 - Observers specify the types of changes they are interested in and
 (in some cases) level of detail they require.

 Sample usage:

 var observer = new MutationObserver(function(mutationRecords) {
   // Handle mutations
 });

 observer.observe(myNode,
 {  // options:
   subtree: true;  // observe the subtree rooted at myNode
   childList: true;  // include information childNode insertion/removals
   attribute: true;  // include information about changes to attributes
 within the subtree
 });

 …

 observer.disconnect();  // Cease observation

 Details:

 We introduce a new interface MutationObserver with a constructor on
 DOMWindow:

 [Constructor(in MutationCallback callback)]
 interface MutationObserver {
    void observe(in Node target, in MutationObserverOptions options);
    void disconnect();
 };

 where MutationCallback is

 [Callback, NoInterfaceObject]
 interface MutationCallback {
     void handleEvent(in MutationRecord[] mutations, in
 MutationObserver observer);
 };

 Registration&    Observation
 - A call to observe creates a registration for the observer to be
 delivered mutations made to |target|, and optionally, its descendants.

 - Subsequent calls to the same MutationObserver made with the same
 |target| have the effect of resetting the options associated with the
 registration.

 - Subsequent calls to the same MutationObserver made with different
 |targets| have the effect of expanding the set of nodes which are
 being observed by the observer. All mutations made to all observed
 nodes in all registrations for a given observer are delivered, in
 time-ordered sequence, via a single invocation of the
 MutationCallback’s handleEvent method.

 - disconnect ceases observation over the observer’s set of observed
 nodes.

 Registration Options
 The |options| argument provided in observe is defined by the
 MutationObserverOptions interface:

 interface MutationObserverOptions {
     // Mutation types
     boolean childList;  // If true, mutations affecting node’s
 childNodes are included.
     boolean attribute;  // If true, mutations affecting element’s
 attributes are included.
>>>
>>> We need to change this name, since per WebIDL 'attribute' can't be used
>>> here.
>>>
>>> I propose we use attr everywhere in the API. MutationRecord has already
>>> attrName.
>>> attributeOldValue ->  attrOldValue and attributeFilter ->  attrFilter
>>
>> Good catch (and I should've caught it when typing this up, as it's
>> pseudo-idl), 'attr' works for me.  If that shortening isn't
>> appreciated, we could go with 'attributes' instead.
>
>
> Apparently I was wrong.
> In WebIDL one can escape names using _ prefix.
>
> But actually, attributes sounds more right than
> attribute. One really does want to observe all the attributes, unless
> names are filtered.
>
> so:
> attributes

Re: [widgets] Killing file:// of evil (widget URI ready for pub)

[Robin Berjon]

Hi Marcos,

On Sep 26, 2011, at 16:43 , Marcos Caceres wrote:
> On Monday, September 26, 2011 at 4:31 PM, Robin Berjon wrote:
>> Well, the advantage of a scheme is that it's solidly in the realm of the 
>> implementation to decide how to handle it. We've actually been bouncing 
>> ideas like the above around for a while (albeit with things like .app rather 
>> than .localhost) and it's a bit scary. It means that in some cases you're 
>> doing DNS resolution differently than the way in which you normally do it 
>> (which might just be relying on the system).  
> This is the problem I've run into at the moment. I can't seem to get around 
> it:  
> 
> * Either add sub domains to localhost in the "hosts" file
> * use virtual hosts in Apache
> * I don't think either gives me dynamic dns capabilities (for when I start 
> new widgets, I create a new subdomain… and no idea how to do it on Android… 
> there is no API, AFACT).  
> 
> All the java HTTP servers I have been looking at naturally assume a TCP/IP 
> socket. Replacing that with a, um, kinda native socket, is not really working 
> for me.  

Well, that's what you get for using Java in the first place — why would anyone 
do that? :)

Depending on what platform you're using to implement this, this isn't a 
problem. For instance, in Gecko IIRC you can register yourself to be notified 
when a URI is about to be loaded, and you get not just the scheme but also (at 
least) the authority. This means that you could intercept calls to 
http://DEADBEEF.localhost and serve them yourself rather than ever hitting the 
network. I'm pointing out the implementation issue however because I have no 
idea if this approach is used elsewhere or if it would require some ugly 
hacking. Overall, the scheme approach uses a well-defined extensibility point 
in the architecture. Relying on magical DNS entries is really a hack (unless 
perhaps we register a TLD for it with defined behaviour. Oh gods no, it's 
already enough of a pain to register a scheme).

If you want to support a local app engine access through the browser but not 
implemented in it, and that uses this DNS based approach then yeah you'll have 
to handle local DNS resolution. Note that the hosts file can be rewritten 
dynamically (by a process running as root). Plenty of tools (e.g. Localghost on 
Mac) do this sort of stuff. You can also run a local DNS server and hook 
yourself up to use it (I'm not sure if you're trying to build a real platform 
or just have fun here :). As for the server at the other end routing it 
properly that's a no-brainer: you just need to handle the Host header.

But again it's not clear to me what you're trying to do — I'm just tossing 
solutions over the fence that have the shape of the problem you're describing.

>> It means surprising results if you add 
>> c13c6f30-ce25-11e0-9572-0800200c9a66.app to your hosts file and see it do 
>> one thing in the browser and another in a widget.
> 
> Yeah :( Or trying to stop a widget from getting into the resources of another 
> widget (referrer check to stop one widget getting into another widget seems 
> somewhat fragile)… and the battery sucking while(true){ } for the thread that 
> listens is not too nice either.  

Again, if you're implementing inside Gecko with the approach described above 
that's not a problem (IIRC it's implemented in Widgeon if you need example code 
— the problem of preventing cross-access for the http: scheme is no different 
from doing the same for widget:). You can simply control navigation policy, 
enforce same-origin, etc. If you're doing something different, well yes, you 
may be in trouble.

> This presupposes that someone there will have an opinion :) I was, at least, 
> going to write my paper around this… but I imagine it will go a lot like… 
> "um, I tried doing this… it kinda didn't work, um… yeah… so, hhmm… would be 
> very useful, however" :).

Knowing what doesn't work is also helpful — you could write a paper about 
failed approaches :)

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: CfI: Progress Events is a W3C Candidate Recommendation

[Anne van Kesteren]

On Mon, 26 Sep 2011 20:07:12 +0200, Arthur Barstow   
wrote:
Anne, Ms2ger, what is the status of the Progress Events test suite (e.g.  
% complete)?


   http://w3c-test.org/webapps/ProgressEvents/tests/


All features are tested, including some complex Web IDL tests. I think we  
can probably think of more tests and add them as they come, but the tests  
we have are good enough to proceed beyond CR once we have implementations  
(and review of the tests).



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Mutation Observers: a replacement for DOM Mutation Events

[Olli Pettay]

On 09/26/2011 09:09 PM, Adam Klein wrote:

On Mon, Sep 26, 2011 at 11:05 AM, Olli Pettay  wrote:

On 09/24/2011 12:16 AM, Adam Klein wrote:


Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.

This proposal represents our best attempt to date at making a set of
sensible trade offs which allows for a new mutation observation
mechanism that:

- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)

- Meets the goal of having the main “questions” that use-cases will
need answered about the net-effect of changes, be computable in linear
time complexity roughly proportional to the number of changes that
occurred.

Significant aspects of this design:

- Delivery of MutationRecords happens asynchronously, at the end of
the current “microtask”. This is between Options 2 and 3 from this
discussion
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
Instead of calling listeners at the end of outermost DOM operation or
at the end of a Task, listeners are called at the end of outermost
script invocation. If there are no script invocations, listeners are
called at the end of Task.

- Information about mutations is delivered to observers as an ordered
sequence of MutationRecords, representing an observed sequence of
changes that have occurred.

- Subtree observation properly handles the case where nodes are
transiently removed from, mutated outside of and then returned to the
subtree.

- Observers specify the types of changes they are interested in and
(in some cases) level of detail they require.

Sample usage:

var observer = new MutationObserver(function(mutationRecords) {
   // Handle mutations
});

observer.observe(myNode,
{  // options:
   subtree: true;  // observe the subtree rooted at myNode
   childList: true;  // include information childNode insertion/removals
   attribute: true;  // include information about changes to attributes
within the subtree
});

…

observer.disconnect();  // Cease observation

Details:

We introduce a new interface MutationObserver with a constructor on
DOMWindow:

[Constructor(in MutationCallback callback)]
interface MutationObserver {
void observe(in Node target, in MutationObserverOptions options);
void disconnect();
};

where MutationCallback is

[Callback, NoInterfaceObject]
interface MutationCallback {
 void handleEvent(in MutationRecord[] mutations, in
MutationObserver observer);
};

Registration&Observation
- A call to observe creates a registration for the observer to be
delivered mutations made to |target|, and optionally, its descendants.

- Subsequent calls to the same MutationObserver made with the same
|target| have the effect of resetting the options associated with the
registration.

- Subsequent calls to the same MutationObserver made with different
|targets| have the effect of expanding the set of nodes which are
being observed by the observer. All mutations made to all observed
nodes in all registrations for a given observer are delivered, in
time-ordered sequence, via a single invocation of the
MutationCallback’s handleEvent method.

- disconnect ceases observation over the observer’s set of observed nodes.

Registration Options
The |options| argument provided in observe is defined by the
MutationObserverOptions interface:

interface MutationObserverOptions {
 // Mutation types
 boolean childList;  // If true, mutations affecting node’s
childNodes are included.
 boolean attribute;  // If true, mutations affecting element’s
attributes are included.


We need to change this name, since per WebIDL 'attribute' can't be used
here.

I propose we use attr everywhere in the API. MutationRecord has already
attrName.
attributeOldValue ->  attrOldValue and attributeFilter ->  attrFilter


Good catch (and I should've caught it when typing this up, as it's
pseudo-idl), 'attr' works for me.  If that shortening isn't
appreciated, we could go with 'attributes' instead.



Apparently I was wrong.
In WebIDL one can escape names using _ prefix.

But actually, attributes sounds more right than
attribute. One really does want to observe all the attributes, unless
names are filtered.

so:
attributes
attributeName
attributeNamespace
attributeOldValue
attributeFilter



-Olli




- Adam





 boolean characterData;  // If true, mutations affecting the value
of CharacterData
 //nodes are included.
 // [Note: If none of the known mutation types is specified, an
Error is thrown]

 // Subtree observation
 boolean subtree;  // If true, the observed set of nodes for this
registration should include
  // descendants of MutationTarget
(behavior described below).

 // Old values
 boolean attributeOldValue;

Re: [FileAPI] BlobBuilder.append("native")

[Eric U]

On Thu, Sep 22, 2011 at 4:47 PM, Glenn Maynard  wrote:
>> "native" Newlines must be transformed to the default line-ending
>> representation of the underlying host filesystem. For example, if the
>> underlying filesystem is FAT32, newlines would be transformed into \r\n
>> pairs as the text was appended to the state of the BlobBuilder.
>
> This is a bit odd: most programs write newlines according to the convention
> of the host system, not based on peeking at the underlying filesystem.  You
> won't even know the filesystem if you're writing to a network drive.  I'd
> suggest "must be transformed according to the conventions of the local
> system", and let implementations decide what that is.  It should probably be
> explicit that the only valid options are \r\n and \n, or reading files back
> in which were transformed in this way will be difficult.

Good catch--I'll fix that.

> Also, in the Issue above that, it seems to mean "native" where it says
> "transparent".

Yup.  That too.

Thanks!

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Eric U]

Thanks Glenn and Simon--I'll see what I can do.

On Fri, Sep 23, 2011 at 1:34 AM, Simon Pieters  wrote:

> On Fri, 23 Sep 2011 01:40:44 +0200, Glenn Maynard  wrote:
>
>  BlobBuilder.append(text) says:
>>
>>  Appends the supplied text to the current contents of the BlobBuilder,
>>>
>> writing it as UTF-8, converting newlines as specified in endings.
>>
>> It doesn't elaborate any further.  The conversion from UTF-16 to UTF-8
>> needs
>> to be defined, in particular for the edge case of invalid UTF-16
>> surrogates.  If this is already defined somewhere, it isn't referenced.
>>
>> I suppose this would belong in "Common infrastructure", next to the
>> existing
>> section on UTF-8, not in FileAPI itself.
>>
>
> WebSocket send() throws SYNTAX_ERR if its argument contains unpaired
> surrogates. It would be nice to be consistent.
>
> --
> Simon Pieters
> Opera Software
>
>

Re: Mutation Observers: a replacement for DOM Mutation Events

[Adam Klein]

On Mon, Sep 26, 2011 at 1:47 AM, Olli Pettay  wrote:
> On 09/24/2011 12:16 AM, Adam Klein wrote:
>>
>> Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
>> Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
>> proposal for a replacement for Mutation Events.
>>
>> This proposal represents our best attempt to date at making a set of
>> sensible trade offs which allows for a new mutation observation
>> mechanism that:
>>
>> - Is free of the faults of the existing Mutation Events mechanism
>> (enumerated in detail here:
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)
>>
>> - Meets the goal of having the main “questions” that use-cases will
>> need answered about the net-effect of changes, be computable in linear
>> time complexity roughly proportional to the number of changes that
>> occurred.
>>
>> Significant aspects of this design:
>>
>> - Delivery of MutationRecords happens asynchronously, at the end of
>> the current “microtask”. This is between Options 2 and 3 from this
>> discussion
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
>> Instead of calling listeners at the end of outermost DOM operation or
>> at the end of a Task, listeners are called at the end of outermost
>> script invocation. If there are no script invocations, listeners are
>> called at the end of Task.
>>
>> - Information about mutations is delivered to observers as an ordered
>> sequence of MutationRecords, representing an observed sequence of
>> changes that have occurred.
>>
>> - Subtree observation properly handles the case where nodes are
>> transiently removed from, mutated outside of and then returned to the
>> subtree.
>>
>> - Observers specify the types of changes they are interested in and
>> (in some cases) level of detail they require.
>>
>> Sample usage:
>>
>> var observer = new MutationObserver(function(mutationRecords) {
>>   // Handle mutations
>> });
>>
>> observer.observe(myNode,
>> {  // options:
>>   subtree: true;  // observe the subtree rooted at myNode
>>   childList: true;  // include information childNode insertion/removals
>>   attribute: true;  // include information about changes to attributes
>> within the subtree
>> });
>>
>> …
>>
>> observer.disconnect();  // Cease observation
>>
>> Details:
>>
>> We introduce a new interface MutationObserver with a constructor on
>> DOMWindow:
>>
>> [Constructor(in MutationCallback callback)]
>> interface MutationObserver {
>>    void observe(in Node target, in MutationObserverOptions options);
>>    void disconnect();
>> };
>
> Yeah, these methods could return mutationobserver.
> (Although I don't like the o.observe(foo).observe(bar) kind of coding
>  style, since it doesn't make it clear which instance's method you're
>  calling. But one doesn't need to use that.)
>
>
>>
>> where MutationCallback is
>>
>> [Callback, NoInterfaceObject]
>> interface MutationCallback {
>>     void handleEvent(in MutationRecord[] mutations, in
>> MutationObserver observer);
>> };
>
> s/handleEvent/handleMutations/

I've yet to see a WebIDL callback that uses a method other than
handleEvent (it's not just EventListeners).  Any reason why
MutationCallbacks should be different?

>
>>
>> Registration&  Observation
>> - A call to observe creates a registration for the observer to be
>> delivered mutations made to |target|, and optionally, its descendants.
>>
>> - Subsequent calls to the same MutationObserver made with the same
>> |target| have the effect of resetting the options associated with the
>> registration.
>>
>> - Subsequent calls to the same MutationObserver made with different
>> |targets| have the effect of expanding the set of nodes which are
>> being observed by the observer. All mutations made to all observed
>> nodes in all registrations for a given observer are delivered, in
>> time-ordered sequence, via a single invocation of the
>> MutationCallback’s handleEvent method.
>>
>> - disconnect ceases observation over the observer’s set of observed nodes.
>>
>> Registration Options
>> The |options| argument provided in observe is defined by the
>> MutationObserverOptions interface:
>>
>> interface MutationObserverOptions {
>>     // Mutation types
>>     boolean childList;  // If true, mutations affecting node’s
>> childNodes are included.
>>     boolean attribute;  // If true, mutations affecting element’s
>> attributes are included.
>>     boolean characterData;  // If true, mutations affecting the value
>> of CharacterData
>>                                             //nodes are included.
>>     // [Note: If none of the known mutation types is specified, an
>> Error is thrown]
>>
>>     // Subtree observation
>>     boolean subtree;  // If true, the observed set of nodes for this
>> registration should include
>>                                  // descendants of MutationTarget
>> (behavior described below).
>>
>>     // Old values
>>     boolean attributeOldValue;
>>     // If true, Mutati

Re: Mutation Observers: a replacement for DOM Mutation Events

[Adam Klein]

On Mon, Sep 26, 2011 at 11:05 AM, Olli Pettay  wrote:
> On 09/24/2011 12:16 AM, Adam Klein wrote:
>>
>> Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
>> Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
>> proposal for a replacement for Mutation Events.
>>
>> This proposal represents our best attempt to date at making a set of
>> sensible trade offs which allows for a new mutation observation
>> mechanism that:
>>
>> - Is free of the faults of the existing Mutation Events mechanism
>> (enumerated in detail here:
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)
>>
>> - Meets the goal of having the main “questions” that use-cases will
>> need answered about the net-effect of changes, be computable in linear
>> time complexity roughly proportional to the number of changes that
>> occurred.
>>
>> Significant aspects of this design:
>>
>> - Delivery of MutationRecords happens asynchronously, at the end of
>> the current “microtask”. This is between Options 2 and 3 from this
>> discussion
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
>> Instead of calling listeners at the end of outermost DOM operation or
>> at the end of a Task, listeners are called at the end of outermost
>> script invocation. If there are no script invocations, listeners are
>> called at the end of Task.
>>
>> - Information about mutations is delivered to observers as an ordered
>> sequence of MutationRecords, representing an observed sequence of
>> changes that have occurred.
>>
>> - Subtree observation properly handles the case where nodes are
>> transiently removed from, mutated outside of and then returned to the
>> subtree.
>>
>> - Observers specify the types of changes they are interested in and
>> (in some cases) level of detail they require.
>>
>> Sample usage:
>>
>> var observer = new MutationObserver(function(mutationRecords) {
>>   // Handle mutations
>> });
>>
>> observer.observe(myNode,
>> {  // options:
>>   subtree: true;  // observe the subtree rooted at myNode
>>   childList: true;  // include information childNode insertion/removals
>>   attribute: true;  // include information about changes to attributes
>> within the subtree
>> });
>>
>> …
>>
>> observer.disconnect();  // Cease observation
>>
>> Details:
>>
>> We introduce a new interface MutationObserver with a constructor on
>> DOMWindow:
>>
>> [Constructor(in MutationCallback callback)]
>> interface MutationObserver {
>>    void observe(in Node target, in MutationObserverOptions options);
>>    void disconnect();
>> };
>>
>> where MutationCallback is
>>
>> [Callback, NoInterfaceObject]
>> interface MutationCallback {
>>     void handleEvent(in MutationRecord[] mutations, in
>> MutationObserver observer);
>> };
>>
>> Registration&  Observation
>> - A call to observe creates a registration for the observer to be
>> delivered mutations made to |target|, and optionally, its descendants.
>>
>> - Subsequent calls to the same MutationObserver made with the same
>> |target| have the effect of resetting the options associated with the
>> registration.
>>
>> - Subsequent calls to the same MutationObserver made with different
>> |targets| have the effect of expanding the set of nodes which are
>> being observed by the observer. All mutations made to all observed
>> nodes in all registrations for a given observer are delivered, in
>> time-ordered sequence, via a single invocation of the
>> MutationCallback’s handleEvent method.
>>
>> - disconnect ceases observation over the observer’s set of observed nodes.
>>
>> Registration Options
>> The |options| argument provided in observe is defined by the
>> MutationObserverOptions interface:
>>
>> interface MutationObserverOptions {
>>     // Mutation types
>>     boolean childList;  // If true, mutations affecting node’s
>> childNodes are included.
>>     boolean attribute;  // If true, mutations affecting element’s
>> attributes are included.
>
> We need to change this name, since per WebIDL 'attribute' can't be used
> here.
>
> I propose we use attr everywhere in the API. MutationRecord has already
> attrName.
> attributeOldValue -> attrOldValue and attributeFilter -> attrFilter

Good catch (and I should've caught it when typing this up, as it's
pseudo-idl), 'attr' works for me.  If that shortening isn't
appreciated, we could go with 'attributes' instead.

- Adam

>
>
>>     boolean characterData;  // If true, mutations affecting the value
>> of CharacterData
>>                                             //nodes are included.
>>     // [Note: If none of the known mutation types is specified, an
>> Error is thrown]
>>
>>     // Subtree observation
>>     boolean subtree;  // If true, the observed set of nodes for this
>> registration should include
>>                                  // descendants of MutationTarget
>> (behavior described below).
>>
>>     // Old values
>>     boolean attributeOldValue;
>>     // If true, MutationRecords descri

CfI: Progress Events is a W3C Candidate Recommendation

[Arthur Barstow]

Below is Call for Implementation for the Progress Events spec.

Anne, Ms2ger, what is the status of the Progress Events test suite (e.g. 
% complete)?


  http://w3c-test.org/webapps/ProgressEvents/tests/

 Original Message 
Subject: 	Progress Events is a W3C Candidate Recommendation (Call for 
Implementations)

Resent-Date:Mon, 26 Sep 2011 16:15:55 +
Resent-From:
Date:   Mon, 26 Sep 2011 11:15:51 -0500
From:   ext Ian Jacobs 
To: W3C Members 



Dear Advisory Committee Representative,

I am pleased to announce that Progress Events is a W3C Candidate Recommendation:
  http://www.w3.org/TR/2011/CR-progress-events-20110922/

[[ snip Member-confidential reference ]]

In response to the 9 August 2011 Last Call, only one comment was submitted and 
it resulted in editorial changes. The commenter agreed with the Editor's 
changes. There were no Formal Objections.

The WebApps Working Group plans to produce a test suite for this specification 
during the CR period.

This Call for Implementations follows section 7.4.3 of the W3C Process Document:
   http://www.w3.org/2005/10/Process-20051014/tr.html#cfi

Thank you,

For Tim Berners-Lee, Director,
Philippe Le Hégaret, Interaction Domain Lead, and
Doug Schepers, Rich Web Clients Activity Lead;
Ian Jacobs, Head of W3C Communications

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447

Re: Mutation Observers: a replacement for DOM Mutation Events

[Olli Pettay]

On 09/24/2011 12:16 AM, Adam Klein wrote:

Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.

This proposal represents our best attempt to date at making a set of
sensible trade offs which allows for a new mutation observation
mechanism that:

- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)

- Meets the goal of having the main “questions” that use-cases will
need answered about the net-effect of changes, be computable in linear
time complexity roughly proportional to the number of changes that
occurred.

Significant aspects of this design:

- Delivery of MutationRecords happens asynchronously, at the end of
the current “microtask”. This is between Options 2 and 3 from this
discussion 
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
Instead of calling listeners at the end of outermost DOM operation or
at the end of a Task, listeners are called at the end of outermost
script invocation. If there are no script invocations, listeners are
called at the end of Task.

- Information about mutations is delivered to observers as an ordered
sequence of MutationRecords, representing an observed sequence of
changes that have occurred.

- Subtree observation properly handles the case where nodes are
transiently removed from, mutated outside of and then returned to the
subtree.

- Observers specify the types of changes they are interested in and
(in some cases) level of detail they require.

Sample usage:

var observer = new MutationObserver(function(mutationRecords) {
   // Handle mutations
});

observer.observe(myNode,
{  // options:
   subtree: true;  // observe the subtree rooted at myNode
   childList: true;  // include information childNode insertion/removals
   attribute: true;  // include information about changes to attributes
within the subtree
});

…

observer.disconnect();  // Cease observation

Details:

We introduce a new interface MutationObserver with a constructor on DOMWindow:

[Constructor(in MutationCallback callback)]
interface MutationObserver {
void observe(in Node target, in MutationObserverOptions options);
void disconnect();
};

where MutationCallback is

[Callback, NoInterfaceObject]
interface MutationCallback {
 void handleEvent(in MutationRecord[] mutations, in
MutationObserver observer);
};

Registration&  Observation
- A call to observe creates a registration for the observer to be
delivered mutations made to |target|, and optionally, its descendants.

- Subsequent calls to the same MutationObserver made with the same
|target| have the effect of resetting the options associated with the
registration.

- Subsequent calls to the same MutationObserver made with different
|targets| have the effect of expanding the set of nodes which are
being observed by the observer. All mutations made to all observed
nodes in all registrations for a given observer are delivered, in
time-ordered sequence, via a single invocation of the
MutationCallback’s handleEvent method.

- disconnect ceases observation over the observer’s set of observed nodes.

Registration Options
The |options| argument provided in observe is defined by the
MutationObserverOptions interface:

interface MutationObserverOptions {
 // Mutation types
 boolean childList;  // If true, mutations affecting node’s
childNodes are included.
 boolean attribute;  // If true, mutations affecting element’s
attributes are included.


We need to change this name, since per WebIDL 'attribute' can't be used 
here.


I propose we use attr everywhere in the API. MutationRecord has already 
attrName.

attributeOldValue -> attrOldValue and attributeFilter -> attrFilter


-Olli



 boolean characterData;  // If true, mutations affecting the value
of CharacterData
 //nodes are included.
 // [Note: If none of the known mutation types is specified, an
Error is thrown]

 // Subtree observation
 boolean subtree;  // If true, the observed set of nodes for this
registration should include
  // descendants of MutationTarget
(behavior described below).

 // Old values
 boolean attributeOldValue;
 // If true, MutationRecords describing changes to attributes should
 // contain the value of the attribute before the change. If true
 // without attribute: true specified, an Error is thrown.

 boolean characterDataOldValue;
 // If true, MutationRecords describing changes to
 // CharacterData nodes should contain the value
 // of the node before the change. If true without
 // characterData: true, an Error is thrown.

 // Filtering
 DOMString[] attributeFilter;
 // If provided, only changes to attributes with localName equaling
 // one o

[Bug 14296] sorry, does this work

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14296

Ross Nicoll  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||j...@jrn.me.uk
 Resolution||NEEDSINFO

-- 
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.

[Bug 14296] New: sorry, does this work

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14296

   Summary: sorry, does this work
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#sco
pe-0
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Workers (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://www.whatwg.org/specs/web-apps/current-work/complete/workers.html
Multipage: http://www.whatwg.org/C#scope-0
Complete: http://www.whatwg.org/c#scope-0

Comment:
sorry, does this work

Posted from: 122.107.219.238
User agent: Mozilla/5.0 (X11; Linux i686; rv:9.0a1) Gecko/20110921
Firefox/9.0a1

-- 
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: Mutation Observers: a replacement for DOM Mutation Events

[Olli Pettay]

On 09/26/2011 11:47 AM, Olli Pettay wrote:

On 09/24/2011 12:16 AM, Adam Klein wrote:

Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.

This proposal represents our best attempt to date at making a set of
sensible trade offs which allows for a new mutation observation
mechanism that:

- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)

- Meets the goal of having the main “questions” that use-cases will
need answered about the net-effect of changes, be computable in linear
time complexity roughly proportional to the number of changes that
occurred.

Significant aspects of this design:

- Delivery of MutationRecords happens asynchronously, at the end of
the current “microtask”. This is between Options 2 and 3 from this
discussion
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
Instead of calling listeners at the end of outermost DOM operation or
at the end of a Task, listeners are called at the end of outermost
script invocation. If there are no script invocations, listeners are
called at the end of Task.

- Information about mutations is delivered to observers as an ordered
sequence of MutationRecords, representing an observed sequence of
changes that have occurred.

- Subtree observation properly handles the case where nodes are
transiently removed from, mutated outside of and then returned to the
subtree.

- Observers specify the types of changes they are interested in and
(in some cases) level of detail they require.

Sample usage:

var observer = new MutationObserver(function(mutationRecords) {
// Handle mutations
});

observer.observe(myNode,
{ // options:
subtree: true; // observe the subtree rooted at myNode
childList: true; // include information childNode insertion/removals
attribute: true; // include information about changes to attributes
within the subtree
});

…

observer.disconnect(); // Cease observation

Details:

We introduce a new interface MutationObserver with a constructor on
DOMWindow:

[Constructor(in MutationCallback callback)]
interface MutationObserver {
void observe(in Node target, in MutationObserverOptions options);
void disconnect();
};


Yeah, these methods could return mutationobserver.
(Although I don't like the o.observe(foo).observe(bar) kind of coding
style, since it doesn't make it clear which instance's method you're
calling. But one doesn't need to use that.)




where MutationCallback is

[Callback, NoInterfaceObject]
interface MutationCallback {
void handleEvent(in MutationRecord[] mutations, in
MutationObserver observer);
};


s/handleEvent/handleMutations/




Registration& Observation
- A call to observe creates a registration for the observer to be
delivered mutations made to |target|, and optionally, its descendants.

- Subsequent calls to the same MutationObserver made with the same
|target| have the effect of resetting the options associated with the
registration.

- Subsequent calls to the same MutationObserver made with different
|targets| have the effect of expanding the set of nodes which are
being observed by the observer. All mutations made to all observed
nodes in all registrations for a given observer are delivered, in
time-ordered sequence, via a single invocation of the
MutationCallback’s handleEvent method.

- disconnect ceases observation over the observer’s set of observed
nodes.

Registration Options
The |options| argument provided in observe is defined by the
MutationObserverOptions interface:

interface MutationObserverOptions {
// Mutation types
boolean childList; // If true, mutations affecting node’s
childNodes are included.
boolean attribute; // If true, mutations affecting element’s
attributes are included.
boolean characterData; // If true, mutations affecting the value
of CharacterData
//nodes are included.
// [Note: If none of the known mutation types is specified, an
Error is thrown]

// Subtree observation
boolean subtree; // If true, the observed set of nodes for this
registration should include
// descendants of MutationTarget
(behavior described below).

// Old values
boolean attributeOldValue;
// If true, MutationRecords describing changes to attributes should
// contain the value of the attribute before the change. If true
// without attribute: true specified, an Error is thrown.

boolean characterDataOldValue;
// If true, MutationRecords describing changes to
// CharacterData nodes should contain the value
// of the node before the change. If true without
// characterData: true, an Error is thrown.

// Filtering
DOMString[] attributeFilter;
// If provided, only changes to attributes with localName equaling
// one of the provided strings will be delivered. If provided without
// attribute: true, an Error is thrown.
};

Subtree Observation
If the subtree option

Re: XBL2 is dead.

[Dimitri Glazkov]

On Mon, Sep 26, 2011 at 12:28 AM, Anne van Kesteren  wrote:
> On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov 
> wrote:
>>
>> Further, instead of packaging Web Components into one omnibus
>> offering, we will likely end up with several free-standing specs or
>> spec addendums:
>>
>> 1) Shadow DOM, the largest bag of with XBL2's donated organs --
>> probably its own spec;
>> 2) Constructible and extensible DOM objects  which should probably
>> just be part of DOM Core and HTML;
>> 3) Declarative syntax for gluing the first 2 parts together -- HTML
>> spec seems like a good fit; and
>> 4) Confinement primitives, which is platformization of the lessons
>> learned from Caja (http://code.google.com/p/google-caja/), integrated
>> with element registration.
>
> It's still not very clear to me what any of this means and how it will fit
> together. Having either a specification or examples to shoot at would be
> helpful. Once it is more clear what each of these parts is going to look
> like, it might be easier for me to comment on how you suggest we split them.

Yessir! Working on it! :)

>
>
>> Why split it like this? Several reasons:
>>
>> a) they are independently moving parts. For example, just shadow DOM,
>> all by itself, is already a useful tool in the hands of Web
>> developers. It's our job as spec developers to ensure that these bits
>> comprise a coherent whole, but from implementation perspective, they
>> don't need to block one another.
>
> How do you construct a shadow DOM though declaratively without a component?

For consistency's sake, it seems like a pretty cool thing to do.
However, the use cases we've been working with haven't shown a need
for this. At this point, I've made peace with only being able to
construct shadow DOM imperatively without the components.

>
>
>> b) each belongs in the right place. For example, making DOM objects
>> extensible is a concern inside of the DOM Core spec. Declarative
>> syntax really needs to live in HTML. Also...
>>
>> c) some parts are too small to be their own spec.
>> Constructible/extensible DOM objects bit does not even have an API
>> surface.
>>
>> d) And finally, every bit has potential of solving problems that are
>> more general than just about components. We shouldn't require making a
>> component if all developer wants is some shadow DOM. Similarly, lack
>> of needing a component shouldn't preclude the use of confinement
>> primitives.
>>
>> Just to recap: XBL2 is dead, exploding into a pretty rainbow. I am a
>> pop tart cat in front of the rainbow.
>
> :-)

I am glad you liked it :)

:DG<

Re: [widgets] Killing file:// of evil (widget URI ready for pub)

[Marcos Caceres]

On Mon, Sep 26, 2011 at 5:26 PM, Mark Baker  wrote:
> On Mon, Sep 26, 2011 at 10:43 AM, Marcos Caceres
>  wrote:
>>> There are however many useful benefits in tying a packaged web application 
>>> (using whatever packaging) to an origin, not the least of which is 
>>> same-origin policy and overall just being a regular web app (that may 
>>> happen to have been loaded differently).
>> I still don't think it's that bad to do http://c13c6f30.whatever
>>
>> Mark, what is the issue with using sub.localhost? (i.e., why do you 
>> discourage using .localhost)?
>
> Sorry if I wasn't clear, but I wasn't discouraging it, just pointing
> out that the implementer has many options.


Ok, thanks for clarifying.


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] Killing file:// of evil (widget URI ready for pub)

[Mark Baker]

On Mon, Sep 26, 2011 at 10:43 AM, Marcos Caceres
 wrote:
>> There are however many useful benefits in tying a packaged web application 
>> (using whatever packaging) to an origin, not the least of which is 
>> same-origin policy and overall just being a regular web app (that may happen 
>> to have been loaded differently).
> I still don't think it's that bad to do http://c13c6f30.whatever
>
> Mark, what is the issue with using sub.localhost? (i.e., why do you 
> discourage using .localhost)?

Sorry if I wasn't clear, but I wasn't discouraging it, just pointing
out that the implementer has many options.

Mark.

Re: [XHR2] Avoiding charset dependencies on user settings

[Henri Sivonen]

On Mon, Sep 26, 2011 at 12:46 PM, Jonas Sicking  wrote:
> On Fri, Sep 23, 2011 at 1:26 AM, Henri Sivonen  wrote:
>> On Thu, Sep 22, 2011 at 9:54 PM, Jonas Sicking  wrote:
>>> I agree that there are no legacy requirements on XHR here, however I
>>> don't think that that is the only thing that we should look at. We
>>> should also look at what makes the feature the most useful. A extreme
>>> counter-example would be that we could let XHR refuse to parse any
>>> HTML page that didn't pass a validator. While this wouldn't break any
>>> existing content, it would make HTML-in-XHR significantly less useful.
>>
>> Applying all the legacy text/html craziness to XHR could break current
>> use of XHR to retrieve responseText of text/html resources (assuming
>> that we want responseText for text/html work like responseText for XML
>> in the sense that the same character encoding is used for responseText
>> and responseXML).
>
> This doesn't seem to only be a problem when using "crazy" parts of
> text/html charset detection. Simply looking for  in the
> first 1024 characters will change behavior and could cause page
> breakage.
>
> Or am I missing something?

Yes: WebKit already performs the  prescan for text/html when
retrieving responseText via XHR even though it doesn't support full
HTML parsing in XHR (so responseXML is still null).
http://hsivonen.iki.fi/test/moz/xhr/charset-xhr.html

Thus, apps broken by the meta prescan would already be broken in
WebKit (unless, of course, they browser sniff in a very strange way).

And apps that wouldn't be OK with using UTF-8 as the fallback encoding
when there's no HTTP-level charset, no BOM and no  in the first
1024 bytes would already by broken in Gecko.

>> Applying all the legacy text/html craziness to XHR would make data
>> loading in programs fail in subtle and hard-to-debug ways depending on
>> the browser localization and user settings. At least when loading into
>> a browsing context, there's visual feedback of character misdecoding
>> and the feedback can be attributed back to a given file. If
>> setting-dependent misdecoding happens in the XHR data loading
>> machinery of an app, it's much harder to figure out what part of the
>> system the problem should be attributed to.
>
> Could you provide more detail here. How are you imagining this data
> being used such that it's not being displayed to the user.
>
> I.e. can you describe an application that would break in a non-visual
> way and where it would be harder to detect where the data originated
> from compared to for example  usage.

If a piece of text came from XHR and got injected into a visible DOM,
it's not immediately obvious, which HTTP response it came from.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [widgets] Killing file:// of evil (widget URI ready for pub)

[Marcos Caceres]

On Monday, September 26, 2011 at 4:31 PM, Robin Berjon wrote:

> On Sep 23, 2011, at 18:26 , Mark Baker wrote:
> > Well, this is progress, but it seems the only difference now between
> > widget: and http: is the authority. And if that's the case, then
> > instead of (from your example);
> >  
> > widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
> >  
> > why not go with this?
> >  
> > http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html
>  
> Well, the advantage of a scheme is that it's solidly in the realm of the 
> implementation to decide how to handle it. We've actually been bouncing ideas 
> like the above around for a while (albeit with things like .app rather than 
> .localhost) and it's a bit scary. It means that in some cases you're doing 
> DNS resolution differently than the way in which you normally do it (which 
> might just be relying on the system).  
This is the problem I've run into at the moment. I can't seem to get around it: 
 

* Either add sub domains to localhost in the "hosts" file
* use virtual hosts in Apache
* I don't think either gives me dynamic dns capabilities (for when I start new 
widgets, I create a new subdomain… and no idea how to do it on Android… there 
is no API, AFACT).  

All the java HTTP servers I have been looking at naturally assume a TCP/IP 
socket. Replacing that with a, um, kinda native socket, is not really working 
for me.  

Anyway, I don't think there is a way around this… I think the browser will 
always do it's own network request over TCP/IP and that will need to be 
intercepted through a socket (unless widget:// is supported natively).  

> It means surprising results if you add 
> c13c6f30-ce25-11e0-9572-0800200c9a66.app to your hosts file and see it do one 
> thing in the browser and another in a widget.

Yeah :( Or trying to stop a widget from getting into the resources of another 
widget (referrer check to stop one widget getting into another widget seems 
somewhat fragile)… and the battery sucking while(true){ } for the thread that 
listens is not too nice either.  

> There are however many useful benefits in tying a packaged web application 
> (using whatever packaging) to an origin, not the least of which is 
> same-origin policy and overall just being a regular web app (that may happen 
> to have been loaded differently).
I still don't think it's that bad to do http://c13c6f30.whatever  

Mark, what is the issue with using sub.localhost? (i.e., why do you discourage 
using .localhost)?  
>  
> Overall I'd rather wait for the outcome from the Offline Web Apps workshop to 
> have a definitive opinion on which approach is best. Be sure to be there! 
> http://www.w3.org/2011/web-apps-ws/

This presupposes that someone there will have an opinion :) I was, at least, 
going to write my paper around this… but I imagine it will go a lot like… "um, 
I tried doing this… it kinda didn't work, um… yeah… so, hhmm… would be very 
useful, however" :).

Re: [widgets] Killing file:// of evil (widget URI ready for pub)

[Robin Berjon]

On Sep 23, 2011, at 18:26 , Mark Baker wrote:
> Well, this is progress, but it seems the only difference now between
> widget: and http: is the authority. And if that's the case, then
> instead of (from your example);
> 
> widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
> 
> why not go with this?
> 
> http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html

Well, the advantage of a scheme is that it's solidly in the realm of the 
implementation to decide how to handle it. We've actually been bouncing ideas 
like the above around for a while (albeit with things like .app rather than 
.localhost) and it's a bit scary. It means that in some cases you're doing DNS 
resolution differently than the way in which you normally do it (which might 
just be relying on the system). It means surprising results if you add 
c13c6f30-ce25-11e0-9572-0800200c9a66.app to your hosts file and see it do one 
thing in the browser and another in a widget.

There are however many useful benefits in tying a packaged web application 
(using whatever packaging) to an origin, not the least of which is same-origin 
policy and overall just being a regular web app (that may happen to have been 
loaded differently).

Overall I'd rather wait for the outcome from the Offline Web Apps workshop to 
have a definitive opinion on which approach is best. Be sure to be there! 
http://www.w3.org/2011/web-apps-ws/

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [widgets] Killing file:// of evil (widget URI ready for pub)

[Marcos Caceres]

On Friday, September 23, 2011 at 8:33 PM, Charles Pritchard wrote:

> I've some strong reservations about expanding the scheme into dns-land.

I''m still looking into this, but I don't know how we get around that. If you 
have any suggestions, sure would like to hear them.  


>  
>  
>  
> On Sep 23, 2011, at 9:59 AM, Mark Baker  (mailto:dist...@acm.org)> wrote:
>  
> > On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres  > (mailto:w...@marcosc.com)> wrote:
> > > > On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres
> > > > mailto:marcosscace...@gmail.com)> wrote:
> > > > Well, this is progress, but it seems the only difference now between
> > > > widget: and http: is the authority. And if that's the case, then
> > > > instead of (from your example);
> > > >  
> > > > widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
> > > >  
> > > > why not go with this?
> > > >  
> > > > http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html
> > > That might totally work:) The spec just needs to sandbox the request so 
> > > apps don't request resources from each other (i.e., I just hope it's not 
> > > hard to implement a kind of restricted-local-http server that widget:// 
> > > tries to be… hopefully you get what I mean here: requests/response is 
> > > instance specific, except where this could be used with postMessage… 
> > > Also, I was worried about muddying-up the two "protocols", even if they 
> > > are both http.
> > >  
> > > Another minor nit is that some runtimes already implement widget:// … but 
> > > then again, they also implement http, so it might all be ok. Might have a 
> > > crack at trying to implement this on Android.
> >  
> > That's great to hear, Marcos! I'll look for it in the market 8-)
> >  
> > FWIW - I should have mentioned this before - I wouldn't recommend
> > requiring the use of ".localhost", just mention it as one option that
> > implementers might consider. For devices with their own IPs or DNS
> > names, they should also have the option for using a more traditional
> > authority;
> >  
> > http:///widget-instance/c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
> >  
> > And obviously, in those cases, whether access is opened up to those
> > widgets from outside the device is up to the implementers, carriers
> > (where relevant), or (where I hope we get to eventually) user-defined
> > access control policies. But it does create some interesting
> > possibilities!
> >  
> > Mark.

[Bug 14288] New: document.documentElement.insertAdjacentHTML specs WebKit behavior instead of IE behavior

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14288

   Summary: document.documentElement.insertAdjacentHTML specs
WebKit behavior instead of IE behavior
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: DOM Parsing and Serialization
AssignedTo: ms2...@gmail.com
ReportedBy: hsivo...@iki.fi
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Consider
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1148

It throws in Chrome and per spec. It doesn't throw in IE9 or in Opera 11.51.
Given that insertAdjacentHTML is originally an IE API, shouldn't the spec
describe IE behavior instead of WebKit behavior? Is there a good reason to
throw?

-- 
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: [XHR2] Avoiding charset dependencies on user settings

[Jonas Sicking]

On Fri, Sep 23, 2011 at 4:46 AM, Henri Sivonen  wrote:
> On Fri, Sep 23, 2011 at 11:26 AM, Henri Sivonen  wrote:
>> Applying all the legacy text/html craziness
>
> Furthermore, applying full legacy text/html craziness involves parser
> restarts for GET requests. With a browsing context, that means
> renavigation, but I really don't want to support parser restarts in
> XHR.

Yeah, I don't see that there's a sane way to replicate this part of
HTML parsing.

/ Jonas

Re: [XHR2] Avoiding charset dependencies on user settings

[Jonas Sicking]

On Fri, Sep 23, 2011 at 1:26 AM, Henri Sivonen  wrote:
> On Thu, Sep 22, 2011 at 9:54 PM, Jonas Sicking  wrote:
>> I agree that there are no legacy requirements on XHR here, however I
>> don't think that that is the only thing that we should look at. We
>> should also look at what makes the feature the most useful. A extreme
>> counter-example would be that we could let XHR refuse to parse any
>> HTML page that didn't pass a validator. While this wouldn't break any
>> existing content, it would make HTML-in-XHR significantly less useful.
>
> Applying all the legacy text/html craziness to XHR could break current
> use of XHR to retrieve responseText of text/html resources (assuming
> that we want responseText for text/html work like responseText for XML
> in the sense that the same character encoding is used for responseText
> and responseXML).

This doesn't seem to only be a problem when using "crazy" parts of
text/html charset detection. Simply looking for  in the
first 1024 characters will change behavior and could cause page
breakage.

Or am I missing something?

In fact, it seems to me to be a more likely scenario that we now would
get the correct charset for many XHR-loads and thus fix more pages
than it breaks.

> Applying all the legacy text/html craziness to XHR would make data
> loading in programs fail in subtle and hard-to-debug ways depending on
> the browser localization and user settings. At least when loading into
> a browsing context, there's visual feedback of character misdecoding
> and the feedback can be attributed back to a given file. If
> setting-dependent misdecoding happens in the XHR data loading
> machinery of an app, it's much harder to figure out what part of the
> system the problem should be attributed to.

Could you provide more detail here. How are you imagining this data
being used such that it's not being displayed to the user.

I.e. can you describe an application that would break in a non-visual
way and where it would be harder to detect where the data originated
from compared to for example  usage.

/ Jonas

Re: [indexeddb] New WebIDL Exception Model for IndexedDB

[Anne van Kesteren]

On Mon, 26 Sep 2011 09:31:36 +0200, Anne van Kesteren   
wrote:
On Fri, 23 Sep 2011 00:52:39 +0200, Israel Hilerio  
 wrote:
This is our understanding on how the spec needs to change to support  
the new WebIDL exception handling model.  We would start by removing  
all of the constants from IDBDatabaseException.  After that, the only  
thing left would be message.  Do we still need to have this class  
definition?  It seems we can remove it.


In either case, we would have to continue by defining a set of  
exception types and code mappings. Each exception type will have a code  
value of 0.


The mapping will look like this:
UnknownError(0)
NonTransientError(0)
NotFoundError(0)
ConstraintError(0)
DataError(0)
NotAllowedError(0)
TransactionInactiveError(0)
AbortError(0)
ReadOnlyError(0)
TimeoutError(0)
QuotaError(0)
VersionError(0)

If we believe the message attribute is still relevant, then we would  
define the IDBDatabaseException class like this:

exception IDBDatabaseException: DOMException {
DOMString  message;
};
Using this approach, IDBDatabaseException will inherit the name and  
code properties from DOMException.


Is this what you had in mind?


The new approach is outlined here:

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c14

I should probably update DOM4 with some easy to use language, including  
how this maps to the code member.


I've done that now.

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw

If that is correct I would expect Indexed Database API to say e.g.

"throw a VersionError exception" in its prose.

We should probably keep these exceptions central somewhere so we do not  
mint similar exceptions twice. E.g. QuotaError looks like it could be the  
same as the existing QuoteExceededError.


The table in DOM4 could be that central place I suppose as other than the  
code numbers it is largely non-normative so we could update it as  
editorial changes whenever we want.


What do people think?


--
Anne van Kesteren
http://annevankesteren.nl/

Re: Mutation Observers: a replacement for DOM Mutation Events

[Olli Pettay]

On 09/24/2011 12:16 AM, Adam Klein wrote:

Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.

This proposal represents our best attempt to date at making a set of
sensible trade offs which allows for a new mutation observation
mechanism that:

- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)

- Meets the goal of having the main “questions” that use-cases will
need answered about the net-effect of changes, be computable in linear
time complexity roughly proportional to the number of changes that
occurred.

Significant aspects of this design:

- Delivery of MutationRecords happens asynchronously, at the end of
the current “microtask”. This is between Options 2 and 3 from this
discussion 
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html.
Instead of calling listeners at the end of outermost DOM operation or
at the end of a Task, listeners are called at the end of outermost
script invocation. If there are no script invocations, listeners are
called at the end of Task.

- Information about mutations is delivered to observers as an ordered
sequence of MutationRecords, representing an observed sequence of
changes that have occurred.

- Subtree observation properly handles the case where nodes are
transiently removed from, mutated outside of and then returned to the
subtree.

- Observers specify the types of changes they are interested in and
(in some cases) level of detail they require.

Sample usage:

var observer = new MutationObserver(function(mutationRecords) {
   // Handle mutations
});

observer.observe(myNode,
{  // options:
   subtree: true;  // observe the subtree rooted at myNode
   childList: true;  // include information childNode insertion/removals
   attribute: true;  // include information about changes to attributes
within the subtree
});

…

observer.disconnect();  // Cease observation

Details:

We introduce a new interface MutationObserver with a constructor on DOMWindow:

[Constructor(in MutationCallback callback)]
interface MutationObserver {
void observe(in Node target, in MutationObserverOptions options);
void disconnect();
};


Yeah, these methods could return mutationobserver.
(Although I don't like the o.observe(foo).observe(bar) kind of coding
 style, since it doesn't make it clear which instance's method you're
 calling. But one doesn't need to use that.)




where MutationCallback is

[Callback, NoInterfaceObject]
interface MutationCallback {
 void handleEvent(in MutationRecord[] mutations, in
MutationObserver observer);
};


s/handleEvent/handleMutations/




Registration&  Observation
- A call to observe creates a registration for the observer to be
delivered mutations made to |target|, and optionally, its descendants.

- Subsequent calls to the same MutationObserver made with the same
|target| have the effect of resetting the options associated with the
registration.

- Subsequent calls to the same MutationObserver made with different
|targets| have the effect of expanding the set of nodes which are
being observed by the observer. All mutations made to all observed
nodes in all registrations for a given observer are delivered, in
time-ordered sequence, via a single invocation of the
MutationCallback’s handleEvent method.

- disconnect ceases observation over the observer’s set of observed nodes.

Registration Options
The |options| argument provided in observe is defined by the
MutationObserverOptions interface:

interface MutationObserverOptions {
 // Mutation types
 boolean childList;  // If true, mutations affecting node’s
childNodes are included.
 boolean attribute;  // If true, mutations affecting element’s
attributes are included.
 boolean characterData;  // If true, mutations affecting the value
of CharacterData
 //nodes are included.
 // [Note: If none of the known mutation types is specified, an
Error is thrown]

 // Subtree observation
 boolean subtree;  // If true, the observed set of nodes for this
registration should include
  // descendants of MutationTarget
(behavior described below).

 // Old values
 boolean attributeOldValue;
 // If true, MutationRecords describing changes to attributes should
 // contain the value of the attribute before the change. If true
 // without attribute: true specified, an Error is thrown.

 boolean characterDataOldValue;
 // If true, MutationRecords describing changes to
 // CharacterData nodes should contain the value
 // of the node before the change. If true without
 // characterData: true, an Error is thrown.

 // Filtering
 DOMString[] attributeFilter;
 // If provided, only changes to attributes with l

Re: [indexeddb] New WebIDL Exception Model for IndexedDB

[Anne van Kesteren]

On Fri, 23 Sep 2011 00:52:39 +0200, Israel Hilerio   
wrote:
This is our understanding on how the spec needs to change to support the  
new WebIDL exception handling model.  We would start by removing all of  
the constants from IDBDatabaseException.  After that, the only thing  
left would be message.  Do we still need to have this class definition?   
It seems we can remove it.


In either case, we would have to continue by defining a set of exception  
types and code mappings. Each exception type will have a code value of 0.


The mapping will look like this:
UnknownError(0)
NonTransientError(0)
NotFoundError(0)
ConstraintError(0)
DataError(0)
NotAllowedError(0)
TransactionInactiveError(0)
AbortError(0)
ReadOnlyError(0)
TimeoutError(0)
QuotaError(0)
VersionError(0)

If we believe the message attribute is still relevant, then we would  
define the IDBDatabaseException class like this:

exception IDBDatabaseException: DOMException {
DOMString  message;
};
Using this approach, IDBDatabaseException will inherit the name and code  
properties from DOMException.


Is this what you had in mind?


The new approach is outlined here:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c14

I should probably update DOM4 with some easy to use language, including  
how this maps to the code member.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: XBL2 is dead.

[Anne van Kesteren]

On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov  
 wrote:

Further, instead of packaging Web Components into one omnibus
offering, we will likely end up with several free-standing specs or
spec addendums:

1) Shadow DOM, the largest bag of with XBL2's donated organs --
probably its own spec;
2) Constructible and extensible DOM objects  which should probably
just be part of DOM Core and HTML;
3) Declarative syntax for gluing the first 2 parts together -- HTML
spec seems like a good fit; and
4) Confinement primitives, which is platformization of the lessons
learned from Caja (http://code.google.com/p/google-caja/), integrated
with element registration.


It's still not very clear to me what any of this means and how it will fit  
together. Having either a specification or examples to shoot at would be  
helpful. Once it is more clear what each of these parts is going to look  
like, it might be easier for me to comment on how you suggest we split  
them.




Why split it like this? Several reasons:

a) they are independently moving parts. For example, just shadow DOM,
all by itself, is already a useful tool in the hands of Web
developers. It's our job as spec developers to ensure that these bits
comprise a coherent whole, but from implementation perspective, they
don't need to block one another.


How do you construct a shadow DOM though declaratively without a component?



b) each belongs in the right place. For example, making DOM objects
extensible is a concern inside of the DOM Core spec. Declarative
syntax really needs to live in HTML. Also...

c) some parts are too small to be their own spec.
Constructible/extensible DOM objects bit does not even have an API
surface.

d) And finally, every bit has potential of solving problems that are
more general than just about components. We shouldn't require making a
component if all developer wants is some shadow DOM. Similarly, lack
of needing a component shouldn't preclude the use of confinement
primitives.

Just to recap: XBL2 is dead, exploding into a pretty rainbow. I am a
pop tart cat in front of the rainbow.


:-)


--
Anne van Kesteren
http://annevankesteren.nl/