Re: Service Workers 1 and Nightly

On Fri, Sep 18, 2015 at 7:56 PM, Arthur Barstow wrote: > > Regarding the publishing plan above, the latest process document includes > an expectation that before a CR is published the spec "has already received > wide review" [1]. Although the group is free to determine

Re: Normative references to Workers.

On 9/16/15 4:47 AM, Mike West wrote: Note that this is an issue that's going to come up for a number of WebAppSec specs (see https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8 , for instance (and that

Re: Normative references to Workers.

On Tue, Sep 15, 2015 at 10:31 AM, Mike West wrote: > The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML > spec for the > "set up a worker environment settings object" algorithm[2], as the Web > Workers Candidate Recommendation from May 2012[3]

Normative references to Workers.

The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML spec for the "set up a worker environment settings object" algorithm[2], as the Web Workers Candidate Recommendation from May 2012[3] substantially predates the entire concept of a "settings object", and because the WHATWG

Re: Normative references to Workers.

On Tue, 15 Sep 2015, Mike West wrote: > > It seems appropriate, then, to bring the question to this group: does > WebApps intend to update the Workers draft in TR? FWIW, I think the W3C should get out of the business of republishing WHATWG specifications. It's just adding confusion, especially

Re: Normative references to Workers.

On Tue, Sep 15, 2015 at 11:25 AM, Tab Atkins Jr. wrote: > ​there's nothing wrong with reffing WHATWG specs. It will not delay > ​ or hamper​ > > publication or Rec-track advancement, despite the > ​ occasional misinformed​ > > complaint from someone not aware of the > ​ ​

Re: Normative references to Workers.

On 09/15/2015 03:26 PM, Daniel Veditz wrote: On Tue, Sep 15, 2015 at 11:25 AM, Tab Atkins Jr. > wrote: ​there's nothing wrong with reffing WHATWG specs. It will not delay ​ or hamper​ publication or Rec-track advancement, despite

Secure Contexts: It's worth taking another look.

BCC: www-tag@, public-webapps@, public-privacy@, public-geolocation@ in the hopes of spurring "wide" review. I've done a bit of polishing on https://w3c.github.io/webappsec/specs/powerfulfeatures/ over the last few days, and I think it's worth folks' time to take another look at the document. In

Shadow DOM Styling Meeting on September 18, 2015

Folks, Now that the Shadow DOM v1 implementations had started in a few browsers, we need a quick get-together to iron out implementation specifics around Shadow DOM styling and reconcile any remaining shifts (if any) in CSS Scoping spec due to Shadow DOM v1. To do this, we're going to meet on

Re: Shadow DOM spec for v1 is ready to be reviewed

On Mon, Sep 7, 2015 at 9:35 AM, Hayato Ito wrote: > I think the spec should address these issues and define the well-defined > behavior clearly. The current spec looks too lazy because it only mention > the following: > >> Window object named properties [HTML] must access the

[CSSWG][css-cascade-4] Last Call for Comments on CSS Cascading and Inheritance Level 4

The CSS WG has published an updated Working Draft of the CSS Cascading and Inheritance Module Level 4 http://www.w3.org/TR/css-cascade-4/ This CSS module describes how to collate style rules and assign values to all properties on all elements by way of cascading (choosing a winning

Re: Shadow DOM spec for v1 is ready to be reviewed

On Sun, Sep 6, 2015 at 12:53 AM Anne van Kesteren wrote: > On Fri, Aug 28, 2015 at 8:33 AM, Hayato Ito wrote: > > - Some of the remaining issues are difficult to address in the Shadow DOM > > spec because it requires non-trivial monkey patches to DOM. I

Reminder: [TPAC2015] Registration is now open for Oct 26-30 meeting week; deadline October 7

On 6/10/15 9:28 PM, Arthur Barstow wrote: Registration is now open for the October 26-30 Technical Plenary and all Working Group meeting week [TPAC], this year in Sapporo Japan: WebApps (the entire group) will meet on Monday and Tuesday

[Bug 24632] [meta][imports]: The spec should have fewer monkey patches

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24632 Bug 24632 depends on bug 24637, which changed state. Bug 24637 Summary: [imports] "style sheet that is blocking scripts" should be generalized to support HTML Imports https://www.w3.org/Bugs/Public/show_bug.cgi?id=24637 What

Re: Shadow DOM spec for v1 is ready to be reviewed

On Fri, Aug 28, 2015 at 8:33 AM, Hayato Ito wrote: > - Some of the remaining issues are difficult to address in the Shadow DOM > spec because it requires non-trivial monkey patches to DOM. I have a plan > to upstream the Shadow DOM spec into DOM in the near future. After that,

Re: Tests for new shadow DOM API

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ryosuke, On 09/03/2015 10:06 PM, Ryosuke Niwa wrote: > Hi all, > > Where should we put tests for new shadow DOM API? It looks like > the tests in > https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shado w-trees > >

Directory Upload

Hello WebApps WG and Incubator CG members, As you may know, we (Microsoft) have been collaborating with Mozilla on evolving the new directory upload proposal [1]. It has recently been added to the Incubator Community Group and we are looking forward to have everyone get involved with providing

Re: Tests for new shadow DOM API

I think many of them are still relevant. The key problem I have at the moment is that I can't tell which ones are relevant and which ones aren't. So I wanted to create a new directory and migrate or delete the existing tests over time. > On Sep 3, 2015, at 1:19 PM, Travis Leithead

RE: Tests for new shadow DOM API

Why not deprecate/remove the existing tests in the current folder structure? Presumably we can replace them with new tests that are aligned with the recent spec changes? If the existing tests really aren't relevant anymore, I don't see a reason to keep them around. From: rn...@apple.com

Re: [charter] Request for Comments; deadline Sept 10

Hi Josh, Thanks for the feedback! I filed to record your comments regarding the draft charter. A pull request - especially for the the editorial comments (such as typos, missing links, etc.) - would be welcome. Below I reply to a few of your

Re: Shadow DOM spec for v1 is ready to be reviewed

Thank you for the feedback! Let me take a look at the filed issues. I really appreciate it. It looks https://github.com/w3c/webcomponents/issues/308 is the only conceptual problem. I think I can send "Intent to Implement: Shadow DOM v1" in Blink soon. :) On Wed, Sep 2, 2015 at 5:43 AM Ryosuke

Re: Shadow DOM spec for v1 is ready to be reviewed

Thanks for the update! > On Aug 27, 2015, at 11:33 PM, Hayato Ito wrote: > > Let me post a quick update for the Shadow DOM spec: > https://w3c.github.io/webcomponents/spec/shadow/ >

Re: PSA: publish WD of "WebIDL Level 1"

> On 31 Aug 2015, at 20:12, Ms2ger wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Yves, > > On 08/31/2015 03:28 PM, Yves Lafon wrote: >> In fact, I would prefer to have the editors’ copy published as >> TR/WebIDL/, and let -1 -2 … -n be pointers to the

Re: PSA: publish WD of "WebIDL Level 1"

> On 01 Sep 2015, at 14:27, Ms2ger wrote: > > Hi Yves, > > On 09/01/2015 11:30 AM, Yves Lafon wrote: >> On 31 Aug 2015, at 20:12, Ms2ger wrote: >>> On 08/31/2015 03:28 PM, Yves Lafon wrote: In fact, I would prefer to have the editors’ copy published as

Re: PSA: publish WD of "WebIDL Level 1"

Hi Yves, On 09/01/2015 11:30 AM, Yves Lafon wrote: > On 31 Aug 2015, at 20:12, Ms2ger wrote: >> On 08/31/2015 03:28 PM, Yves Lafon wrote: >>> In fact, I would prefer to have the editors’ copy published as >>> TR/WebIDL/, and let -1 -2 … -n be pointers to the stable version >>>

Re: PSA: publish WD of "WebIDL Level 1"

> On Sep 1, 2015, at 7:27 AM, Anne van Kesteren wrote: > > On Tue, Sep 1, 2015 at 4:23 PM, Ryosuke Niwa wrote: >> I think you’re missing the point. The point of these documentation is to >> know exactly what the patch author was looking at the time he wrote

Re: PSA: publish WD of "WebIDL Level 1"

> On Aug 31, 2015, at 8:51 PM, Anne van Kesteren wrote: > > On Tue, Sep 1, 2015 at 2:33 AM, Ryosuke Niwa wrote: >> Let's say we implement some feature based on Web IDL published as of today. >> I'm going to refer that in my source code commit message.

Re: PSA: publish WD of "WebIDL Level 1"

On Tue, Sep 1, 2015 at 4:23 PM, Ryosuke Niwa wrote: > I think you’re missing the point. The point of these documentation is to > know exactly what the patch author was looking at the time he wrote the > patch. If there was a typo in the spec, that’s an important information.

Re: PSA: publish WD of "WebIDL Level 1"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yves, On 08/31/2015 03:28 PM, Yves Lafon wrote: > In fact, I would prefer to have the editors’ copy published as > TR/WebIDL/, and let -1 -2 … -n be pointers to the stable version > (aka, what is implemented, not what has to be implemented). >

[Bug 29103] New: MediaStream Recording API: MediaRecorderErrorEvent is a NoInterfaceObject, consider removing

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29103 Bug ID: 29103 Summary: MediaStream Recording API: MediaRecorderErrorEvent is a NoInterfaceObject, consider removing Product: WebAppsWG Version: unspecified Hardware: All

[Bug 29104] New: BlobEvent is defined in both MediaStream Recorder and MediaStream ImageCapture, consider factoring them out.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29104 Bug ID: 29104 Summary: BlobEvent is defined in both MediaStream Recorder and MediaStream ImageCapture, consider factoring them out. Product: WebAppsWG Version: unspecified

[Bug 29105] New: MediaStream Recording API: Consider not using BlobEvent, using Blob and FileReader instead

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29105 Bug ID: 29105 Summary: MediaStream Recording API: Consider not using BlobEvent, using Blob and FileReader instead Product: WebAppsWG Version: unspecified Hardware: All

[Bug 29102] MediaStream Recording API: remove RecordingErrorNameEnum and use DomException instead

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29102 Miguel Casas-Sanchez changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 29103] MediaStream Recording API: MediaRecorderErrorEvent is a NoInterfaceObject, consider removing

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29103 Miguel Casas-Sanchez changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 29104] BlobEvent is defined in both MediaStream Recorder and MediaStream ImageCapture, consider factoring them out.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29104 Miguel Casas-Sanchez changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 29105] MediaStream Recording API: Consider not using BlobEvent, using Blob and FileReader instead

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29105 Miguel Casas-Sanchez changed: What|Removed |Added Status|NEW |RESOLVED

Re: PSA: publish WD of "WebIDL Level 1"

> On Aug 7, 2015, at 9:27 AM, Anne van Kesteren wrote: > > On Fri, Aug 7, 2015 at 6:23 PM, Travis Leithead > wrote: >> This is, at a minimum, incremental goodness. It's better than leaving the >> prior L1 published document around--which

RE: PSA: publish WD of "WebIDL Level 1"

From: Ryosuke Niwa [mailto:rn...@apple.com] > For our internal documentation purposes, I'd refer having a perm link to a > document that never changes. > > Let's say we implement some feature based on Web IDL published as of > today. I'm going to refer that in my source code commit message.

Re: PSA: publish WD of "WebIDL Level 1"

On Tue, Sep 1, 2015 at 2:33 AM, Ryosuke Niwa wrote: > Let's say we implement some feature based on Web IDL published as of today. > I'm going to refer that in my source code commit message. Future readers of > my code has no idea what I was implementing when they look at my

Re: PSA: publish WD of "WebIDL Level 1"

> On 07 Aug 2015, at 14:45, Arthur Barstow wrote: > > On 8/4/15 2:21 PM, Tab Atkins Jr. wrote: >> On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow >> wrote: >>> Hi All, >>> >>> This is heads-up re the intent to publish a Working Draft of "WebIDL

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

Hello Hallvord, Hallvord Reiar Michaelsen Steen mailto:hst...@mozilla.com 27 août 2015 18:32 On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht p...@hoplahup.net mailto:p...@hoplahup.net wrote: do you not want to split the writable types list in safe and non-safe ones and let browsers

Re: [charter] Request for Comments; deadline Sept 10

Art wrote: The proposal to merge the WebApps WG and the HTML WG has started a formal review period that ends September 10: http://w3c.github.io/charter-html/group-charter.html IRC: active participants, particularly editors, regularly use the #webapps W3C IRC channel is this channel

Re: [clipboard] document.execCommand and clipboard actions

On Thu, Aug 6, 2015 at 11:00 AM, yves.ko...@ysadi.be wrote: Hi, Sorry if I might be out of scope, I am quite new in this mailing list. Welcome, and sorry that I'm late at responding. The clipboard is aimed to exchange any? data between any apps running on your computer. It is not a

Mozilla/Microsoft support for Native Messaging

https://wiki.mozilla.org/WebExtensions#Additional_APIs http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/ It would be a pity if Mozilla and Microsoft implements support for Chrome's Native Messaging without any discussions on W3C lists. Although

Minutes from WebApps + HTMLWG Editing Task Force face to face meeting

Hi folks, The minutes of the August 23-24 Editing Task Force f2f meeting are available as: * http://www.w3.org/2015/08/23-webapps-minutes.html http://www.w3.org/2015/08/23-webapps-minutes.html * http://www.w3.org/2015/08/24-webapps-minutes.html http://www.w3.org/2015/08/24-webapps-minutes.html

Re: [worker] Integration of WorkerGlobalScope and AbstractWorker

On Sun, Aug 23, 2015 at 12:23 PM, Bang Seongbeom bangseongb...@hotmail.com wrote: The current spec says that the internal worker scope is WorkerGlobalScope(or Dedi-, Shared-), the external is AbstractWorker(or Worker, Shared-.) But it destroys consistency with Window object and confuses users

[worker] Integration of WorkerGlobalScope and AbstractWorker

The current spec says that the internal worker scope is WorkerGlobalScope(or Dedi-, Shared-), the external is AbstractWorker(or Worker, Shared-.) But it destroys consistency with Window object and confuses users with the difference of WorkerGlobalScope and AbstractWorker. The global scope

WebApps-ACTION-758: Ask accesibility people about imes

WebApps-ACTION-758: Ask accesibility people about imes http://www.w3.org/2008/webapps/track/actions/758 Assigned to: Charles McCathie Nevile

what's the meaning of lighter blue thick underlined terms in some specs?

Hi, I notice in at least some specs produced by y'all, such as.. [1] http://www.w3.org/TR/workers/ [2] http://www.w3.org/TR/webmessaging/ ..there are some terms that are underlined with lighter blue thick lines, but which are not links, and are not explicitly defined within those specs.

Re: what's the meaning of lighter blue thick underlined terms in some specs?

Hi =JeffH, =JeffH jeff.hod...@kingsmountain.com, 2015-08-23 14:51 -0700: Archived-At: http://www.w3.org/mid/55da4071.2080...@kingsmountain.com Hi, I notice in at least some specs produced by y'all, such as.. [1] http://www.w3.org/TR/workers/ [2] http://www.w3.org/TR/webmessaging/

RE: Custom elements Constructor-Dmitry baseline proposal

From: Maciej Stachowiak [mailto:m...@apple.com] On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote: - Parser-created custom elements and upgraded custom elements will have their constructor and attributeChange callbacks called at a time when all their children and

Re: Custom elements Constructor-Dmitry baseline proposal

On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote: In

[Bug 29068] New: Should not reocmmend DocumentEvent.createEvent

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29068 Bug ID: 29068 Summary: Should not reocmmend DocumentEvent.createEvent Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW

Re: Custom elements Constructor-Dmitry baseline proposal

Thank you for writing this up. Would be interesting to hear what Maciej and Ryosuke think. On Tue, Aug 18, 2015 at 12:19 AM, Domenic Denicola d...@domenic.me wrote: - Use symbols instead of strings for custom element callbacks. So the way this is done is that they are publicly available on the

Re: Copying multi-range selection

On 15/08/2015 22:24, Phillips, Addison wrote: This appears to make visual selection appealing--although it doesn't, for the reasons mentioned elsewhere, lead to sensible text operations unless the selected run happens to be all in a single direction. and if the text runs all in a single

RE: Copying multi-range selection

This appears to make visual selection appealing--although it doesn't, for the reasons mentioned elsewhere, lead to sensible text operations unless the selected run happens to be all in a single direction. and if the text runs all in a single direction, there's no difference between

Re: Moving W3C Streams to Note and adding disclaimer [was: [charter] What is the plan for Streams API?]

After looking back at how we’ve handled cases like this one in the past, and after noting that we appear to already have some agreement that at least a disclaimer of some kind would be appropriate here—and that it would be uncontroversial to add one—I’ve gone ahead and done so. That seems

Moving W3C Streams to Note and adding disclaimer [was: [charter] What is the plan for Streams API?]

Arthur Barstow art.bars...@gmail.com, 2015-08-10 08:07 -0400: Archived-At: http://www.w3.org/mid/55c893e4.8050...@gmail.com On 8/7/15 8:32 AM, Anne van Kesteren wrote: On Fri, Aug 7, 2015 at 1:56 PM, Arthur Barstow art.bars...@gmail.com wrote: Given this status, and in the absence of other

Custom elements Constructor-Dmitry baseline proposal

In https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Constructor-Dmitry.md I’ve written up in some detail what I consider to be the current state-of-the-art in custom elements proposals. That is, if we take the current spec, and modify it in ways that everyone agrees are good ideas,

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

Hallvord, do you not want to split the writable types list in safe and non-safe ones and let browsers how they deal with unsafe ones? Here's an idea: html, xml, and picture formats should be in the unsafe ones. I guess json too (but both XML and JSON are too generic to my taste). Similarly, I'd

[url] do not find.

mamagyim@gh mail.com

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

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg

RE: Copying multi-range selection

what's the use case driving this, and where are the requirements coming from? i ask because i'm inclined to think that the circumstances in which this would a produce useful results, given the way it carves up the actual content, are quite, perhaps extremely, limited. Well, the web

Re: Copying multi-range selection

On Sat, Aug 15, 2015 at 9:04 PM, Richard Ishida ish...@w3.org wrote: my question was specifically, why do it in a non-standard way for bidi text? (typical scenario is split visual but one range internally) Which is not great for users, right? Also, as Addison points out, it's unclear how that

Re: Copying multi-range selection

We worked on this some years ago, and found that the cut/copy/paste were very, very complicated to get to be natural, and ended up dropping it. The problem is that if ...ABC... are adjacent ranges on the screen in the source (each letter is a range), people expect to see ...ABC... when it is

Re: Copying multi-range selection

On 15/08/2015 06:19, Anne van Kesteren wrote: On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa rn...@apple.com wrote: We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually

Re: Copying multi-range selection

Hi Anne, Not sure if this would answer your question, but in general, when it comes to BiDi you need to differentiate between the physical order (what is in memory, e.g, ABC) and the logical order (what the user expects to see (e.g., CBA). At the same time to handle copy/paste, you will be

Re: Copying multi-range selection

On Sat, Aug 15, 2015 at 8:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Aug 15, 2015 at 10:23 AM, Richard Ishida ish...@w3.org wrote: what's the use case driving this, and where are the requirements coming from? i ask because i'm inclined to think that the circumstances in

Re: Copying multi-range selection

On Sat, Aug 15, 2015 at 10:23 AM, Richard Ishida ish...@w3.org wrote: what's the use case driving this, and where are the requirements coming from? i ask because i'm inclined to think that the circumstances in which this would a produce useful results, given the way it carves up the actual

RE: Copying multi-range selection

Hello, Anne! *** WARNING: longish comment, best left to readers really interested in bidi stuff *** This problem is well known in bidi circles, and as far as I know, has not been solved satisfactorily, and maybe even has no good solution. The heart of the problem is that a visually

Copying multi-range selection

Hi all, We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious in DOM order, doing so involves creating a disjoint multi-range

Re: Copying multi-range selection

On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa rn...@apple.com wrote: We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious

Re: Custom Element Action Items?

On Mon, Aug 10, 2015 at 3:17 PM, Wilson Page wilsonp...@me.com wrote: I was unable to attend the latest F2F so would like clarification on what the takeaway action items were and who is responsible for pushing them forward. I don't believe this information was included in the minutes. I think

Re: Is polyfilling future web APIs a good idea?

Awesome. Now I think I understand the full picture you described. When trying to offer a feature that is still being specced, prefix the specced APIs, and once the spec is stable, for browsers that don't ship these APIs, alias the prefixed ones by dropping the prefix. Is that correct? On Aug

Re: Custom Element Action Items?

As for Custom Elements, I think the following is one of the Action Items: https://github.com/w3c/webcomponents/issues/287 Could someone add a missing action item to GitHub Issues if it exists? As for the Shadow DOM spec, I'm updating the spec so that it adapts the Slots and other changes which

[Bug 25097] Update HTTP and HTTPAUTH references to new HTTPbis specs

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25097 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 25097] Update HTTP and HTTPAUTH references to new HTTPbis specs

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25097 Julian Reschke julian.resc...@gmx.de changed: What|Removed |Added Status|RESOLVED|REOPENED

[Bug 29049] Queue a microtask to unset active on transaction

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29049 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 16137] IndexedDB: Add API for enumerating databases

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16137 Joshua Bell jsb...@google.com changed: What|Removed |Added Resolution|LATER |MOVED --- Comment #4

[Bug 22370] Inform script of corruption-induced data loss

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22370 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED

[Bug 25223] IDB exposes GC behavior

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25223 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED

[Bug 22130] Modification for IDBObjectStore's clear and delete method

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22130 Joshua Bell jsb...@google.com changed: What|Removed |Added Resolution|LATER |MOVED --- Comment #4

[Bug 11528] We should add some form of dynamic transaction to IndexedDB

https://www.w3.org/Bugs/Public/show_bug.cgi?id=11528 Joshua Bell jsb...@google.com changed: What|Removed |Added CC||jsb...@google.com

[Bug 21836] Remove NotSupportedError on creating index for multiEntry index with array keyPath

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21836 Joshua Bell jsb...@google.com changed: What|Removed |Added Resolution|LATER |MOVED --- Comment #6

[Bug 10000] Allow expressions in addition to keyPaths when creating indexes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=1 Joshua Bell jsb...@google.com changed: What|Removed |Added Resolution|LATER |MOVED --- Comment #5

[Bug 28067] DOMStringList has been removed from DOM

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28067 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 28456] nested keyPath: allow specification which part should be iterated if it's an array

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28456 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: W3C's version of XMLHttpRequest should be abandoned

Hey all, Like Jungkee, I haven't been active editing the XHR spec. I too feel like XHR L1 is very far from trivial. That is because the snapshot Domenic is talking about is not what XHR L1 is supposed to be. XHR L1 is supposed to be a state of what is actually implemented in released browsers at

[Bug 29049] New: Queue a microtask to unset active on transaction

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29049 Bug ID: 29049 Summary: Queue a microtask to unset active on transaction Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW

Custom Element Action Items?

Hi All, I was unable to attend the latest F2F so would like clarification on what the takeaway action items were and who is responsible for pushing them forward. I don't believe this information was included in the minutes. I heard there was agreement around Shadow DOM. Who is tasked with

Re: Is polyfilling future web APIs a good idea?

On Aug 6, 2015 11:05 PM, Glen Huang curvedm...@gmail.com wrote: This assumes you'll match That's a good point. I agree for most APIs it's probably better to simply use polyfill code for all browsers. But some APIs have some extra benefits that might not be polyfillable. For example, the

Re: [charter] What is the plan for Streams API?

On Mon, Aug 10, 2015 at 2:07 PM, Arthur Barstow art.bars...@gmail.com wrote: Given Takeshi's status it seems premature to speculate. The current [TR] is now mostly void of content although it might be good to gut it even more as well as to add a clear note that indicates that work has stopped

Re: [charter] What is the plan for Streams API?

On 8/7/15 8:32 AM, Anne van Kesteren wrote: On Fri, Aug 7, 2015 at 1:56 PM, Arthur Barstow art.bars...@gmail.com wrote: Given this status, and in the absence of other feedback, I think the Streams API should remain in WebApps' charter (at least for now). Then later, the work may proceed (if

[charter] Need clarification about Fetching resources

All - WebApps' draft charter (formally being reviewed by consortium Members through Sept 10 [1]) includes the following text about Fetching resources: [[ http://www.w3.org/2015/07/web-platform-wg.html#network Fetching resources The Group MAY also define the mechanisms to fetch resources

RE: W3C's version of XMLHttpRequest should be abandoned

Hi Art, Hallvord, Julian, and all, Apologies having not been active on it. My feeling is capturing a snapshot for REC would still be a non-trivial task. Unfortunately, I don't seem to be able to spare much time on this work as of now. Sorry for not being able to help. It's my own stance, not

Re: W3C's version of XMLHttpRequest should be abandoned

On 8/6/15 8:07 AM, Hallvord Reiar Michaelsen Steen wrote: On Thu, Aug 6, 2015 at 9:15 AM, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: According to Art the plan of record is to still pursue https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html And you

Re: PSA: publish WD of WebIDL Level 1

On Fri, Aug 7, 2015 at 6:23 PM, Travis Leithead travis.leith...@microsoft.com wrote: This is, at a minimum, incremental goodness. It's better than leaving the prior L1 published document around--which already tripped up a few folks on my team recently. I strongly +1 it. If your team looks at

Re: PSA: publish WD of WebIDL Level 1

This is, at a minimum, incremental goodness. It's better than leaving the prior L1 published document around--which already tripped up a few folks on my team recently. I strongly +1 it. From: Anne van Kesteren ann...@annevk.nl Sent: Friday, August 7,

Re: [clipboard] document.execCommand and clipboard actions

On Thu, Aug 6, 2015 at 1:36 PM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: ... I haven't been following discussions in that group, so I don't know how many developers they consulted. I'm sure we all understand the frustration with the contentEditable implementations out there -

Re: PSA: publish WD of WebIDL Level 1

On Fri, Aug 7, 2015 at 9:23 AM, Travis Leithead travis.leith...@microsoft.com wrote: This is, at a minimum, incremental goodness. It's better than leaving the prior L1 published document around--which already tripped up a few folks on my team recently. I strongly +1 it. There are

<    3   4   5   6   7   8   9   10   11   12   >