Alex Russell | 4 Jul 13:26 2015

Informal Service Worker working session

Hey all,

Apologies for the late notice. 

As many SW participants are going to be in town for the WebApps F2F on the 21st, Google San Francisco is hosting a working day, 9am-5pm PST on July 20th to work through open issues and discuss future work.

If you're attending, or would like to, simply RSVP here:

bugzilla | 3 Jul 15:42 2015

[Bug 28890] New: scroll should be a simple Event not a UIEvent

            Bug ID: 28890
           Summary: scroll should be a simple Event not a UIEvent
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: UI Events
          Assignee: garykac@...
          Reporter: rbyers@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...

AFAIK all browsers implement it just as 'Event'.  Gary says the WG planned to
change the spec (  This sounds like a good idea to
me (makes my life easier:

I could imagine there might be reasons to want to add to the scroll event in
the future (eg. I've wanted velocity and maybe other properties on it), but we
can cross that bridge if/when we come to it.


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

timeless | 3 Jul 03:38 2015

Re: CR: Web Storage (Second Edition)

> Particpate: [sic]

> the event must have its key attribute initialised to the name of the key in question,

`initialized` [About 11,800,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of
`initialised` [About 553,000 results]

> but require the user to authorise access to local storage areas.

`authorize` [About 80,100,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of `authorise` [About 6,960,000

> Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after.

sought-after [1]

> Each site has its own separate storage area.

area => areas | storage => local storage

> ("must", "should", "may", etc)


> If the given key does exist in the list, and its value is not equal to value, then it must have its value
updated to value. If its previous value is equal to value, then the method must do nothing.
> if the methods did not throw an exception or "do nothing" as defined above

it'd be nice if the above sections underlined/otherwise styled `do nothing`.

> User agents should always avoid deleting data while a script that could access that data is running.

consider a script which does:

var global_state = window.localStorage.getItem("value");
function uses_global_state() { if (global_state == 5) { .... }}
window.setTimeout(uses_global_state, 2000000);

between the script's initial execution, and the firing of the timeout,
is the script considered to be `running`?


Anne van Kesteren | 2 Jul 09:05 2015

Custom Elements: "createdCallback" & cloning

In the interest of moving forward I tried to more seriously consider
Dmitry's approach. Based on es-discussion discussion
it seems likely new JavaScript features (such as private state) will
be tied to object creation. This makes the prototype-swizzling design
even less appealing, in my opinion.

Meanwhile, I have not made much progress on the cloning question. As
Domenic pointed out, that would also either require
prototype-swizzling or invoking the constructor, there's not really a
third way. I guess for that to work cloneNode() and various editing
operations would have to become resilient against JavaScript executing
in the middle of them, something that has caused (is causing?) us a
ton of headaches with mutation events. (Or the alternative, have some
kind of mode switch for the DOM which is similarly a large

Not sure what to do now :-/



Tab Atkins Jr. | 1 Jul 01:48 2015

[shadow-dom] ::before/after on shadow hosts

I was recently pointed to this StackOverflow thread
which asks what happens to ::before and ::after on shadow hosts, as
it's not clear from the specs.  I had to admit that I hadn't thought
of this corner-case, and it wasn't clear what the answer was!

In particular, there seem to be two reasonable options:

1. ::before and ::after are *basically* children of the host element,
so they get suppressed when the shadow contents are displayed

2. ::before and ::after aren't *really* children of the host element,
so they still show up before/after the shadow contents.

According to the SO thread (I haven't tested this myself), Firefox and
Chrome both settled on #2.  I'm fine to spec this in the Scoping
module, I just wanted to be sure this was the answer we wanted.


Anne van Kesteren | 30 Jun 11:55 2015

Components F2F

Can someone update with a
bit more information? I hear it might be in Mountain View?

Will we have sufficient time to cover both Custom Elements and Shadow
DOM? And could the drafts maybe be updated to cover what has been
agreed to so far? E.g. it seems we have agreement on slots and I think
that was the last major thing from Shadow DOM that needed a solution.
Would be great if we could review a complete document.



Arthur Barstow | 29 Jun 18:03 2015

[admin] WebEx has replaced Zakim

The consortium's Zakim voice conference bridge has been replaced with 
WebEx [1][2][3]. The group's meeting page [4] has been updated to 
reflect this change and calendar invitations were created for the three 
reoccurring telecons:

1. D3E/UI Events <>

2. Editing APIs <>

3. Web Components <>

If you have any Qs, issues, etc. please let us know.

-Thanks, AB

[1] <>
[2] <>
[3] <>
[4] <>

Wez | 26 Jun 12:49 2015

Re: Clipboard API: remove dangerous formats from mandatory data types

Florian, as I pointed out earlier, this proposal is to remove the requirement that user agents allow content to set the local system clipboard directly with certain pre-existing clipboard formats, because doing so safely is not possible in general. Removing the requirement from the spec will simply mean that the spec more accurately reflects what is actually implemented in existing user agents.

Defining how user agents can/should support setting of arbitrary formats is a separate discussion; user agents don't generally support that - including not supporting application/octet-stream, which the spec doesn't actually define the behaviour of! - so it would in effect be a new feature of the API the behaviour of which would need to be properly specified. Please feel free to fork this thread if that's something you'd like to propose ideas for. :)


On Thu, 25 Jun 2015 at 19:13 Florian Bösch <> wrote:
I think you underestimate the integrative need that web-apps will acquire and the lengths they will go to faced with a business need to make it work once "clipboard API" becomes common developer knowledge.
Ashley Gullen | 24 Jun 14:48 2015

Detecting image encoding/decoding support

While drafting I realised that there is no way to tell in JS what image formats the browser can decode (with Image or ImageBitmap objects) or encode (with canvas toDataURL()/toBlob() or the ImageBitmap.toBlob() method I was proposing).

HTMLMediaElement.canPlayType() can give an indication if an audio or video format can be decoded. MediaRecorder.canRecordMimeType() can give an indication if an audio or video format can be encoded. Should we not have the same for images? For example there are a number of image formats beyond PNG and JPEG which some browsers support, such as:
- JPEG 2000 (Safari)
- JPEG XR (IE/Edge)
- WebP (Blink)
- APNG (Firefox, Safari)
- any other future formats

Most client-side detection I've seen involves either trying to load a data URI included in the source, or using canvas' toDataURL() and seeing if the resulting data URI includes the expected MIME type. I think there should be methods on some object (be it Image, ImageBitmap or Canvas) for:
- canDecodeType(): indicate if an image format can be encoded by Image/ImageBitmap objects
- canEncodeType(): indicate if an image format can be encoded by Canvas toDataURL/toBlob (or my proposed ImageBitmap.toBlob())


Justin Novosad | 23 Jun 21:34 2015

Subject=Re: Async Image -> ImageData conversion

Based on feedback received from web developers, new APIs that move image data around should also strive to eliminate intermediate copies of the image data to avoid memory bloat. I think your proposal achieves that, but I think memory footprint reduction could be a stated objective of the proposal. For example, the current solution of using a canvas forces the creation of an intermediate copy (the canvas). 

Also, to avoid the multiplication of APIs for moving image data between various representations, I would like to suggest an alternative: using the ImageBitmap interface as a hub. The creation of ImageBitmaps is already asynchronous (createImageBitmap returns a promise), and it has overloads for acquiring images from img, video, canvas, url, blob, imagedata. All that is missing are a few methods for getting data directly out of an ImageBitmap. So I think adding toBlob and toImageData (both async) to ImageBitmap is a more succinct proposal that would address your use cases, and many additional ones at the same time.
Arthur Barstow | 23 Jun 12:52 2015

PSA: publishing new WD of Service Workers on June 25

This is an announcement of the intent to publish a new Working Draft of 
Service Workers on June 25 using the following document as the basis:


If anyone has any major concerns with this proposal, please speak up 
immediately; otherwise the WD will be published as proposed.

For some implementation data for this spec, see 

-Thanks, ArtB