Re: It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Boris Zbarsky
On 5/9/14, 12:26 AM, Jungkee Song wrote: Right. We're defining an AsyncMap interface [1] which Cache interface and CacheList interface are based off of. AsyncMap isn't spec'd yet in any place than in the .ts file. A difficulty encountered is we don't have any IDL construct for this yet. Any sugge

Re: Why do keys() and values() on CacheList in ServiceWorkers not return promises

2014-05-08 Thread Jungkee Song
On May 9, 2014 1:16 PM, "Boris Zbarsky" wrote: > > In particular, given that get() wants to return a Promise, why do we want values() to return a list of Cache objects synchronously? > > Similar for keys(): if has() needs to be async, then how can has() be sync. > Exactly. both values() and keys(

RE: It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Domenic Denicola
From: Jungkee Song [mailto:jungk...@gmail.com] > Right. We're defining an AsyncMap interface [1] which Cache interface and > CacheList interface are based off of. AsyncMap isn't spec'd yet in any place > than in the .ts file. A difficulty encountered is we don't have any IDL > construct for th

Re: It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Jungkee Song
On May 9, 2014 12:18 PM, "Boris Zbarsky" wrote: > > I'm looking at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-listhere. > > The point of [MapClass] (assuming [MapClass] stays in the WebIDL spec at all) is to declare interfaces that quack enough like Map that i

Re: It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Boris Zbarsky
On 5/9/14, 12:14 AM, Domenic Denicola wrote: As an aside, I filed https://github.com/heycam/webidl/issues/11 regarding [MapClass]. Yeah, agreed. ArrayClass makes sense, because the Array methods are generic. But MapClass as currently specced just doesn't. -Boris

RE: It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Domenic Denicola
Agreed, this was odd to me. As an aside, I filed https://github.com/heycam/webidl/issues/11 regarding [MapClass]. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mozilla.com] Sent: Thursday, May 8, 2014 23:15 To: public-webapps Subject: It doesn't make sense to use [MapClass] fo

Why do keys() and values() on CacheList in ServiceWorkers not return promises

2014-05-08 Thread Boris Zbarsky
In particular, given that get() wants to return a Promise, why do we want values() to return a list of Cache objects synchronously? Similar for keys(): if has() needs to be async, then how can has() be sync. -Boris

Re: Service worker spec should probably not use IDL arrays

2014-05-08 Thread Boris Zbarsky
On 5/9/14, 12:05 AM, Jungkee Song wrote: Addressed: https://github.com/slightlyoff/ServiceWorker/commit/0035befac6c49df5b2e7a171ce26aa96c516a32d Thanks! -Boris

Re: Service worker spec should probably not use IDL arrays

2014-05-08 Thread Jungkee Song
On May 9, 2014 12:19 PM, "Boris Zbarsky" wrote: > > IDL arrays are not really supported by any UA, and it's not clear to me that any plan to do it. The trend has been toward using ES arrays instead (which typically means IDL sequences). > > At first glance, every use of IDL arrays in service work

Service worker spec should probably not use IDL arrays

2014-05-08 Thread Boris Zbarsky
IDL arrays are not really supported by any UA, and it's not clear to me that any plan to do it. The trend has been toward using ES arrays instead (which typically means IDL sequences). At first glance, every use of IDL arrays in service workers could in fact be a sequence without causing any

It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Boris Zbarsky
I'm looking at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-list here. The point of [MapClass] (assuming [MapClass] stays in the WebIDL spec at all) is to declare interfaces that quack enough like Map that it makes sense to have them be instanceof Map and h

[Bug 25567] [imports]: Specify how media queries and html imports work together

2014-05-08 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25567 Morrita Hajime changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 24043] [Custom]: Need to check writable too.

2014-05-08 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24043 Dimitri Glazkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

PSA: First Public Working Draft of Service Workers published

2014-05-08 Thread Arthur Barstow
The First Public Working Draft of Service Workers was published today: <http://www.w3.org/TR/2014/WD-service-workers-20140508/> Congrats Jungkee and Alex and thanks to Philippe for preparing the `pub ready` version. -AB

Re: Custom Elements: 'data-' attributes

2014-05-08 Thread Brian Kardell
On Thu, May 8, 2014 at 5:37 AM, Anne van Kesteren wrote: > On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa wrote: > > The answer to that question, IMO, is no. It's not safe to use custom > > attributes without 'data-' if one wanted to write a forward compatible > HTML > > document. > > Note that

Re: Custom Elements: 'data-' attributes

2014-05-08 Thread Ian Hickson
On Thu, 8 May 2014, Bruce Lawson wrote: > On 7 May 2014 20:03, Ian Hickson wrote: > > > > Requiring a dash is pretty ugly. I would allow any attribute, and > > we'll just have to be careful when introducing new global ones. > > I think the ship HMS Ugly has already sailed, given a dash is compul

[Bug 25610] New: [imports]: Want an informative section about implications of how CSP + Imports is defined

2014-05-08 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25610 Bug ID: 25610 Summary: [imports]: Want an informative section about implications of how CSP + Imports is defined Product: WebAppsWG Version: unspecified Hardware: PC

Re: Custom Elements: 'data-' attributes

2014-05-08 Thread Anne van Kesteren
On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa wrote: > The answer to that question, IMO, is no. It's not safe to use custom > attributes without 'data-' if one wanted to write a forward compatible HTML > document. Note that the question is scoped to custom elements, not elements in general. It

Re: Custom Elements: 'data-' attributes

2014-05-08 Thread Bruce Lawson
On 7 May 2014 20:03, Ian Hickson wrote: > > Requiring a dash is pretty ugly. I would allow any attribute, and we'll > just have to be careful when introducing new global ones. I think the ship HMS Ugly has already sailed, given a dash is compulsory for the names of custom elements. Also, requiri