Re: Proposal for a DOM L3 Events Telecon

2013-05-01 Thread Wez
Hi guys, mind if I tag along with Gary on the call? On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик) gary...@google.comwrote: On Mon, Apr 29, 2013 at 12:59 PM, Travis Leithead travis.leith...@microsoft.com wrote: I’d like to propose we start a call to begin to work toward resolving the

Re: Proposal for a DOM L3 Events Telecon

2013-05-01 Thread 河内 隆仁
If Masayuki-san is joining and the time is JST-friendly, I would also like to join, but feel free to ignore me if not. On Wed, May 1, 2013 at 6:30 PM, Wez w...@google.com wrote: Hi guys, mind if I tag along with Gary on the call? On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик)

Re: URL comparison

2013-05-01 Thread Anne van Kesteren
On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: We created a prollyfill for this about a year ago (called :-link-local instead of :local-link for forward compatibility): http://hitchjs.wordpress.com/2012/05/18/content-based-css-link/ Cool! If you can specify the

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

2013-05-01 Thread Anne van Kesteren
On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib sch...@google.com wrote: I argue on that issue that we should not bubble the event and have the handler on document only. Pointer lock doesn't have as much legacy spec churn as fullscreen, but I think we're in a position to have both of them be

Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)

2013-05-01 Thread Alec Flett
I think there are some good use cases for not-quite-offline as well. Sort of a combination of your twitter and wikipedia use cases: Community-content site: Logged-out users have content cached aggressively offline - meaning every page visited should be cached until told otherwise. Intermediate

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Tab Atkins Jr.
On Tue, Apr 30, 2013 at 11:10 AM, Ryosuke Niwa rn...@apple.com wrote: I'm concerned that we're over engineering here. A valid concern in general, but I'm confident that we're actually hitting the right notes here, precisely because we've developed these more complicated features due to direct

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

2013-05-01 Thread Vincent Scheib
On Wed, May 1, 2013 at 7:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib sch...@google.com wrote: I argue on that issue that we should not bubble the event and have the handler on document only. Pointer lock doesn't have as much legacy spec

Re: URL comparison

2013-05-01 Thread Brian Kardell
+ the public-nextweb list... On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell bkard...@gmail.com wrote: We created a prollyfill for this about a year ago (called :-link-local instead of :local-link for forward

RE: Proposal for a DOM L3 Events Telecon

2013-05-01 Thread Travis Leithead
I’d like to be sure we get Masayuki in our discussions as this represents at least a trio of implementors on the call. The 4pm PDT (Tue) / 8am JST (Wed) will work for me. I’ll set up the telco details and send them out. From: Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com] Sent: Wednesday,

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Ryosuke Niwa
On Apr 30, 2013, at 12:07 PM, Daniel Freedman dfre...@google.com wrote: I'm concerned that if the spec shipped as you described, that it would not be useful enough to developers to bother using it at all. I'm concerned that we can never ship this feature due to the performance penalties it

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Dimitri Glazkov
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2013, at 12:07 PM, Daniel Freedman dfre...@google.com wrote: I'm concerned that if the spec shipped as you described, that it would not be useful enough to developers to bother using it at all. I'm concerned

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Scott Miles
I'm concerned that we can never ship this feature due to the performance penalties it imposes. Can you be more explicit about the penalty to which you refer? I understand there are concerns about whether the features can be made fast, but I wasn't aware of an overall penalty on code that is not

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Jonas Sicking
My proposal is to allow for multiple insertion points, and use selectors to filter the insertion points. However restrict the set of selectors such that only an elements intrinsic state affects which insertion point it is inserted in. I.e. only an elements name, attributes and possibly a few

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Scott Miles
Note that the interesting restriction isn't that it shouldn't regress performance for the web-at-large. No argument, but afaict, the implication of R. Niwa's statement was was in fact that there was a penalty for these features merely existing. The restriction is that it shouldn't be slow

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Daniel Freedman
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2013, at 12:07 PM, Daniel Freedman dfre...@google.com wrote: I'm concerned that if the spec shipped as you described, that it would not be useful enough to developers to bother using it at all. I'm concerned

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Dimitri Glazkov
FWIW, I don't mind revisiting and even tightening selectors on insertion points. I don't want this to be a sticking point. :DG On Wed, May 1, 2013 at 12:46 PM, Scott Miles sjmi...@google.com wrote: Note that the interesting restriction isn't that it shouldn't regress performance for the

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Scott Miles
Sorry it got lost in other messages, but fwiw, I also don't have problem with revisiting and even tightening selectors Scott On Wed, May 1, 2013 at 12:55 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: FWIW, I don't mind revisiting and even tightening selectors on insertion points. I don't

Re: URL comparison

2013-05-01 Thread Clint Hill
I'd like to add to what Brian is saying below: This is effectively the goal of the public-nextweb group as I see it. We want to provide a way for developers to build these types of prollyfills and .. More importantly .. Share and publicize them to get the necessary exposure and feedback. Without

Blob URLs | autoRevoke, defaults, and resolutions

2013-05-01 Thread Arun Ranganathan
At the recent TPAC for Working Groups held in San Jose, Adrian Bateman, Jonas Sicking and I spent some time taking a look at how to remedy what the spec. says today about Blob URLs, both from the perspective of default behavior and in terms of what correct autoRevoke behavior should be. This

Re: Blob URLs | autoRevoke, defaults, and resolutions

2013-05-01 Thread Eric U
On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote: At the recent TPAC for Working Groups held in San Jose, Adrian Bateman, Jonas Sicking and I spent some time taking a look at how to remedy what the spec. says today about Blob URLs, both from the perspective of default

Re: Blob URLs | autoRevoke, defaults, and resolutions

2013-05-01 Thread Jonas Sicking
On Wed, May 1, 2013 at 4:25 PM, Eric U er...@google.com wrote: On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote: Switching the default to false would enable IE, Chrome, andFirefox to have interoperability with URL.createObjectURL(blobArg), though such a default places

Re: Blob URLs | autoRevoke, defaults, and resolutions

2013-05-01 Thread Glenn Maynard
On Wed, May 1, 2013 at 5:36 PM, Arun Ranganathan a...@mozilla.com wrote: 2a. To meticulously special-case Blob URLs, per Bug 17765 [4]. This calls for a synchronous step attached to wherever URLs are used to peg Blob URL data at fetch, so that the chance of a concurrent revocation doesn't

Re: Blob URLs | autoRevoke, defaults, and resolutions

2013-05-01 Thread Eric U
On Wed, May 1, 2013 at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 1, 2013 at 4:25 PM, Eric U er...@google.com wrote: On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote: Switching the default to false would enable IE, Chrome, andFirefox to have

Re: Blob URLs | autoRevoke, defaults, and resolutions

2013-05-01 Thread Glenn Maynard
On Wed, May 1, 2013 at 7:01 PM, Eric U er...@google.com wrote: Hmm...now Glenn points out another problem: if you /never/ load the image, for whatever reason, you can still leak it. How likely is that in good code, though? And is it worse than the current state in good or bad code? I

Re: ZIP archive API?

2013-05-01 Thread Paul Bakaus
Still waiting for it as well. I think it'd be very useful to transfer sets of assets etc. From: Florian Bösch pya...@gmail.commailto:pya...@gmail.com Date: Tue, 30 Apr 2013 15:58:22 +0200 To: Anne van Kesteren ann...@annevk.nlmailto:ann...@annevk.nl Cc: Charles McCathie Nevile

Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)

2013-05-01 Thread Paul Bakaus
Hi Jonas, hi Alec, I think all of this is great stuff that helps a ton – thanks! Let's definitely put them onto a wiki somewhere. Charles: Where would be the right place to put that list? I'm imagining a big table with columns for the proposal and then each of the AppCache 2.0 proposals

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Ryosuke Niwa
On May 1, 2013, at 12:46 PM, Scott Miles sjmi...@google.com wrote: Note that the interesting restriction isn't that it shouldn't regress performance for the web-at-large. No argument, but afaict, the implication of R. Niwa's statement was was in fact that there was a penalty for these

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-05-01 Thread Scott Miles
I'm sure Web developers are happy to have more features but I don't want to introduce a feature that imposes such a high maintenance cost without knowing for sure that they're absolutely necessary. You are not taking 'yes' for an answer. :) I don't really disagree with you here. With respect to