Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

+1 to FPWD of FindText API > On Oct 7, 2015, at 11:38 AM, Robert Sanderson wrote: > > +1 to FPWD > > On Wed, Oct 7, 2015 at 8:34 AM, Ivan Herman wrote: > I am happy to have this documents published as FPWD. > > Ivan > > > > On 06 Oct 2015, at 22:32 ,

RE: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

Hi Jake, Thanks for the offer. The DPUB IG meets on Mondays at 11:00 EDT/15:00 UTC. We would be very happy to have you at our 19 October meeting [1] to discuss Service Workers in the context of the Portable Web Publications for the Open Web Platform [2]. Markus and I will copy you when we

Re: Reminder regarding normative references

On Wed, Oct 7, 2015 at 9:30 AM, Steve Faulkner wrote: > hi mike, i think you will find your example is in the W3C HTML 5.1: > > http://www.w3.org/TR/html51/webappapis.html#creation-url > > not saying there aren't other examples that would be concrete. > I am pleasantly

Re: Reminder regarding normative references

On 7 October 2015 at 08:15, Mike West wrote: > As a concrete example, I'm going to send a transition request for Secure > Contexts shortly. It uses the "creation URL" concept which was recently > added to WHATWG's HTML ( >

Re: Reminder regarding normative references

On Wed, Oct 7, 2015 at 12:44 AM, Wendy Seltzer wrote: > A reminder that has come up in some recent transition calls: When moving > a spec to Candidate Recommendation, we look to see that the normative > references are to documents of equivalent stability[1] -- ideally, also >

[Bug 14828] Import Hixie's tests?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14828 Arthur Barstow changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 15279] Update WebSockets tests to remove support for MozWebSocket

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15279 Ms2ger changed: What|Removed |Added Status|NEW |RESOLVED

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

I am happy to have this documents published as FPWD. Ivan > On 06 Oct 2015, at 22:32 , Frederick Hirsch wrote: > > This is a call for consensus (CfC) to publish a First Public Working Draft > (FPWD) of FindText API; deadline 14 October (1 week) > > This FindText API is

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

+1 to FPWD On Wed, Oct 7, 2015 at 8:34 AM, Ivan Herman wrote: > I am happy to have this documents published as FPWD. > > Ivan > > > > On 06 Oct 2015, at 22:32 , Frederick Hirsch wrote: > > > > This is a call for consensus (CfC) to publish a First Public Working

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

This is a call for consensus (CfC) to publish a First Public Working Draft (FPWD) of FindText API; deadline 14 October (1 week) This FindText API is joint deliverable of the WebApps WG and Web Annotation WG (listed as "Robust Anchoring" in the charters [1], [2]). +1 for publishing this

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

Hi, Raphaël– Yes, this is one narrowly-scoped piece of generalized functionality that we hope can get broad agreement and implementation. It's just one of the building blocks of a full set of robust anchoring features, some of which might be standardized, but which may actually be done in

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

Hi Doug, It's just one of the building blocks of a full set of robust anchoring features, some of which might be standardized, but which may actually be done in script. We'll most likely gather together those pieces in the sort of umbrella document you suggest… maybe something like "Mapping Web

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

Hi, Yosi– On 10/6/15 9:30 PM, Yoshifumi Inoue wrote: It's exciting! Thanks! For Shadow DOM, current Blink implementation traverses composed tree rather than DOM tree. We introduced a concept position in composed tree and ephemeral range in composed tree; "ephemeral" means range in composed

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

How does this work with shadow dom? Range is not very friendly to that. On Oct 6, 2015 4:35 PM, "Frederick Hirsch" wrote: > This is a call for consensus (CfC) to publish a First Public Working Draft > (FPWD) of FindText API; deadline 14 October (1 week) > > This FindText API

Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

This is a call for consensus (CfC) to publish a First Public Working Draft (FPWD) of FindText API; deadline 14 October (1 week) This FindText API is joint deliverable of the WebApps WG and Web Annotation WG (listed as "Robust Anchoring" in the charters [1], [2]). This is a Call for Consensus

[Bug 19771] Need way to determine what keys are supported on device.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19771 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 26813] Removing parent of element that's full screen

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26813 Anne changed: What|Removed |Added Status|NEW |RESOLVED CC|

ISSUE-187: Https://github.com/w3c/uievents/issues/20

ISSUE-187: Https://github.com/w3c/uievents/issues/20 http://www.w3.org/2008/webapps/track/issues/187 Raised by: On product:

RE: ISSUE-187: Https://github.com/w3c/uievents/issues/20

I closed this--it was opened by accident. -Original Message- From: Web Applications Working Group Issue Tracker [mailto:sysbot+trac...@w3.org] Sent: Tuesday, October 6, 2015 5:26 PM To: public-webapps@w3.org Subject: ISSUE-187: Https://github.com/w3c/uievents/issues/20 ISSUE-187:

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

It's exciting! For Shadow DOM, current Blink implementation traverses composed tree rather than DOM tree. We introduced a concept position in composed tree and ephemeral range in composed tree; "ephemeral" means range in composed tree isn't live. Ephemeral range objects aren't update at DOM

[Bug 21083] Proposal key names for Android

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

Hi, Eliott– Good question. I don't have a great answer yet, but this is something that will need to be worked out with Shadow DOM, not just for this spec, but for Selection API and others, as well as to CSS, which has some Range-like styling. I don't know if this means a change to Shadow

[Bug 21121] Define mobile phone related keys

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 21083] Proposal key names for Android

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083 Bug 21083 depends on bug 21121, which changed state. Bug 21121 Summary: Define mobile phone related keys https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121 What|Removed |Added

[Bug 21083] Proposal key names for Android

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083 Bug 21083 depends on bug 21137, which changed state. Bug 21137 Summary: Define key names for game controller of Android https://www.w3.org/Bugs/Public/show_bug.cgi?id=21137 What|Removed |Added

[Bug 22569] MouseEvent should have DOMString pseudoElement property like TransitionEvent

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22569 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 22891] Mechanism to differentiate pointer input from multiple users/devices missing

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22891 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 23259] Expose ticks in wheel events

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23259 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 25485] D3E and corelation with DOM4(W3C)/DOM(WHATWAG) and DOM3 Core

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 21120] Define TV or A/V remote controller's keys

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21120 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 21083] Proposal key names for Android

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083 Bug 21083 depends on bug 21120, which changed state. Bug 21120 Summary: Define TV or A/V remote controller's keys https://www.w3.org/Bugs/Public/show_bug.cgi?id=21120 What|Removed |Added

[Bug 21136] Define Home key and Back key of Android smartphone

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21136 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 21083] Proposal key names for Android

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083 Bug 21083 depends on bug 21136, which changed state. Bug 21136 Summary: Define Home key and Back key of Android smartphone https://www.w3.org/Bugs/Public/show_bug.cgi?id=21136 What|Removed |Added

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers wrote: > Hi, Eliott– > > Good question. > > I don't have a great answer yet, but this is something that will need to be > worked out with Shadow DOM, not just for this spec, but for Selection API > and others, as well as to CSS, which

[Bug 21137] Define key names for game controller of Android

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21137 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 21830] KeyboardEvent.locale is too general.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21830 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

Hi, Tab– Thanks for the correction. I assumed that Houdini would expose more of the underpinnings of the ::selection pseudo-element [1] and its ilk. Maybe that hasn't surfaced (and maybe it won't). It does seem to be more magic, though, which I'd thought we were trying to demystify. But if

[Bug 23907] How do web apps distinguish if a keydown event causes text input?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23907 Gary Kacmarcik changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 23575] The paragraph about patent policy is duplicated.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23575 Arthur Barstow changed: What|Removed |Added Status|NEW |RESOLVED

Re: Indexed DB + Promises

On Mon, 5 Oct 2015 at 23:31 Joshua Bell wrote: > Yeah - "When control is returned to the event loop" isn't precise enough. > It's an open issue in the 2nd Ed. and I welcome suggestions for tightening > it up. Note that Jake Archibald, at least, was happy with the Blink >

[Bug 27108] Push API should be allowed without dependency on service worker

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27108 Arthur Barstow changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 14214] missing definition of Transferable

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14214 Arthur Barstow changed: What|Removed |Added Status|NEW |RESOLVED

Re: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

Jake, just to note that Tzviya, who organizes the meetings around TPAC, is on vacations until Wednesday morning. We will synchronize then; I hope it is all right. And thanks in advance for your help! Ivan --- Ivan Herman Tel:+31 641044153 http://www.ivan-herman.net (Written on mobile, sorry

Re: Indexed DB + Promises

Thanks for all the feedback so far. I've captured concrete suggestions in the issue tracker - https://github.com/inexorabletash/indexeddb-promises/issues On Wed, Sep 30, 2015 at 11:10 AM, Tab Atkins Jr. wrote: > On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey

RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

Hi All, The Digital Publishing Interest Group [1] is seeking feedback regarding the use of Service Workers in their early draft (WIP) of "Portable Web Publications for the Open Web Platform", in particular section 5.1 "General Architecture for Online/Offline Publications":

[Bug 28823] Course of action even after Event Source retry failure.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28823 Anne changed: What|Removed |Added Status|NEW |RESOLVED

Re: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

On Mon, 5 Oct 2015 at 13:00 Arthur Barstow wrote: > The IG welcomes discussion and feedback during their October 19 > conference call (if interested, please contact Tzviya) and/or during > TPAC. I'm happy to take part in this from a service worker point of view, if

Re: [web-animations] Should computedTiming return a live object?

On Sat, Oct 3, 2015 at 1:14 AM, Anne van Kesteren wrote: > On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles wrote: >> I'd like to change this API, probably to one of the following (listed >> roughly in order of preference). I wonder if anyone else has an

Re: [web-animations] Should computedTiming return a live object?

On Sat, Oct 3, 2015 at 1:21 AM, Domenic Denicola wrote: > Anne's questions are interesting and worth answering. For example, which of > these properties are typically held in memory already, versus which would > require some kind of computation---the former usually are better

Re: Tests for new shadow DOM API

Hi, Thanks Ryosuke for starting contributing tests to shadow-dom/ and moving the old ones under untriaged/. I would like to continue triaging old tests in untriaged/ directory. The general rule of thumb (for me) for working on them are: - Remove tests that test out-of-date features (e.g.

Re: [web-animations] Should computedTiming return a live object?

On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles wrote: > I'd like to change this API, probably to one of the following (listed > roughly in order of preference). I wonder if anyone else has an opinion > on this? I'm curious as to what this maps to closer to the metal. That

RE: [web-animations] Should computedTiming return a live object?

Anne's questions are interesting and worth answering. For example, which of these properties are typically held in memory already, versus which would require some kind of computation---the former usually are better as properties, and the latter as methods. But setting aside the deeper issues

[Bug 27915] Clients of WebSockets are not NTP synced (and there is no NTP-alike spec)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27915 Domenic Denicola changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 28841] Incorporate changes suggested by Mixed Content

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28841 Domenic Denicola changed: What|Removed |Added Status|NEW |RESOLVED

Re: Indexed DB + Promises

On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola wrote: > I guess part of the question is, does this add enough value, or will authors > still prefer wrapper libraries, which can afford to throw away backward > compatibility in order to avoid these ergonomic problems? From

Re: Indexed DB + Promises

I agree with Jonas, I'd like to see IDBRequest and IDBTransaction be thenables. This could be done by having a hidden promise, and having .then/.catch proxy to the same methods on the hidden promise. We just have to get over the throw/reject thing. On Tue, 29 Sep 2015, 23:16 Jonas Sicking

Re: Indexed DB + Promises

Very good initiative. Joshua, I am trying to understand how your proposal relates to microtasks. Does the extension of lifetime mean that a transaction is alive 1/ until the end of the event (including pending microtasks) or 2/ that it can be kept alive across several events? Intuitively, I

Re: Indexed DB + Promises

On 30/09/15 08:12, Jake Archibald wrote: > I agree with Jonas, I'd like to see IDBRequest and IDBTransaction be > thenables. This could be done by having a hidden promise, and having > .then/.catch proxy to the same methods on the hidden promise. > > We just have to get over the throw/reject

Re: Indexed DB + Promises

One of the things I like about the WebSQL API is that the transaction aborts if any queries fail or if any callbacks throw errors. This way the whole transaction can be handled as a promise easily, which provides nice abstraction to the calling code. It comes at the expense of each individual

Re: Indexed DB + Promises

IDB already aborts the transaction if errors are thrown in callbacks. Additionally, in the promise proposal, if the promise passed to .waitUntil rejects, the transaction aborts. Does this address your concerns? On Wed, 30 Sep 2015, 08:26 Conrad Irwin wrote: > One of the

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

> On Sep 29, 2015, at 8:19 AM, Alan Stearns wrote: > > On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of Ryosuke Niwa" > wrote: > > Chaals, Art, > > Do you have a time preference for this? We’ve got one vote for Tuesday > afternoon, but I think Monday

[web-animations] Should computedTiming return a live object?

(CC-ing public-webapps and www-style since I think this API needs more eyes on it) Hi, Web Animations currently has the following API[1]: interface AnimationEffectReadOnly { readonly attribute AnimationEffectTimingReadOnly timing; readonly attribute ComputedTimingProperties

Re: Indexed DB + Promises

On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. wrote: > On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola wrote: >> I guess part of the question is, does this add enough value, or will authors >> still prefer wrapper libraries, which can afford to throw

Re: Indexed DB + Promises

On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey wrote: > On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. wrote: >> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola wrote: >>> I guess part of the question is, does this add enough value, or

Re: Indexed DB + Promises

On Wed, Sep 30, 2015 at 3:13 AM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > Joshua, I am trying to understand how your proposal relates to > microtasks. Does the extension of lifetime mean that a transaction is > alive 1/ until the end of the event (including pending microtasks) or

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

Late Tuesday afternoon would be a good fit for me. On Tue, Sep 29, 2015 at 8:49 AM, Ryosuke Niwa wrote: > Hi, > > Attending the recent meeting for shadow DOM styling [1] convinced me to > join CSS WG, and further that we need a joint meeting between CSS WG and > WebApps WG on

Re: [XHR] Error type when setting request headers.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yves, On 09/29/2015 03:25 PM, Yves Lafon wrote: > Hi, In XHR [1], setRequestHeader is defined by this: [[ void > setRequestHeader(ByteString name, ByteString value); ]] It has a > note: [[ Throws a SyntaxError exception if name is not a header >

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of Ryosuke Niwa" wrote: >Hi, > >Attending the recent meeting for shadow DOM styling [1] convinced me to join >CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG >on this topic during TPAC to iron out

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

On 9/29/15 11:19 AM, Alan Stearns wrote: On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of Ryosuke Niwa" wrote: Hi, Attending the recent meeting for shadow DOM styling [1] convinced me to join CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

I added a note (as a question) to the meeting wiki page: https://www.w3.org/wiki/Webapps/October2015Meeting cheers On Tue, 29 Sep 2015 11:12:16 +0500, John Daggett wrote: Late Tuesday afternoon would be a good fit for me. On Tue, Sep 29, 2015 at 8:49 AM, Ryosuke

Re: Indexed DB + Promises

On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola wrote: > This seems ... reasonable, and quite possibly the best we can do. It has a > several notable rough edges: > > - The need to remember to use .promise, instead of just having functions > whose return values you can await

RE: Indexed DB + Promises

This seems ... reasonable, and quite possibly the best we can do. It has a several notable rough edges: - The need to remember to use .promise, instead of just having functions whose return values you can await directly - The two-stage error paths (exceptions + rejections), necessitating

Re: Indexed DB + Promises

Yes, sorry. <> That's for implementors such as yourself to work through, I had assumed. I just went over the Readme from the perspective of an IDB user. Here is some potentially very naive feedback but i it s so obvious I can't help but state it: Instead of having .promise to appended to the

Re: Indexed DB + Promises

On Mon, Sep 28, 2015 at 11:42 AM, Marc Fawzi wrote: > Have you looked at ES7 async/await? I find that pattern makes both simple > as well as very complex (even dynamic) async coordination much easier to > deal with than Promise API. I mean from a developer perspective. > >

Re: Indexed DB + Promises

<< Instead of having .promise to appended to the IDB methods as in `store.openCursor(query).promise` why couldn't you configure the IDB API to be in Promise returning mode and in that case openCursor(query) would return a Promise. >> I meant user configurable, maybe as a global config. On Mon,

Re: Indexed DB + Promises

Have you looked at ES7 async/await? I find that pattern makes both simple as well as very complex (even dynamic) async coordination much easier to deal with than Promise API. I mean from a developer perspective. Sent from my iPhone > On Sep 28, 2015, at 10:43 AM, Joshua Bell

Indexed DB + Promises

One of the top requests[1] we've received for future iterations of Indexed DB is integration with ES Promises. While this initially seems straightforward ("aren't requests just promises?") the devil is in the details - events vs. microtasks, exceptions vs. rejections, automatic commits, etc.

Re: Indexed DB + Promises

On 28/09/15 22:14, Marc Fawzi wrote: > << > Instead of having .promise to appended to the IDB methods as > in `store.openCursor(query).promise` why couldn't you configure the IDB > API to be in Promise returning mode and in that case openCursor(query) > would return a Promise. >>> > > I meant

Re: Indexed DB + Promises

How about using ES7 decorators, like so: @idb_promise function () { //some code that uses the IDB API in Promise based way } and it would add .promise to the IDB APIs On Mon, Sep 28, 2015 at 1:26 PM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > On 28/09/15 22:14, Marc Fawzi

RE: Indexed DB + Promises

I’ve been maintaining an IDB wrapper using Promises for a few years now[1]. Some things I’ve learnt are: · Sharing transactions are a pain, but can be beneficial · Cursors would lead to a nicer implementation on generators · Async looks like a nicer abstraction on top

Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

Hi, Attending the recent meeting for shadow DOM styling [1] convinced me to join CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG on this topic during TPAC to iron out the details. Can we have a joint meeting (of one or two hours) on Monday (10/26) or Tuesday

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25097 Anne changed: What|Removed |Added Status|REOPENED|RESOLVED

[XHR]

CfC: Transition "Secure Contexts" to CR; deadline October 1st.

BCC: www-tag@, public-webapps@, public-privacy@, public-geolocation@, public-review-announce@. Hello, WebAppSec! Two weeks ago, I noted that Secure Contexts was pretty much done, and ready to review ( https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0068.html). I've made some changes

RE: RfC: Service Workers

Hello Art, Could you better define what "soon" means? More specifically, do you have a deadline for comments? I don't see any dates in the thread below. Thanks, Addison Phillips Principal SDE, I18N Architect (Amazon) Chair (W3C I18N WG) Internationalization is not a feature. It is an

Re: Directory Upload

Thanks for the status update, Ali! And kudos for the transparency around your plans for the prefixed APIs. Re: the new directory upload proposal [1] It looks like there's some recent discussion [2] by Moz folks about moving forward with implementation. On the Chrome side, we're definitely eager

[webapps] spec title editorial nit [I18N-ISSUE-433]

Dear webapps, This note is to forward a minor comment from the I18N WG about your document "Manifest for web applications" [1] that we missed forwarding previously. Our comment is editorial in nature: -- The title of the specification is "Manifest for web application". Should this be

Re: RfC: Service Workers

On 9/23/15 1:46 PM, Phillips, Addison wrote: Could you better define what "soon" means? More specifically, do you have a deadline for comments? I don't see any dates in the thread below. I think four weeks is the `normal` expectation for `wide reviews`. However, the Editors and some active

Re: RfC: Service Workers

Please use the Version 1 branch for this review: On 9/21/15 7:27 AM, Arthur Barstow wrote: [ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG (public-web-mobile), W3C Chairs (chairs), Review Announce list

Re: Normative references to Workers.

On 9/21/15 5:54 AM, Ms2ger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2015 11:05 AM, Xiaoqian Wu wrote: If it helps, I’d like to prepare a Workers draft to revise the previous CR, and schedule the publication ASAP (hopefully 22 Sep). The goal is to synchronise with the

Re: Normative references to Workers.

On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow wrote: > On 9/21/15 5:54 AM, Ms2ger wrote: >> Why? > > I think the rationale was mentioned in > . Ms2ger made a valid point. Workers is actively being

RfC: Service Workers

[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG (public-web-mobile), W3C Chairs (chairs), Review Announce list (public-review-announce), Geolocation WG (public-geolocation) ] The Editors and active contributors of Service Workers intend to publish a Candidate Recommendation

Re: Normative references to Workers.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2015 11:05 AM, Xiaoqian Wu wrote: > If it helps, I’d like to prepare a Workers draft to revise the > previous CR, and schedule the publication ASAP (hopefully 22 Sep). > The goal is to synchronise with the upstream, to document the >

Re: Are web components *seriously* not namespaced?

I created a prototype of this idea on github: https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/README.md by forking the original webcomponents.js project. It contains a working example of this concept. Below the content of the README.md file: This fork of webcomponents.js enhances

Re: Normative references to Workers.

> On 22 Sep, 2015, at 1:35 am, Anne van Kesteren wrote: > > On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow wrote: >> On 9/21/15 5:54 AM, Ms2ger wrote: >>> Why? >> >> I think the rationale was mentioned in >>

RE: Normative references to Workers.

From: Xiaoqian Wu [mailto:xiaoq...@w3.org] > If the spec is still changing frequently, indeed it isn't a good idea to > publish another CR… but the WebApps WG needs to clearly tell the community > that the 2012 CR should be considered obsolete. > > I’d suggest that we publish a WD for

Re: Normative references to Workers.

> On 16 Sep, 2015, at 8:17 pm, Arthur Barstow wrote: > > 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 >>

Service Workers 1 and Nightly

Hi all, We editors are happy to announce that we make a new branch for Service Workers 1 today [1]. Thanks to all the contributions, Service Workers 1 now covers the fundamental model and the associated APIs to support offline-first and background processing requirements. The features in this

[Bug 29136] New: Keyboard events should specify their target when more than 1 document exists

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29136 Bug ID: 29136 Summary: Keyboard events should specify their target when more than 1 document exists Product: WebAppsWG Version: unspecified Hardware: PC

Re: Service Workers 1 and Nightly

On 9/18/15 2:22 AM, Jungkee Song wrote: Hi all, We editors are happy to announce that we make a new branch for Service Workers 1 today [1]. Thanks to all the contributions, Service Workers 1 now covers the fundamental model and the associated APIs to support offline-first and background

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