On Wed, Aug 6, 2014 at 12:24 PM, Anne van Kesteren ann...@annevk.nl wrote:
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533 on
investigating whether we can reuse the Request object (which is passed
to fetch(), and used in service workers to expose requests from a
window or worker).
On Thu, Aug 14, 2014 at 5:28 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Ben Maurer ben.mau...@gmail.com writes:
Another concrete example with img tags: sometimes an abusive user will
use a site like Facebook as a CDN -- they'll upload a picture and hotlink
it from elsewhere.
Hi,
Recently I have investigated memory usage of HTML video element in
several desktop browsers (firefox and chrome on windows and linux, and
IE 11), and have found some disappointing results:
1. A video element in a playable state consumes significant amount of
memory. For each playing or
On Tue, Aug 19, 2014 at 9:12 AM, duanyao duan...@ustc.edu wrote:
Hi,
Recently I have investigated memory usage of HTML video element in
several desktop browsers (firefox and chrome on windows and linux, and
IE 11), and have found some disappointing results:
1. A video element in a playable
于 2014年08月19日 16:00, Philip Jägenstedt 写道:
On Tue, Aug 19, 2014 at 9:12 AM, duanyao duan...@ustc.edu wrote:
Hi,
Recently I have investigated memory usage of HTML video element in
several desktop browsers (firefox and chrome on windows and linux, and
IE 11), and have found some disappointing
On Tue, 19 Aug 2014, at 08:41, Kornel Lesiński wrote:
WakeLock.request() expecting a string isn't very friendly to feature
detection.
I'd prefer if individual lock types were instances of objects, e.g.
navigator.*Lock objects could be instances of a variant of the WakeLock
interface:
On Tue, Aug 19, 2014 at 11:56 AM, duanyao duan...@ustc.edu wrote:
于 2014年08月19日 16:00, Philip Jägenstedt 写道:
On Tue, Aug 19, 2014 at 9:12 AM, duanyao duan...@ustc.edu wrote:
Hi,
Recently I have investigated memory usage of HTML video element in
several desktop browsers (firefox and chrome
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock is held indefinitely (until the
user leaves the page of course).
I.e.
On Wed, 08 May 2013 03:36:51 +0200, Jens O. Meiert j...@meiert.com wrote:
I understand the amount of space it takes. I still don't understand
what the
problem is. Is it that people look at the scrollbar and think oh wow
this
document is too long, I'm not gonna bother reading it at all.? Or
于 2014年08月19日 20:23, Philip Jägenstedt 写道:
On Tue, Aug 19, 2014 at 11:56 AM, duanyao duan...@ustc.edu wrote:
于 2014年08月19日 16:00, Philip Jägenstedt 写道:
On Tue, Aug 19, 2014 at 9:12 AM, duanyao duan...@ustc.edu wrote:
Hi,
Recently I have investigated memory usage of HTML video element in
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock
Tab Atkins Jr. jackalm...@gmail.com writes:
On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
[…]
Seems to me a declarative solution (like CSS) might be appropriate.
@media screen {
video:playing {
wake-lock: display 15s;
}
}
On August 19, 2014 at 11:16:19 AM, Nils Dagsson Moskopp
(n...@dieweltistgarnichtso.net) wrote:
Tab Atkins Jr. writes:
This solves the GC and locking issues (the latter by delegating state
management to CSS, which everyone already knows to use).
It would also make it easily possible to
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock
On Tue, Aug 19, 2014 at 11:07 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate
On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate DisplayWakeLock() and SystemWakeLock() classes.
Might make sense to do
On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres w...@marcosc.com wrote:
On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate
On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
Why is isHeld still used here? You don't need it to avoid squashing
someone else's lock with this design, and several people have
pointed out that exposing it is a footgun, as people might check it and
On Tue, Aug 19, 2014 at 1:44 PM, Marcos Caceres w...@marcosc.com wrote:
On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
Why is isHeld still used here? You don't need it to avoid squashing
someone else's lock with this design, and several people have
pointed out
On 06/26/2014 12:50 PM, Tobie Langel wrote:
On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote:
On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
Here's a first crack at a better spec:
Moved your text here:
https://github.com/whatwg/meta-brand-color
On Tue, Aug 19, 2014 at 6:52 PM, fantasai fantasai.li...@inkedblade.net wrote:
On 06/26/2014 12:50 PM, Tobie Langel wrote:
On Jun 26, 2014, at 21:20, Marcos Caceres w...@marcosc.com wrote:
On June 26, 2014 at 1:58:17 PM, Tab Atkins Jr. (jackalm...@gmail.com)
wrote:
Here's a first crack at a
21 matches
Mail list logo
