Re: [UIEvents] Firing composition events for dead keys

On 01/10/2016 01:14 AM, Ryosuke Niwa wrote: Hi all, This is another feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to discuss editing API and related events. We found out that all major browsers (Chrome, Firefox, and Safari) fire

Re: [UIEvents] Firing composition events for dead keys

> On Jan 9, 2016, at 6:33 PM, Olli Pettay wrote: > > On 01/10/2016 01:14 AM, Ryosuke Niwa wrote: >> Hi all, >> >> This is another feedback from multiple browser vendors (Apple, Google, >> Microsoft) that got together in Redmond last Thursday to discuss editing API >> and

Re: time at TPAC other than Wednesday?

On Sat, 09 Jan 2016 23:20:27 +0300, Ryosuke Niwa wrote: On Jan 8, 2016, at 7:12 PM, Johannes Wilm wrote: On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin wrote: Hello Johannes, I was the one to organize the meeting. To

Re: [Editing] [DOM] Adding static range API

> On Jan 9, 2016, at 6:25 PM, Olli Pettay wrote: > > Hard to judge this proposal before seeing an API using StaticRange objects. > > One thing though, if apps were to create an undo stack of their own, they > could easily have their own Range-like API implemented in JS. So if

[selection-api] onselectstart/onselectionchange attributes

Hi, It looks like browsers don't agree on where `onselectstart` and `onselectionchange` IDL attributes should be defined: https://github.com/w3c/selection-api/issues/54 https://github.com/w3c/selection-api/issues/60 In particular, Blink/WebKit/Trident all defines onselectstart/onselectionchange

Re: [UIEvents] Firing composition events for dead keys

On 01/10/2016 05:05 AM, Ryosuke Niwa wrote: On Jan 9, 2016, at 6:33 PM, Olli Pettay wrote: On 01/10/2016 01:14 AM, Ryosuke Niwa wrote: Hi all, This is another feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to

Re: time at TPAC other than Wednesday?

> On Jan 9, 2016, at 4:11 PM, Chaals McCathie Nevile > wrote: > > On Sat, 09 Jan 2016 23:20:27 +0300, Ryosuke Niwa wrote: > >> >>> On Jan 8, 2016, at 7:12 PM, Johannes Wilm wrote: >>> >>> On Sat, Jan 9, 2016 at 3:49 AM,

Re: time at TPAC other than Wednesday?

On Sat, Jan 9, 2016 at 2:32 AM, Gary Kačmarčík (Кошмарчик) < gary...@google.com> wrote: > +public-webapps since these these notes are relevant for both groups > > On Fri, Jan 8, 2016 at 5:03 PM, Johannes Wilm > wrote: > >> Just so we don't have too many different ideas

Re: time at TPAC other than Wednesday?

+public-webapps since these these notes are relevant for both groups On Fri, Jan 8, 2016 at 5:03 PM, Johannes Wilm wrote: > Just so we don't have too many different ideas about what is going on. > > This is the last I remember having heard from the taskforce. We were >

Re: time at TPAC other than Wednesday?

On Sat, Jan 9, 2016 at 2:32 AM, Gary Kačmarčík (Кошмарчик) < gary...@google.com> wrote: > +public-webapps since these these notes are relevant for both groups > > On Fri, Jan 8, 2016 at 5:03 PM, Johannes Wilm > wrote: > >> Just so we don't have too many different ideas

Re: time at TPAC other than Wednesday?

On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin wrote: > Hello Johannes, > > > > I was the one to organize the meeting. To make things clear, this was an > ad hoc meeting with the intent for the browsers to resolve any ambiguities > and questions on beforeInput spec, which

RE: time at TPAC other than Wednesday?

Hello Johannes, I was the one to organize the meeting. To make things clear, this was an ad hoc meeting with the intent for the browsers to resolve any ambiguities and questions on beforeInput spec, which we did. This was the reason I invited representatives from each browser only. To your

Re: [WebIDL] T[] migration

On 12/18/15 3:53 AM, Simon Pieters wrote: Note that it requires liveness. Does that work for a frozen array? No. You'd have to create a new array object at the point when you want to update the set of values in the array. Maybe this particular API should be a method instead that returns a

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

> On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) wrote: > > Is there any option to attend this remotely (telcon or video conference)? > > 2015年12月9日(水) 10:26 Ryosuke Niwa : >> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa wrote: > > > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) > wrote: > > > > Is there any option to attend this remotely (telcon or video conference)? > > > > 2015年12月9日(水) 10:26 Ryosuke Niwa

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

Is there any option to attend this remotely (telcon or video conference)? 2015年12月9日(水) 10:26 Ryosuke Niwa : > > > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile < > cha...@yandex-team.ru> wrote: > > > > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile < >

FileReader.prototype.readAsText Question

Hi all, I have a question about " FileReader.prototype.readAsText " using chunks of data with "Blob.prototype.slice" : How do you handle an incomplete encoded character sequence, i.e. how do we get the number of decoded bytes ? Thanks

Re: Service worker F2F meeting - 26th Jan - San Francisco

Updated https://github.com/slightlyoff/ServiceWorker/issues/806 with attendees, including Ilya & Conrad. On Tue, 5 Jan 2016 at 00:27 Ilya Grigorik wrote: > > On Mon, Jan 4, 2016 at 9:12 AM, Anne van Kesteren > wrote: > >> We have three more seats at this

Service worker F2F meeting - 26th Jan - San Francisco

Since many of those involved in service workers will be in town for the web components meeting on the 25th ( https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md) we're having a service workers meeting on the 26th. The meeting is being hosted by Mozilla

[workers]

กูนี้หละเจ้าพ่อ Heak ker

Re: Service worker F2F meeting - 26th Jan - San Francisco

On Mon, Jan 4, 2016 at 9:12 AM, Anne van Kesteren wrote: > We have three more seats at this point, allocated on the basis of > first come, first served. > If any are still available, I'd like to reserve one as well :)

Re: Service worker F2F meeting - 26th Jan - San Francisco

On Mon, Jan 4, 2016 at 5:56 PM, Conrad Irwin wrote: > I'd be interested in attending as a relatively mute observer. We've been > using service workers for a while now, and I'd like to get more involved. Great, you're in, no need to be mute though. We have three more

Re: Service worker F2F meeting - 26th Jan - San Francisco

I'd be interested in attending as a relatively mute observer. We've been using service workers for a while now, and I'd like to get more involved. Conrad On Monday, January 4, 2016, Jake Archibald wrote: > Since many of those involved in service workers will be in

RE: Custom elements contentious bits

From: Brian Kardell [mailto:bkard...@gmail.com] > I'd really like to understand where things really are with async/sync/almost > sync - does anyone have more notes or would they be willing to provide more > exlpanation?  I've read the linked contentious bit and I'm still not sure > that I

Re: Can we land heycam's WebIDL tests as-is and address review comments following?

On Mon, 21 Dec 2015 07:34:12 +0100, Zhang, Zhiqiang wrote: Hi, 2+ years ago, heycam submitted WebIDL tests at https://github.com/w3c/web-platform-tests/pull/271 These tests have been reviewed by several guys but get no update ever since. I wonder if we could

RE: Can we land heycam's WebIDL tests as-is and address review comments following?

Travis, Great. Glad to hear that you are working on the tests. Perhaps you can try Simon' method to make your update in a new branch in w3c/web-platform-tests, so that others can make updates together. Thanks, Zhiqiang From: Travis Leithead [mailto:travis.leith...@microsoft.com] Sent: Monday,

Re: [WebIDL] T[] migration

On Fri, 18 Dec 2015 18:04:27 +0100, Olli Pettay wrote: On 12/18/2015 06:20 PM, Domenic Denicola wrote: From: Simon Pieters [mailto:sim...@opera.com] Note that it requires liveness. Does that work for a frozen array? Frozen array instances are frozen and cannot change.

RE: Can we land heycam's WebIDL tests as-is and address review comments following?

Yves and I have been reviewing these tests and revising them according to recent WebIDL changes and we think they may be ready to be integrated. The updates are in a PR on heycams page. Let’s not integrate heycam’s original PR until our update is done first please… From: Simon

Can we land heycam's WebIDL tests as-is and address review comments following?

Hi, 2+ years ago, heycam submitted WebIDL tests at https://github.com/w3c/web-platform-tests/pull/271 These tests have been reviewed by several guys but get no update ever since. I wonder if we could land the tests as-is and address the review comments in further pull requests? Then we can

Re: [WebIDL] T[] migration

On Thu, 16 Jul 2015 18:16:04 +0200, Boris Zbarsky wrote: Other references: ·CSS OM Presumably this is Document.styleSheetSets? In practice, I believe no one except Gecko implements this and I therefore don't expect it to make it to REC... Updating this draft to use

RE: [WebIDL] T[] migration

From: Simon Pieters [mailto:sim...@opera.com] > Note that it requires liveness. Does that work for a frozen array? Frozen array instances are frozen and cannot change. However, you can have the property that returns them start returning a new frozen array. The spec needs to track when these

Re: [WebIDL] T[] migration

On 12/18/2015 06:20 PM, Domenic Denicola wrote: From: Simon Pieters [mailto:sim...@opera.com] Note that it requires liveness. Does that work for a frozen array? Frozen array instances are frozen and cannot change. However, you can have the property that returns them start returning a new

Re: Proposal - Personal Identity API

On 17 December 2015 at 13:26, Stian Soiland-Reyes < soiland-re...@cs.manchester.ac.uk> wrote: > Excerpts from Binyamin's message of 2015-12-12 19:50:31 +: > > Currently many apps uses SSO (Single sign-on, > > https://en.wikipedia.org/wiki/Single_sign-on) with different APIs and > > protocols.

Re: Proposal - Personal Identity API

Also see `navigator.id` in FX: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/id Sam On Thu, 17 Dec 2015 at 12:30 Stian Soiland-Reyes < soiland-re...@cs.manchester.ac.uk> wrote: > Excerpts from Binyamin's message of 2015-12-12 19:50:31 +: > > Currently many apps uses SSO

Re: Proposal - Personal Identity API

Excerpts from Binyamin's message of 2015-12-12 19:50:31 +: > Currently many apps uses SSO (Single sign-on, > https://en.wikipedia.org/wiki/Single_sign-on) with different APIs and > protocols. It still requires server-side authentications. > Browsers/OSs has to validate the main personal

Proposal - Personal Identity API

בע"ה Hi, I purpose to implement Personal Identity API (I have not jet found anything similar to it). This days all recent browsers (Chrome, Firefox, Opera, Edge, etc.) and devices (Android, iOS, Firefox OS, etc.) prefers or requires Signin with user personal identification data (at least

Re: Custom elements contentious bits

On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola wrote: > A bit ago Jan put together an initial draft of the "contentious bits" for > custom elements, in preparation for our January F2F. Today I went through and > expanded on the issues he put together, with the result at >

Re: Custom elements contentious bits

On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren wrote: > On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola wrote: > > A bit ago Jan put together an initial draft of the "contentious bits" > for custom elements, in preparation for our January F2F. Today I

Web Applications Working Group now Closed; join the Web Platform Working Group (Call for Participation)

Dear Advisory Committee Representative, Chairs, Web Applications Working Group members, The Web Applications Working Group, whose charter expires until 31 July 2016, is now closed. The group has been working since 2008 on [Specifications] that enable improved client-side application

[service-workers] How can one use in-memory global state in Service Workers?

Experts on Service Workers: Per the spec ( https://slightlyoff.github.io/ServiceWorker/spec/service_worker/), global states will be discarded in between service worker restarts. This is understandable, however, it makes it impossible or too difficult to implement some use cases. Consider

Re: Indexed DB + Promises

On Mon, Oct 5, 2015 at 3:27 PM, Joshua Bell wrote: > 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.

Shadow DOM and alternate stylesheets

Hi, what should happen with the title attribute of style elements in Shadow DOM? In Blink you can currently select style elements in shadow trees based on the alternate stylesheet name set for the document. You even set the preferred stylesheet using the title on style elements inside shadow

Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile wrote: we are trying to shift the date of the Custom Elements meeting to *25* Jan, from the previously proposed date of 29th. We are currently looking for a host in the Bay area - offers gratefully

Re: Shadow DOM and alternate stylesheets

On Tue, Dec 8, 2015 at 4:43 AM, Rune Lillesveen wrote: > what should happen with the title attribute of style elements in Shadow DOM? > > In Blink you can currently select style elements in shadow trees based > on the alternate stylesheet name set for the document. You even set >

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

> On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile > wrote: > > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile > wrote: > >> we are trying to shift the date of the Custom Elements meeting to *25* Jan, >> from the previously

Custom Elements meeting will be 25th Jan (not 29th)

Dear all, we are trying to shift the date of the Custom Elements meeting to *25* Jan, from the previously proposed date of 29th. We are currently looking for a host in the Bay area - offers gratefully received. If you plan to attend, please add your name to the meeting page:

Re: Custom elements contentious bits

Domenic, Closed shadow DOM and its impact on test automation and auditing is also a very important issue. --Dylan On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola wrote: > Hi all, > > A bit ago Jan put together an initial draft of the "contentious bits" for > custom

Re: Meeting date, january

Great, lets do the 25th then. :) On Wed, Dec 2, 2015 at 1:09 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > 25th works for me. > > -Original Message- > From: Domenic Denicola [mailto:d...@domenic.me] > Sent: Tuesday, December 1, 2015 8:32 AM > To: Chaals McCathie Nevile

Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Art, On 12/02/2015 02:23 PM, Arthur Barstow wrote: > Yves and Travis would like to publish a Candidate Recommendation > of WebIDL Level 1 and this is a Call for Consensus to do so. The > draft CR is: > >

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

1) Encryption between Alice and Bob by means of an asymmetric public/private key exchange protocol cannot be secure if both also exchange the keys and none has a method to verify the keys they got are the correct ones. Chuck who might control the gateway over which either Alice or Bob communicate

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch wrote: > 1) Encryption between Alice and Bob by means of an asymmetric > public/private key exchange protocol cannot be secure if both also exchange > the keys and none has a method to verify the keys they got are the correct >

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

> > In DTLS, each handshake message is assigned a specific sequence >number within that handshake. When a peer receives a handshake >message, it can quickly determine whether that message is the next >message it expects. If it is, then it processes it. If not, it >queues it for

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 10:01 AM, Florian Bösch wrote: > In DTLS, each handshake message is assigned a specific sequence >>number within that handshake. When a peer receives a handshake >>message, it can quickly determine whether that message is the next >>message

RE: Publish WD of HTML Accessibility API Mappings (AAM) 1.0

The WP WG approves publication of the HTML AAM WD. Léonie, Ade, Chaals and Art (WP co-chairs) > -Original Message- > From: Léonie Watson [mailto:lwat...@paciellogroup.com] > Sent: 19 November 2015 09:20 > To: public-webapps@w3.org > Cc: 'Michael Cooper' > Subject: PSA:

RE: Meeting date, january

25th works for me. -Original Message- From: Domenic Denicola [mailto:d...@domenic.me] Sent: Tuesday, December 1, 2015 8:32 AM To: Chaals McCathie Nevile ; 'public-webapps WG' ; Léonie Watson Cc: Anne van Kesteren

Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

> On 02 Dec 2015, at 16:11, Ms2ger wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Art, > > On 12/02/2015 02:23 PM, Arthur Barstow wrote: >> Yves and Travis would like to publish a Candidate Recommendation >> of WebIDL Level 1 and this is a Call for

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Le 01/12/2015 20:41, Brad Hill a écrit : >> As far as I see it, a "mixed content" has the word "content", which is > supposed to designate something that can be included in a web page and > therefore be dangerous. > > "Mixed Content" (and "mixed content blocking") is a term of art that has >

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte wrote: > > Then you should follow your rules and apply this policy to WebRTC, ie > allow WebRTC to work only with http. > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP. Also WebRTC does P2P, and there's

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Le 02/12/2015 13:18, Florian Bösch a écrit : > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte > wrote: > > Then you should follow your rules and apply this policy to WebRTC, ie > allow WebRTC to work only with http. > > > Just

CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

Yves and Travis would like to publish a Candidate Recommendation of WebIDL Level 1 and this is a Call for Consensus to do so. The draft CR is: If anyone has comments or concerns about this CfC, please reply by December 9 at the

Fwd: Fingerprinting Guidance for Web Specification Authors

Editors, All - please see "Fingerprinting Guidance for Web Specification Authors" and reflect it in your spec, accordingly. Forwarded Message Subject:Fingerprinting Guidance for Web Specification

Re: Fingerprinting Guidance for Web Specification Authors

On Tue, Dec 1, 2015 at 11:52 AM, Arthur Barstow wrote: > Editors, All - please see "Fingerprinting Guidance for Web Specification > Authors" > and reflect it in your spec, accordingly. Tracking can be a

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

> As far as I see it, a "mixed content" has the word "content", which is supposed to designate something that can be included in a web page and therefore be dangerous. "Mixed Content" (and "mixed content blocking") is a term of art that has been in use for many years in the browser community. As

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Le 01/12/2015 05:31, Brad Hill a écrit : > Let's keep this discussion civil, please. Maybe some wording was a little tough below, apologies for this, the logjam attack is difficult to swallow, how something that is supposed to protect forward secrecy can do quietly the very contrary without

RE: Meeting date, january

From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru] > Yes, likewise for me. Anne, Olli specifically called you out as someone we > should ask. I am assuming most people are OK either way, having heard no > loud screaming except for Elliot... I would be pretty heartbroken if we met

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Not sure that you know what you are talking about here, maybe influenced by fb's onion things, or you misunderstood what I wrote. I am not talking about the Tor network, neither the Hidden services, I am talking about the Tor protocol itself, that's different and it is known to be strong, but

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte wrote: > Not sure that you know what you are talking about here, maybe influenced > by fb's onion things, or you misunderstood what I wrote. > > I am not talking about the Tor network, neither the Hidden services, I > am

WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Redirecting this to WebApps since it's probable that we are facing a design mistake that might amplify by deprecating non TLS connections. I have submitted the case to all possible lists in the past, never got a clear answer and was each time redirected to another list (ccing webappsec but as a

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

I don't think there is universal agreement among browser engineers (if anyone agrees at all) with your assertion that the Tor protocol or even Tor hidden services are "more secure than TLS". TLS in modern browsers requires RSA 2048-bit or equivalent authentication, 128-bit symmetric key

RE: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

“Secure against which threats?” is the question. TLS, with its stronger crypto, is more secure against an adversary that wants to read the content of your messages. ToR is more secure against an adversary that wants to detect that you visit a particular site, are associated with particular

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte wrote: > You must be kidding, the logjam attack showed the complete failure of > TLS Sure, protocols have bugs, and bugs get fixed. The things we require for HTTPS aren't even design goals of Tor. > and your 1/2/3

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

What are you talking about? The logjam attack just shows that you (spec security experts of major internet companies) are incompetent, or just knew about it. You don't know Tor "plenty well", I am not referring at all to hidden services, the fb case, or the ridiculous related case of a https

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes wrote: > 1. Authentication: You know that you're talking to who you think you're > talking to. > And then Dell installs a their own root authority on machines they ship, or your CA of choice gets pwn'ed or the NSA uses some

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

You must be kidding, the logjam attack showed the complete failure of TLS and your 1/2/3 (notwithstanding the useless discussions about CAs & co), which does not apply to the Tor protocol that you don't know apparently but that fulfills 1/2/3 I am not a Tor advocate, this is just an example

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

How about the many of the Tor endpoints being compromised? Does that show a complete failure of Tor? I would say no. http://www.ibtimes.co.uk/tor-anonymity-network-compromised-following-potential-raid-by-law-enforcement-agencies-1480620 Most folks who really care about this stuff use Tor and

Re: Meeting date, january

On Tue, 01 Dec 2015 00:15:23 +1000, Léonie Watson wrote: From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: 26 November 2015 01:55 it appears that there are some people may not be able to attend a meeting on the 29th - although Apple has

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Let's keep this discussion civil, please. The reasons behind blocking of non-secure WebSocket connections from secure contexts are laid out in the following document: http://www.w3.org/TR/mixed-content/ A plaintext ws:// connection does not meet the requirements of authentication, encryption

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

On 11/30/15 8:31 AM, Xiaoqian Wu wrote: The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have been widely implemented by the major browser vendors. Compatibly? Last I checked, for example, Blink doesn't support Dedicated Workers inside workers, only inside Window. I

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

> On 30 Nov 2015, at 10:02 PM, Boris Zbarsky wrote: > > On 11/30/15 8:31 AM, Xiaoqian Wu wrote: >> The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers >> have been widely implemented by the major browser vendors. > > Compatibly? Last I checked, for

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

On 11/30/2015 02:31 PM, Xiaoqian Wu wrote: > This is a call for comments regarding the next step of Web Workers. > > The latest [TEST RESULTS] of Web Workers indicate that Dedicated > Workers have been widely implemented by the major browser vendors. > > [Diff] between the latest W3C WD and the

RE: Meeting date, january

> From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru] > Sent: 26 November 2015 01:55 > it appears that there are some people may not be able to attend a meeting > on the 29th - although Apple has generously offered to host that day. > > Is there anyone who would only be able to attend if

CfC: Is Web Workers Ready for CR? deadline Dec 14

This is a call for comments regarding the next step of Web Workers. The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have been widely implemented by the major browser vendors. [Diff] between the latest W3C WD and the WHATWG living standard suggests substantial changes

Re: Meeting date, january

CSSWG and Houdini are in Sydney starting on the 30th, which means I couldn't go to both which is unfortunate. I'd prefer the 25th. :) On Wed, Nov 25, 2015 at 5:54 PM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > Hi, > > it appears that there are some people may not be able to attend

Meeting date, january

Hi, it appears that there are some people may not be able to attend a meeting on the 29th - although Apple has generously offered to host that day. Is there anyone who would only be able to attend if we moved the meeting to the 25th? Conversely, would that shift cause problems for anyone

[CSSWG] Minutes Sapporo F2F 2015-10-27 Part IV: Joint Meeting With WebApps

Joint Meeting With WebApps -- - There was conversation to further understand the use of and use cases for :host and :host-context in ShadowDOM - There was a struggle to find a use case for :host. - In regards to :host-context it was felt the same effect

PSA: Publish WD of HTML Accessibility API Mappings (AAM) 1.0

Hello WP, This is notice of intent to publish a new Working Draft of HTML Accessibility API Mappings on/around 19th November [1]. It is a joint publication of the Web Platform and ARIA WGs. Léonie. [1] http://w3c.github.io/aria/html-aam/html-aam.html -- Senior accessibility engineer

[admin] Web Platform WG is really the new WebApps

Hi All, back in October, we started the Web Platform WG [1] and invited folks to join the new Group at the time [Register]. We did not formally closed down the Web Applications Working Group however. This is an advance notice that we are going to close down the Web Applications Working

No meeting in december Re: [web components] proposed meetings: 15 dec / 29 jan

OK, just to formally close the loop we will not have a meeting in December. cheers On Mon, 16 Nov 2015 05:12:55 +0100, Hayato Ito wrote: Thank you, Ryosuke. I'm fine not to have a meeting in Dec. Let me add a link to GitHub issue(s) for each item: 1. Clarify focus

29 Jan? Re: [web components] proposed meetings: 15 dec / 29 jan

Hi folks, having canceled the proposed december meeting, and with a little less time pressure, this is a check that people are still interested in a face to face meeting for web components stuff - shadow DOM and custom elements both have some currently outstanding issues. I changed the

High Resolution Time 2: time origin and worker support

The latest version of High Resolution Time is ready for wide review. One can find the latest draft at: http://www.w3.org/TR/hr-time-2/ High Resolution Time Level 2 replaces the first version of High Resolution Time [HR-TIME] and includes: * Defines a precise definition of time origin for

Re: [web components] proposed meetings: 15 dec / 29 jan

Thank you, Ryosuke. I'm fine not to have a meeting in Dec. Let me add a link to GitHub issue(s) for each item: > 1. Clarify focus navigation I think the following two GitHub issues are good starting points to know the current status. https://github.com/w3c/webcomponents/issues/103

[web components] proposed meetings: 15 dec / 29 jan

Hi folks, in the poll we ran, there were only about 10 responses, and the preference split was pretty even. I also forgot to make a place where people could provide their name :( Our proposal is to look for a host on 15 December on the West Coast, for a meeting primarily focused on

Re: [web components] proposed meetings: 15 dec / 29 jan

> On Nov 13, 2015, at 8:08 AM, Anne van Kesteren wrote: > > On Fri, Nov 13, 2015 at 4:57 PM, Ryosuke Niwa wrote: >> What outstanding problems are you thinking of? > > Again, not I, but Hayato Ito raised these. I just happen to agree. He > emailed this list

Re: [web components] proposed meetings: 15 dec / 29 jan

> On Nov 13, 2015, at 3:07 AM, Anne van Kesteren wrote: > > On Fri, Nov 13, 2015 at 11:32 AM, Chaals McCathie Nevile > wrote: >> Our proposal is to look for a host on 15 December on the West Coast, for a >> meeting primarily focused on Shadow DOM, and

Re: [web components] proposed meetings: 15 dec / 29 jan

On Fri, Nov 13, 2015 at 4:57 PM, Ryosuke Niwa wrote: > What outstanding problems are you thinking of? Again, not I, but Hayato Ito raised these. I just happen to agree. He emailed this list on November 2:

Re: [web components] proposed meetings: 15 dec / 29 jan

On Fri, Nov 13, 2015 at 11:32 AM, Chaals McCathie Nevile wrote: > Our proposal is to look for a host on 15 December on the West Coast, for a > meeting primarily focused on Shadow DOM, and another on 29 January in the > Bay area for one around Custom Elements. The agenda can

Re: Callback when an event handler has been added to a custom element

Hi! On Fri, Nov 6, 2015 at 5:12 PM, Domenic Denicola wrote: > In general I would be cautious about this kind of API. Events are not > expected to have side effects, and adding listeners should not cause an > (observable) action. Hm, but message port API itself has such a

RE: Callback when an event handler has been added to a custom element

From: Mitar [mailto:mmi...@gmail.com] > Hm, but message port API itself has such a side-effect: I think that is just a very bad API. The platform is unfortunately full of bad APIs :). In particular, a difference between two different ways of adding event listeners is not something authors

RE: Callback when an event handler has been added to a custom element

In general I would be cautious about this kind of API. Events are not expected to have side effects, and adding listeners should not cause an (observable) action. See e.g. https://dom.spec.whatwg.org/#action-versus-occurance which tries to explain this in some detail. A better design in your

Re: Callback when an event handler has been added to a custom element

On Fri, Nov 6, 2015 at 5:12 PM, Domenic Denicola wrote: > In general I would be cautious about this kind of API. Events are not > expected to have side effects, and adding listeners should not cause an > (observable) action. See e.g. >

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