Re: CfC: move WebApps' test suites to Github; deadline March 22

[Charles McCathie Nevile]

On Fri, 15 Mar 2013 17:40:18 +0100, Arthur Barstow   
wrote:


As you probably know, the HTMLWG recently moved its test suite to GitHub  
(GH). Tobie, Robin, Odin, Ms2ger and others propose WebApps do the same  
and this is a Call for Consensus to do so.


We support the move.

cheers

Odin defined the new testing process for GH in [Proposal] and this will  
replace most, if not all, of the testing processes already agreed  
[Testing]. (Some things like using testharness.js will remain the same.)


Assuming this CfC passes:

* [Proposal] will likely be updated as we gain experience with GH and  
may be replaced by more general information like  
.


* The root of the repository will be the same as HTML(WG):  
 and each of WebApps' specs  
will have its own subdir. For example the Web Storage test suite would  
be .


* WebApps' hg test repository  will  
become Read-only (i.e. write access will be turned off).


* Tobie, Robin, Odin and Ms2ger will do the work of the move (Test  
Facilitators are not required to do the work).


If you have any comments or concerns about this CfC, please reply to  
this e-mail by March 22 at the latest. Positive response is preferred  
and encouraged, and silence will be considered as agreement with the  
proposal.


-Thanks, AB

[Proposal] 
[Testing] 





--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: [webcomponents]: Making produce DocumentFragments

[Dimitri Glazkov]

On Thu, Mar 14, 2013 at 8:09 PM, Dominic Cooney  wrote:

> On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov wrote:
>
>> Here's one scenario where keeping components Documents might be a good
>> idea. Suppose you just built a multi-threaded parser into your renderer
>> engine, and you would like to hook it up to start loading multiple
>> components in parallel. How difficult will it be for you to do this if they
>> were all just DocumentFragments in the same document?
>>
>
> Given that having components be parsed in the same document complicates
> the specification, complicates the implementation (for example resolving
> relative resources), might threaten some optimizations (multi-threaded
> parsing), and gives a benefit that authors could achieve using tools to
> crunch multiple component files into one, I propose that:
>
> Each resource is loaded in its own document.
>
> What about the type of the Component's content attribute? Should that be
> DocumentFragment or Document?
>

Might as well be Document, then. Why create an extra DocumentFragment,
right?

:DG<

Re: [webcomponents] linking using ?

[Dimitri Glazkov]

Hi Mike, the spec you're looking for is under development here:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html

:DG<


On Fri, Mar 15, 2013 at 7:07 AM, Mike Kamermans  wrote:

> Hey all,
>
> I searched the archive at
> http://lists.w3.org/Archives/Public/public-webapps/ and checked out
> the
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#definitions
> and
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
> specs, but couldn't find anything about this in them:
>
> are there provisions in the spec (or is it in the works) to add a new
> link type so that if some person A defines a stack of useful
> templates, and person B wants to use those templates, they can include
> them on their own page using  href="http://personA/templates.html";> (or rel="components", or some
> other relation name that makes sense for the role the link plays)?  I
> was thinking about this in terms of using web components for something
> like Mozilla's Popcorn Maker, where it would be really cool if we
> could define all our components as templates, and then tell everyone
> "this is our collection of templates, go grab
> popcorn.webmaker.org/templates.html if you want to use these on your
> own pages!". I really love the idea of web components, but it feels
> like being able to share them in the same way you can share .js or
> ..css files would make them ridiculously powerful on the future web =)
>
> - Mike "Pomax" Kamermans
> Mozilla Foundation
>
>
>

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Fri, Mar 15, 2013 at 6:57 PM, Vincent Scheib  wrote:
> I have added onipointerlockchange and onpointerlockerror to the partial
> document IDL in the pointer lock specification.
>
> Webkit currently only defines these event handler attributes on document.
> Unless a reason is raised to add them elsewhere, I do not plan to add
> additional attributes elsewhere, for reasons discussed in fullscreen
> specification primarily regarding the confusing when releasing exiting due
> to an element being removed from the DOM, and confusion over multiple
> listener points.
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
> https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html

FWIW, in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637 Ian
argues for Window/ due to their bubbling nature.


-- 
http://annevankesteren.nl/

Re: Pointer lock updated with clarification of lock and focus requirements.

[Glenn Maynard]

On Fri, Mar 15, 2013 at 5:24 PM, Vincent Scheib  wrote:

> After discussion with Olli Pettay I have clarified portions of the pointer
> lock specification.
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
> https://dvcs.w3.org/hg/pointerlock/diff/6543d83c0b74/index.html
>
> When requesting pointer lock, this paragraph replaces previous statements
> regarding the target being in the DOM tree.
> """
> Pointer lock must succeed only if the target is in the active document of
> a browsing context which is (or has an ancestor browsing context which is)
> in focus by a window which is in focus by the operating system's window
> manager. The target element and its browsing context need not be in focus.
> """
>
> In Requirements, clarification was added that focus MAY be shifted out of
> a document and into others without exiting lock:
> """
> The Pointer Lock API must exit the pointer lock state if the target is
> removed from its document, or the user agent, window, or tab loses focus.
> Moving focus between elements of active documents, including between
> browsing contexts, does not exit pointer lock. E.g. using the keyboard to
> move focus between contents of frames or iframes will not exit.
> """
>
> Feedback and suggestions welcome.
>

Why would pointer lock care about focus?  If the browsing context doesn't
have focus, pointer lock may be released at the system level, but that
should be transparent to the page and reestablished automatically if the
user returns.  Pages shouldn't need to care about this.

This is the same as fullscreen--obviously a page shouldn't be forced out of
fullscreen if the user switches to another tab or application, unless
that's the system convention (which it isn't on any platform I know of).

(By the way, if a web specification finds itself talking about "windows" or
"window managers" or "tabs" normatively, something is probably wrong.
Interfaces at a higher abstraction level than browsing contexts are
implementation details.  Please see
http://www.whatwg.org/specs/web-apps/current-work/#dom-document-hasfocusfor
platform-independent language.)

-- 
Glenn Maynard

Re: [IndexedDB] Closing connection in a versionchange transaction

[Jonas Sicking]

On Fri, Nov 30, 2012 at 3:26 PM, Joshua Bell  wrote:
> A spec oddity that we noticed - if you explicitly close a connection during
> an upgradeneeded handler (or elsewhere in the transaction), the transaction
> should complete (not abort) yet the connection fails (error), upgrading the
> database but leaving you without a connection.
>
> Example:
>
> var req = indexedDB.open('db' + Date.now(), 2);
> var db;
> req.onupgradeneeded = function() {
>   db = req.result;
>   var trans = req.transaction;
>   trans.oncomplete = function() { alert("transaction completed"); }; //
> should show
>   db.createObjectStore('new-store');
>   db.close();
> };
> req.onsuccess = function() { alert("unexpected success); }; // should NOT
> show
> req.onerror = function() { alert("connection error, version is: " +
> db.version); }; // should show, with 2
>
> ... and a subsequent open would reveal that the version is 2 and the the
> store exists.
>
> This behavior is specified by 4.1 "Opening a database" step 8: ...If the
> "versionchange" transaction in the previous step was aborted, or if
> connection is closed, return a DOMError of type AbortError and abort these
> steps. In either of these cases, ensure that connection is closed by running
> the steps for closing a database connection before these steps are aborted.
>
> ... and the specifics of 4.10 around closePending, which ensure that calling
> close() has no effect on running transactions.

It does seem to make sense to produce an error from a .open() call
unless the database was successfully opened. I don't feel strongly
though and don't recall why we defined it this way.

> The one spec wrinkle might be that in 4.10 "Database closing steps", the
> spec says "Wait for all transactions _created_ using /connection/ to
> complete..." where _created_ references "A transaction is created using
> IDBDatabase.transaction." which is not true of versionchange transactions.

Yeah. This should probably make sure to cover all transactions.

/ Jonas

Re: [IndexedDB] Attributes with undefined vs. null

[Jonas Sicking]

On Wed, Nov 7, 2012 at 10:53 AM, Joshua Bell  wrote:
> Various atttributes in IndexedDB signal "no value" with |undefined|:
>
> IDBKeyRange.lowerBound (if not set)
> IDBKeyRange.upperBound (if not set)
> IDBRequest.result (on error, or on successful deleteDatabase/get with no
> value/delete/clear)
> IDBCursor.key (if no found record)
> IDBCursor.primaryKey (if no found record)
> IDBCursorWithValue.value (if no found record)
>
> It's been pointed out that most Web platform specs use |null| rather than
> |undefined| for signaling these states. I seem to recall a push in the
> direction of using |undefined| rather than |null| in the IndexedDB spec bit
> over a year ago, but my bugzilla-fu was weak. Can anyone discuss or justify
> this deviation from the norm?
>
> (I feel like there's been a trend over the past few years in embrace
> ECMAScript's |undefined| value rather than trying to pretend it doesn't
> exist, but that may be my imagination. IDB's use of |undefined| didn't
> strike me as unusual until it was pointed out.)

I think ECMAScript generally tries to think of 'undefined' as 'no
value' whereas 'null' means 'no object'.

So I think in the above cases 'undefined' seems like a better fit.

I don't feel strongly though.

/ Jonas

Re: [IndexedDB] better way of deleting records

[Jonas Sicking]

On Tue, Jan 15, 2013 at 7:19 PM, Kyaw Tun  wrote:
> From developer point of view, IDBObjectStore.delete method cannot be used
> directly in most use case, since IDBObjectStore.delete returns undefined.
> IDBObjectStore.delete(random_key) always receives onsuccess event, but
> nothing happen. Currently I use cursor or count method before deleting to
> make sure that it will actually be deleted. My suggestion is
> IDBObjectStore.delete return number of records deleted and
> IDBObjectStore.clear return undefined. Hence IDBObjectStore.clear will take
> optional key or key range.

The tricky situation is that while a count(key) followed by
delete(key) is generally slower than a delete(key) which returned the
number of records deleted, in many implementations it's slower to do a
delete(key) which counts the number of deleted records, than one which
doesn't.

So if we mandated that delete(key) counted the number of records
deleted, that would be a performance hit in cases when the caller
doesn't care about the count.

One option would be to add an argument to .delete(key) which specifies
if the count should be calculated or not. Or introduce a
.deleteWithCount(key) function.

> There is no efficient way to delete records by secondary key or index key.
> IDBIndex do not have delete methods. Currently we have to use openCursor and
> delete one by one. Interestingly again, we cannot delete with more efficient
> openKeyCursor. Deleting from openKeyCursor should be allowed.

I agree that we should make it possible to delete from a key cursor.
We should also make it possible to call .update() on a key cursor.

/ Jonas

[Bug 17681] [IndexedDB] Operations that raise multiple exceptions types should define order

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17681

Jonas Sicking  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Jonas Sicking  ---
Reopening. This bug was specifically about specifying order between all
exception types. I agree that generally it doesn't matter which exception is
thrown, but if we don't think that should be defined, then we should mark this
bug WONTFIX rather than FIXED.

I do think it would be good to define all exception orders though.

One way to do it would be to have a global list that defines some sort of
priority based on exception type. So if both a TransactionInactiveError and a
ReadOnlyError test is failing, we always throw ReadOnlyError. And if
ReadOnlyError and DataError both are possible, then we throw DataError.

Or something like that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Jonas Sicking]

On Wed, Mar 6, 2013 at 10:14 AM, Alec Flett  wrote:
> My primary takeaway from both working on IDB and working with IDB for some
> demo apps is that IDB has just the right amount of complexity for really
> large, robust database use.. but for a "welcome to noSQL in the browser" it
> is way too complicated.
>
> Specifically:
>
> versioning - The reason this exists in IDB is to guarantee a schema (read: a
> fixed set of objectStores + indexes) for a given set of operations.
> Versioning should be optional. And if versioning is optional, so should
> opening - the only reason you need to "open" a database is so that you have
> a handle to a versioned database. You can almost implement versioning in JS
> if you really care about it...(either keep an explicit key, or auto-detect
> the state of the schema) its one of those cases where 80% of versioning is
> dirt simple  and the complicated stuff is really about maintaining version
> changes across multiply-opened windows. (i.e. one window opens an idb, the
> next window opens it and changes the schema, the first window may need to
> know that and be able to adapt without breaking any in-flight transactions)

Yeah, the versioning is the part of the API that I'm least happy with.

The reason we need it is because we're synchronously exposing the
"schema" of the database. Instead we could have made the set of object
stores and indexes entirely dynamic and created on-demand.

However that would have made it tricky to do schema which has
constraints (like the "unique" index-flag) or that affects how data is
stored (for example the ability to set a collation on an objectStore
or index as has been discussed).

> transactions - Also should be optional. Vital to complex apps, but totally
> not necessary for many.. there should be a default transaction, like
> db.objectStore("foo").get("bar")

I disagree. This would have made it too trivial to create pages that
have race conditions. I.e. people would write code like:

db.objectStore("foo").get("bar").onsuccess = function(e) {
  db.objectStore("foo").set("bar", e.target.result + 1)
}

without realizing that that contains a race condition.

> transaction scoping - even when you do want transactions, the api is just
> too verbose and repetitive for "get one key from one object store" -
> db.transaction("foo").objectStore("foo").get("bar") - there should be
> implicit (lightweight) transactions like db.objectStore("foo").get("bar")

We used to have this exact syntax, but it got everyone confused about
what how the implicit transaction actually worked.

> forced versioning - when versioning is optional, it should be then possible
> to change the schema during a regular transaction. Yes, this is a lot of
> rope but this is actually for much more complex apps, rather than simple
> ones. In particular, it's not uncommon for more complex database systems to
> dynamically create indexes based on observed behavior of the API, or
> observed data (i.e. when data with a particular key becomes prevalent,
> generate an index for it) and then dynamically use them if present. At the
> moment you have to do a manual close/open/version change to dynamically bump
> up the version - effectively rendering fixed-value versions moot (i.e. the
> schema for version 23 in my browser may look totally different than the
> schema for version 23 in your browser) and drastically complicating all your
> code (Because if you try to close/open while transactions are in flight,
> they will be aborted - so you have to temporarily pause all new
> transactions, wait for all in-flight transactions to finish, do a
> close/open, then start running all pending/paused transactions.) This last
> case MIGHT be as simple as adding db.reopen(newVersion) to the existing
> spec.

Yeah, this is something that I've run into as well. It's tricky to
solve this without removing the ability to synchronously access the
list of objectStores and indexes, or without introducing race
conditions if a page is open in multiple tabs.

> named object stores - frankly, for many use cases, a single objectStore is
> all you need. a simple db.get("foo") would be sufficient. Simply naming a
> "default" isn't bad - whats bad is all the onupgradeneeded scaffolding
> required to create the objectstore in the first place.

I think we should do this as part of a simple API. Similar to something like

https://github.com/slightlyoff/async-local-storage

> I do think that the IDBRequest model needs tweaking, and Futures seem like
> the obvious direction to head in.

Yup. Though see the list of constraints in my previous email in this thread.

> FWIW, the "sync" version of the API is more or less dead - nobody has
> actually implemented it.

We're actually working on an implementation and hope to have it ready mid year.

/ Jonas

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Jonas Sicking]

On Wed, Mar 6, 2013 at 6:01 AM, Alex Russell  wrote:
> I've avoided weighing in on this thread until I had more IDB experience.
> I've been wrestling with it on two fronts of late:
>
> A re-interpretation of the API based on Futures:
> https://github.com/slightlyoff/DOMFuture/tree/master/reworked_APIs/IndexedDB
> A new async LocalStorage design + p(r)olyfill that's bootstrapped on IDB:
> https://github.com/slightlyoff/async-local-storage
>
> While you might be right that it's unlikely that the API can be
> "simplified", I think it's trivial to extend it in ways that make it easier
> to reason about and use.
>
> This thread started out with a discussion of what might be done to keep
> IDB's perceived mistakes from reoccurring. Here's a quick stab at both an
> outline of the mistakes and what can be done to avoid them:
>
> Abuse of events
> The current IDB design models one-time operations using events. This can
> make sense insofar as events can occur zero or more times in the future, but
> it's not a natural fit. What does it mean for oncomplete to happen more than
> once? Is that an error? Are onsuccess and onerror exclusive? Can they both
> be dispatched for an operation? The API isn't clear. Events don't lead to
> good design here as they don't encapsulate these concerns. Similarly, event
> handlers don't chain. This is natural, as they could be invoked multiple
> times (conceptually), but it's not a good fit for data access. It's great
> that IDB as async, and events are the existing DOM model for this, but IDB's
> IDBRequest object is calling out for a different kind of abstraction. I'll
> submit Futures for the job, but others might work (explicit callback,
> whatever) so long as they maintain chainability + async.

Whether it's an "abuse" of events or not I guess is a matter of opinion.

DOM Events have always been used in situations when the Event fired
either 0 or 1 time. They've even been used in situations when an
eventual success/error has been signaled. In particular the "load" and
"error" events for Documents were among some of the first Events
created.

That said, I agree that Events are generally a better fit for
situations when you have a reoccurring "thing" that happen.

And yes, if we had had Futures when we designed IDB it might have lead
to a much easier to use API. We had a hunch that that was the case
when we designed the API. However there weren't then, and there still
aren't, a standardized promise API.

We felt then, and I still feel that way now, that it would have been a
mistake to standardize a promise library as part of a database API.
This is why I've been pushing for someone to step up and take on
creating a standardized promise library that we can rely on for future
APIs.

https://twitter.com/SickingJ/status/20215262974322

> Implicitness
> IDB is implicit in a number of places that cause confusion for folks not
> intimately familiar with the contract(s) that IDB expects you to enter into.
> First, the use of events for delivery of notifications means that
> sequential-looking code that you might expect to have timing issues doesn't.
> Why not? Because IDB operates in some vaguely async way; you can't reason at
> all about events that have occurred in the past (they're not values, they're
> points in time).

You seem to be under the impression that Events are only used/intended
for situations when something will happen "zero or more times at some
point in the future". I agree that this is the scenario when Events
really shine. Especially when that something is connected to DOM
Nodes.

However the way they are actually used in the DOM platform is as a
generic way of doing callbacks.

So despite the fact that IDB uses Events, it still has quite strict
requirements in which order they fire. Having a strict order of
delivering results was a quite intentional design decision.

> I can't find anywhere in the spec that the explicit
> gaurantees about delivery timing are noted
> (http://www.w3.org/TR/IndexedDB/#async-api),

https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#steps-for-asynchronously-executing-a-request

See in particular step 4 which guarantees that requests are run and
deliver their result in the order they were scheduled.

> so one could read IDB code that
> registers two callbacks as having a temporal dead-zone: a space in code
> where something might have happened but which your code might not have a
> chance to hear about. I realize that in practice this isn't the case; event
> delivery for these is asynchronous, but the soonest timing isn't defined:
> end of turn? next turn? end-of-microtask? This means that it's possible to
> have implementations the differ on delivery timing, astonishing those who
> register event handlers at the wrong time. This is part DOM-ish use of
> events for things they're not suited to and a lack of specificity in the
> spec. Both can be fixed.

I agree that this is something that is vague right now. The intent is
that a