Hi guys, mind if I tag along with Gary on the call?
On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик) wrote:
> 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 final bug
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 wrote:
> Hi guys, mind if I tag along with Gary on the call?
>
>
> On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик) wrote:
>
>> On Mon, Ap
On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell 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 workings, we (p
On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib 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
> cleaned up befo
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 cac
On Tue, Apr 30, 2013 at 11:10 AM, Ryosuke Niwa 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 requests and comp
On Wed, May 1, 2013 at 7:00 AM, Anne van Kesteren wrote:
> On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib 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
+ the public-nextweb list...
On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren wrote:
> On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell wrote:
>> We created a prollyfill for this about a year ago (called :-link-local
>> instead of :local-link for forward compatibility):
>>
>> http://hitchjs.word
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, Ma
On Apr 30, 2013, at 12:07 PM, Daniel Freedman 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 imposes.
> Withou
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa wrote:
> On Apr 30, 2013, at 12:07 PM, Daniel Freedman 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 f
> 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
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 state
On Wed, May 1, 2013 at 12:15 PM, Dimitri Glazkov wrote:
> On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa wrote:
>> On Apr 30, 2013, at 12:07 PM, Daniel Freedman wrote:
>>
>>> I'm concerned that if the spec shipped as you described, that it would not
>>> be useful enough to developers to bother u
>> 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
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa wrote:
> On Apr 30, 2013, at 12:07 PM, Daniel Freedman 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 f
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 wrote:
>>> Note that the interesting restriction isn't that it "shouldn't regress
>>> performance for the web-at-large".
>
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 wrote:
> FWIW, I don't mind revisiting and even tightening selectors on
> insertion points. I don't want this to be a
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 t
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
On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan 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 behavior and
>
Eric,
On May 1, 2013, at 7:25 PM, Eric U wrote:
> On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan wrote:
>
>> 2b.To adopt an 80-20 rule, and only specify what happens for some cases that
>> seem common, but expressly disallow other cases. This might be a more muted
>> version of Bug 17765,
On Wed, May 1, 2013 at 4:25 PM, Eric U wrote:
> On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan wrote:
>> Switching the default to "false" would enable IE, Chrome, andFirefox to have
>> interoperability with URL.createObjectURL(blobArg), though such a default
>> places burdens on web developer
On Wed, May 1, 2013 at 5:36 PM, Arun Ranganathan 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 cause
> things
On Wed, May 1, 2013 at 4:53 PM, Jonas Sicking wrote:
> On Wed, May 1, 2013 at 4:25 PM, Eric U wrote:
>> On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan wrote:
>>> Switching the default to "false" would enable IE, Chrome, andFirefox to
>>> have interoperability with URL.createObjectURL(blobArg)
On Wed, May 1, 2013 at 7:01 PM, Eric U 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 think it's much
Still waiting for it as well. I think it'd be very useful to transfer sets of
assets etc.
From: Florian Bösch mailto:pya...@gmail.com>>
Date: Tue, 30 Apr 2013 15:58:22 +0200
To: Anne van Kesteren mailto:ann...@annevk.nl>>
Cc: Charles McCathie Nevile
mailto:cha...@yandex-team.ru>>, public-webapps
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
valida
On May 1, 2013, at 12:46 PM, Scott Miles 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 features
>> 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 t
30 matches
Mail list logo
