usage stats drop off.
On Mon, 23 Mar 2015 07:43 Garrett Smith dhtmlkitc...@gmail.com wrote:
On 3/21/15, Jake Archibald jaffathec...@gmail.com wrote:
I'd rather we did that by introducing promises to HTMLCanvasElement.
Returning a promise from toBlob is easy, making the callback arg optional
Which is why more browsers shouldn't adopt it. If we have an opportunity to
switch it for a promise-based API, we should take it.
On Mon, 23 Mar 2015 at 17:21 Garrett Smith dhtmlkitc...@gmail.com wrote:
On 3/23/15, Jake Archibald jaffathec...@gmail.com wrote:
I'd rather Firefox did a small
On Sat, 21 Mar 2015 at 18:16 Rik Cabanier caban...@gmail.com wrote:
Justin is worried that in order to make this asynchronous, Chrome has to
create a snapshot of the canvas bits which is slow if it resides on the GPU.
Of course, his workaround to use getImageData is just as slow since it has
I'd rather we did that by introducing promises to HTMLCanvasElement.
Returning a promise from toBlob is easy, making the callback arg optional
by checking the type of the first arg is hacky but possible (and is done in
js libs).
On Sat, 21 Mar 2015 10:56 Robert O'Callahan rob...@ocallahan.org
Usecase:
Receiving a push message results in a 'push' event within the
ServiceWorker. The likely action at this point is to show a notification.
It should be possible to generate an image to use as an icon for this
notification (
On 24 September 2014 01:21, Jonas Sicking jo...@sicking.cc wrote:
* Notifications that close when a page goes away does not seem useful
on mobile, but could be useful on desktop to enable minimized
applications, or applications whose window is covered by other
windows, call attention to
On 22 August 2014 07:20, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Aug 22, 2014 at 12:27 AM, James Graham ja...@hoppipolla.co.uk
wrote:
I think that adding an extra verb to the names to describe a consistent
feature of the API is a mistake; it seems important when designing the
On 5 August 2014 16:30, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Aug 5, 2014 at 5:04 PM, Peter Beverloo bever...@google.com
wrote:
On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren ann...@annevk.nl
wrote:
Is that available within a service worker?
It would be reasonable to
Over in ServiceWorkerLand we've been getting stuck on the interaction
between methods that read a request/response body and the underlying stream.
The question was Should methods that read the body consume it, meaning
nothing else can read it?
On 21 August 2014 13:27, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Aug 21, 2014 at 11:02 AM, Jake Archibald jaffathec...@gmail.com
wrote:
* The as* methods should be directly on the response, and named
consumeAs*,
so response.consumeAsJSON()
Would it be really bad to have
2014 18:27, Jake Archibald jaffathec...@gmail.com wrote:
On 21 August 2014 13:27, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Aug 21, 2014 at 11:02 AM, Jake Archibald jaffathec...@gmail.com
wrote:
* The as* methods should be directly on the response, and named
consumeAs*,
so
On 14 July 2014 17:17, Domenic Denicola dome...@domenicdenicola.com wrote:
From: Juan Ignacio Dopazo jdop...@yahoo-inc.com
I agree that Node's design sounds a bit better for piping. But where
would you put the FetchResponseBodyStream? fetch() returns a promise for a
Response. Why would the
On 25 June 2014 04:50, Anne van Kesteren ann...@annevk.nl wrote:
Do we want to keep that tradition and have both asFormData() and
asURLSearchParams() or should we embed some smarts in the asFormData()
algorithm? (FormData is basically a more general URLSearchParams as it
can handle Blob/File
On 25 June 2014 08:17, Domenic Denicola dome...@domenicdenicola.com wrote:
Hmm. To clarify, this is in case the server sends you
application/x-www-form-urlencoded data, and you want to then get it in a
format that can easily become a mutable query string or form data object?
If so, neither
On 18 June 2014 11:08, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jun 16, 2014 at 6:57 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
var doesFetchSupportJson = function () {
return fetch(data:application/json;base64,e30=).then(function
(response) {
return
On 19 June 2014 12:56, Jake Archibald jaffathec...@gmail.com wrote:
Good point.
toJSON
toText
toBlob
toArrayBuffer
…works for me.
Ah yes, the toJSON clash (thanks Tobie).
asJSON
asText
asBlob
asArrayBuffer
Thanks, updated my code examples to reflect this
On 14 March 2014 23:57, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/14/14 6:04 PM, Jake Archibald wrote:
Any guarantees of ordering if fully cached?
I believe no.
-Boris
On 15 March 2014 00:31, Kyle Simpson get...@gmail.com wrote:
I'd say the first syntax is a bit verbose for what I was dreaming 4 years
ago when I started asking for a simple script preloading mechanism, but
it's just this side of acceptable. If we have to take the second approach,
I say
On 15 March 2014 00:35, Kyle Simpson get...@gmail.com wrote:
there's a seemingly implicit requirement that we have to get both ES6
promises and DOM promises to land for these suggested approaches to work.
ES6 promises are already in Chrome stable, they're on the route to stable
in Firefox.
on existence of particular element before executing
script
Solution: Either put the script that handles script loading after the
element in question, or use mutation observers
Cheers,
Jake.
On 12 March 2014 14:27, Jake Archibald jaffathec...@gmail.com wrote:
On 12 March 2014 14:17, Domenic Denicola
On 14 March 2014 20:10, Kyle Simpson get...@gmail.com wrote:
Is link rel=preload going to fire this loaded event after it finishes
pre-loading but BEFORE it executes (or, rather, BEFORE because it doesn't
execute them at all)?
link rel=preload doesn't execute (you can use it to preload
On 14 March 2014 21:05, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/14/14 5:03 PM, Jake Archibald wrote:
Do you know what browsers do with a fully cached script?
script src=url is always executed async when inserted into the DOM,
cached or not.
Any guarantees of ordering if fully cached
One of the problems with async scripting is doing something when/if it's
ready. A complete solution looks like this
https://gist.github.com/jakearchibald/7662e012462c7537a075, it would be a
lot easier if we could just do:
thing.loaded().then(function() {
console.log('loaded');
}, function() {
On 12 March 2014 13:15, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/12/14 7:23 AM, Jake Archibald wrote:
== img/link/script/document/iframe .loaded() ==
If the element hasn't loaded or is loading, vend a promise that
resolves/rejects on its load/error event.
If the element has fired load
On 12 March 2014 14:17, Domenic Denicola dome...@domenicdenicola.comwrote:
var img = document.createElement(img);
var promise1 = img.loaded();
img.src = foo.png;
var promise2 = img.loaded();
// (1) will promise1 be immediately fulfilled, since img has about:blank
or similar loaded already?
I like this, also provides hooks for something like
form.requestAutocomplete to do one-click account creation, along with
password generation.
On 5 Mar 2014 20:39, Edward O'Connor eocon...@apple.com wrote:
Hi,
Ian wrote, in 2012:
This might fall under the broader class of identity-related
The registration of a Service Worker is currently only possible via DOM
call from an HTML document, so it makes sense for registration to be
governed by CSP.
There was some discussion here
https://github.com/slightlyoff/ServiceWorker/issues/46
So script-src would cover registration, but there
On 26 September 2013 14:57, Jake Archibald jaffathec...@gmail.com wrote:
Note, this only covers registration. If http://example.com allows
controllers from http://example.co.uk, and successfully calls
registerServiceWorker(/*, http://example.co.uk/service.js;), that
controller will be used
On 31 August 2013 00:04, Ryosuke Niwa rn...@apple.com wrote:
It'll be much harder to implement a new dependency API that replies on CSS
selectors if we care about the performance at all.
Where does the performance issue come from? It would only need to be
resolved once on node creation or
On 28 August 2013 14:32, Anne van Kesteren ann...@annevk.nl wrote:
* Using a sub-scheme (zip) with a zip-path (after !):
zip:http://www.example.org/zip!image.gif
* Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif
* Using media fragments:
. Or is that in the doc I'm just
not getting my head around it?
It'd be great if modules can solve these but also give the UA all the
requirements up front (or maybe that's the job of HTTP2).
On Wed, 10 Jul 2013, Jake Archibald wrote:
If dependencies took a CSS selector it could be:
script dependencies
On 18 July 2013 23:28, Kyle Simpson get...@gmail.com wrote:
About a week ago, I presented a set of code comparing the script
dependencies=.. approach to the script preload approach, as far as
creating generalized script loaders.
There were a number of concerns presented in those code
On 12 July 2013 20:12, Ian Hickson i...@hixie.ch wrote:
On Fri, 5 Apr 2013, Jake Archibald wrote:
Been reading the steps for image downloading -
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data
...
Unless I'm reading it wrong
http://url.spec.whatwg.org/
How would I create a URL relative to the page, but taking into account
base (and anything else that may affect relative urls on the page)?
It feels like the 2nd constructor parameter should default to the page's
base url, and you could pass window.location.href in if
On Wednesday, 10 July 2013, Kyle Simpson wrote:
You know, I keep relying on the fact that the body of work on this topic for
almost 3 years … I've spent more time over the last 4+ years obsessing on
script loading than any other developer … I am saying the same things I've
been saying for
On 10 July 2013 17:37, Jake Archibald jaffathec...@gmail.com wrote:
On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote:
I personally don't care about scripts being discoverable by pre-parsers. I
have done testing and am not convinced that something appearing earlier (in
markup) leads
On 11 July 2013 15:59, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jul 11, 2013 at 7:56 AM, Jake Archibald jaffathec...@gmail.com
wrote:
http://url.spec.whatwg.org/
How would I create a URL relative to the page, but taking into account
base (and anything else that may affect relative
On 9 July 2013 20:39, Ian Hickson i...@hixie.ch wrote:
1. Add a dependencies attribute to script that can point to other
scripts to indicate that execution of this script should be delayed
until all other scripts that are (a) earlier in the tree order and (b)
identified by this
On 9 July 2013 21:41, Kyle Simpson get...@gmail.com wrote:
http://wiki.whatwg.org/wiki/Script_Execution_Control
My proposal was to standardize what IE4-10 did, which is to start loading
a script even if it's not in the DOM, but not execute it until it's in the
DOM. Then, you monitor an event
On 9 July 2013 22:31, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 7/9/13, Ian Hickson i...@hixie.ch wrote:script id=jquery
src=jquery.js async/script
script id=shims src=shims.js async/script
script dependencies=shims jquery src=myscript.js
async/script
Why limit depends
On 10 July 2013 11:31, Bruno Racineux br...@hexanet.net wrote:
Anyway, as per your previous email I think we mostly agree that solution
#1 is not very practical (or infeasible per your word)
Given the suggestions I made to #1 in
On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote:
The IE4-10 technique is invisible to pre-parsers, if we're chasing
performance here it's not good enough.
...
Also invisible to preloaders.
I personally don't care about scripts being discoverable by pre-parsers. I
have done
Been reading the steps for image downloading -
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data
As far as I can tell:
Step 12 If selected source is null is the only step where an error
event can be fired and abort before step 14.
Step 14
43 matches
Mail list logo
