Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 17:51, Boris Zbarsky wrote: The same blob should have different URLs in different documents, no? All documents originated from the same application/session/same-origin? No. That's the point. Unless you want the lifetime of the Blob to immediately become "while you have any do

Re: Charter addition proposal: screen orientation lock

Hi, On Mon, Jan 30, 2012 at 6:32 PM, Mounir Lamouri wrote: > > This is what I meant by "not a MUST", so I guess we agree :) > Perfect! :) > > We need this to be tied together in some way, so that it is possible to > > click on say, a video element and have to animate entering fullscreen > > a

[Bug 15796] New: Specify how to extract a key when keyPath is an array

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15796 Summary: Specify how to extract a key when keyPath is an array Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal

Re: Fwd: Data compression APIs?

On 1/30/12 6:11 AM, timeless wrote: There have been some requests for zip support [1], and probably less relevant for xhr [2]. Note that the use case I'm forwarding [3] requires support for both compression and decompression. I'm solely looking for inflate / deflate support. It provides a dece

Re: [FileAPI] createObjectURL isReusable proposal

On Sat, 28 Jan 2012, Kyle Huey wrote: > > Why though? What stops UAs from accepting the relevant objects for .src > properties? You don't necessarily have an object, e.g. if you're using innerHTML or document.write(). -- Ian Hickson U+1047E)\._.,--,'``.fL

Re: Charter addition proposal: screen orientation lock

On 01/30/2012 03:57 PM, Kenneth Rohde Christiansen wrote: > Also, I do not think the specifications should restrain the conditions > in which the screen orientation lock can happen. At least not at the > > > It doesn't have to do that, but it could point out that UAs might want > to restr

Re: CfC Re: Charter addition proposal: screen orientation lock

On 01/30/2012 02:26 PM, Charles McCathieNevile wrote: > OK, since I was planning to have the charter up today, let's have a > quick call for consensus on this. Please reply by end of business > Wednesday if you support or object to this - silence will be taken as > not explicitly supporting it, and

Fwd: Re: [FileAPI] createObjectURL isReusable proposal

Original Message Subject:Re: [FileAPI] createObjectURL isReusable proposal Date: Mon, 30 Jan 2012 17:51:55 +0100 From: Bronislav Klučka To: Boris Zbarsky On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case

Re: Charter addition proposal: screen orientation lock

On Jan 30, 2012, at 13:45 , Marcos Caceres wrote: > On Monday, 30 January 2012 at 22:22, Robin Berjon wrote: >> Sorry, I should indeed have mentioned that as part of the background. The >> problem with specifying orientation as part of the viewport at rule is that >> it leads to circular dependen

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 11:44 AM, Bronislav Klučka wrote: Both could be solved by Blob.URL, there is no strange string somehow connected to blob. Blob belongs to URL and URL belongs to blob... who cares how exactly is the string created (split -> join), it is string identification, not pointer reference...

Re: Charter clarification: common manifest

On Jan 30, 2012, at 13:38 , Marcos Caceres wrote: > On Monday, 30 January 2012 at 21:26, Robin Berjon wrote: >> It's not something that has happened to date, but I'm hearing indications >> that there could be interest in quickly aligning on a manifest for web apps >> (that would I presume differ

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether someo

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether someone has a "reference" it. Consider this:

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > so just a line > URL.createObjectUrl(blob) > creates a memory leak? Heh? > > Which brink me to my previous question, what happened to Blob.URL? Just > brink it back and this whole conversation can go away... > The only way blob.URL differs from URL.createObjectUrl is

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 16:56, Boris Zbarsky wrote: On 1/30/12 10:40 AM, Bronislav Klučka wrote: img1 = document.getElementById("my-image"); img1.src = URL.createObjectUrl(myBlob); img2.src = img1.src; should work like a charm and the URL and blob will be released as soon as all references will be 0 (des

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 10:40 AM, Bronislav Klučka wrote: img1 = document.getElementById("my-image"); img1.src = URL.createObjectUrl(myBlob); img2.src = img1.src; should work like a charm and the URL and blob will be released as soon as all references will be 0 (destroying the image) No, it won't. As curre

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 16:14, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka > And how? Using src attribute? that would have to be changed to accept both string and Blob object? What it would return on get operation? Libraries managing images (lightboxes

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > And how? Using src attribute? that would have to be changed to accept both > string and Blob object? What it would return on get operation? Libraries > managing images (lightboxes) would have to consider, what does src mean? Or > do you propose other attribute? What w

Re: Charter addition proposal: screen orientation lock

Hello, On Mon, Jan 30, 2012 at 3:36 PM, Mounir Lamouri wrote: > On 01/30/2012 12:43 PM, Kenneth Rohde Christiansen wrote: > > Hi there, > > > > Orientation lock is already part of the CSS Device Adaption spec as part > > of the viewport meta tag, though this is only going to be optional and > >

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 15:18, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka > it would seem that you do not understand the point here... if we allow img.src = blob approach we would HAVE TO have memory management on language level as well, either UR

Re: Charter addition proposal: screen orientation lock

On 01/30/2012 12:43 PM, Kenneth Rohde Christiansen wrote: > Hi there, > > Orientation lock is already part of the CSS Device Adaption spec as part > of the viewport meta tag, though this is only going to be optional and > should be ignored for normal web browsing due to the effect on usability > (

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > it would seem that you do not understand the point here... if we allow > img.src = blob approach we would HAVE TO have memory management on language > level as well, > either URL reference or blob must be freed/nulled/whatever somewhere. > This is not simple reference

Fwd: Data compression APIs?

Since webapps is currently rechartering, is this something it wants to consider? Note that I'm not a member of webapps at this time. There have been some requests for zip support [1], and probably less relevant for xhr [2]. Note that the use case I'm forwarding [3] requires support for both compr

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 14:40, Kyle Huey wrote: 2012/1/28 Bronislav Klučka > img.src = blob; tells nothing about possible access to underlying data using URL identifier And I think that if we're concerned about the blob being "leaked" for the lifetime

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/28 Bronislav Klučka > img.src = blob; > > tells nothing about possible access to underlying data using URL identifier > And I think that if we're concerned about the blob being "leaked" for the lifetime of the document (because the URL was never revoked) we should abandon the blob URL app

Re: CfC Re: Charter addition proposal: screen orientation lock

I support, but I think it tied into the device adaptions spec, fullscreen and also splash screen support. Kenneth On Mon, Jan 30, 2012 at 2:26 PM, Charles McCathieNevile wrote: > OK, since I was planning to have the charter up today, let's have a quick > call for consensus on this. Please reply

CfC Re: Charter addition proposal: screen orientation lock

OK, since I was planning to have the charter up today, let's have a quick call for consensus on this. Please reply by end of business Wednesday if you support or object to this - silence will be taken as not explicitly supporting it, and without support it isn't going to get into the draft

[Bug 15794] apa yang kamu lakukan terhadapku ?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15794 Art Barstow changed: What|Removed |Added CC||art.bars...@nokia.com Resolution

Re: Charter addition proposal: screen orientation lock

On Monday, 30 January 2012 at 22:50, Kenneth Rohde Christiansen wrote: > Hi there, > > On Mon, Jan 30, 2012 at 1:22 PM, Robin Berjon (mailto:ro...@berjon.com)> wrote: > > Hi, > > > > On Jan 30, 2012, at 12:43 , Kenneth Rohde Christiansen wrote: > > > Orientation lock is already part of the

[Bug 15794] apa yang kamu lakukan terhadapku ?

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

[Bug 15794] New: apa yang kamu lakukan terhadapku ?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15794 Summary: apa yang kamu lakukan terhadapku ? Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other

Re: Charter addition proposal: screen orientation lock

Hi there, On Mon, Jan 30, 2012 at 1:22 PM, Robin Berjon wrote: > Hi, > > On Jan 30, 2012, at 12:43 , Kenneth Rohde Christiansen wrote: > > Orientation lock is already part of the CSS Device Adaption spec as part > of the viewport meta tag > > Sorry, I should indeed have mentioned that as part of

Re: Charter addition proposal: screen orientation lock

On Monday, 30 January 2012 at 22:22, Robin Berjon wrote: > Hi, > > On Jan 30, 2012, at 12:43 , Kenneth Rohde Christiansen wrote: > > Orientation lock is already part of the CSS Device Adaption spec as part of > > the viewport meta tag > > > > Sorry, I should indeed have mentioned that as p

Re: Charter clarification: common manifest

On Monday, 30 January 2012 at 21:26, Robin Berjon wrote: > Hi all, > > there is one aspect of the upcoming charter that I would like to see > clarified. Previously, it has been my understanding that if implementers > wanted to agree on a common manifest format for web apps, they ought to be

Re: Charter addition proposal: screen orientation lock

Hi, On Jan 30, 2012, at 12:43 , Kenneth Rohde Christiansen wrote: > Orientation lock is already part of the CSS Device Adaption spec as part of > the viewport meta tag Sorry, I should indeed have mentioned that as part of the background. The problem with specifying orientation as part of the vi

Re: Charter addition proposal: screen orientation lock

Hi there, Orientation lock is already part of the CSS Device Adaption spec as part of the viewport meta tag, though this is only going to be optional and should be ignored for normal web browsing due to the effect on usability (think about navigating session history). It is thus mostly useful for

Charter clarification: common manifest

Hi all, there is one aspect of the upcoming charter that I would like to see clarified. Previously, it has been my understanding that if implementers wanted to agree on a common manifest format for web apps, they ought to be able to do so within the bounds of this WG given that the same idea (a

Charter addition proposal: screen orientation lock

Hi all! Sorry for bringing this to the group this late, but it's a topic that's been discussed in other places and that I believe is both useful and mature enough to be ready for standardisation. Some applications are designed in such a way that they only make sense in one device orientation.