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
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.
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
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
Hi there,
On Mon, Jan 30, 2012 at 1:22 PM, Robin Berjon ro...@berjon.com 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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15794
Ms2ger ms2...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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 ro...@berjon.com
(mailto:ro...@berjon.com) wrote:
Hi,
On Jan 30, 2012, at 12:43 , Kenneth Rohde Christiansen wrote:
Orientation lock is already part
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
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 cha...@opera.comwrote:
OK, since I was planning to have the charter up today, let's have a quick
call for consensus on
2012/1/28 Bronislav Klučka bronislav.klu...@bauglir.com
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
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
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com
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
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
(think
On 30.1.2012 15:18, Glenn Maynard wrote:
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com
mailto:bronislav.klu...@bauglir.com
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
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com
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
On 30.1.2012 16:14, Glenn Maynard wrote:
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com
mailto:bronislav.klu...@bauglir.com
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
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
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com
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
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:
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
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 from
Original Message
Subject:Re: [FileAPI] createObjectURL isReusable proposal
Date: Mon, 30 Jan 2012 17:51:55 +0100
From: Bronislav Klučka bronislav.klu...@bauglir.com
To: Boris Zbarsky bzbar...@mit.edu
On 30.1.2012 17:29, Boris Zbarsky wrote:
On 1/30/12
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 restrict
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
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
Hi,
On Mon, Jan 30, 2012 at 6:32 PM, Mounir Lamouri mou...@lamouri.fr 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
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
28 matches
Mail list logo
