On 2014-05-23 06:53, Michael Heuberger wrote:
Hi James
Single page apps!
These become more and more popular with frameworks like RactiveJS or
AngularJS. There the first request is a HTTP request, for any subsequent
requests an AJAX one is generated. The problem is the first HTTP
AJAX
Hi Julian
Yes, with AJAX requests I meant using XMLHTTPRequest.
If the initial page load yields a 404 will there be any scripts to
execute at all?
Oh yes, absolutely. Have you ever written a single page app? There is
lots of logic to execute when a 404 occurs. I could count plenty of use
- Notify the administrator about a 404 by email with a response back to
the server
But the server already knows about the 404, JS shouldn’t be needed/used to
re-inform the server of the status it’s already sent.
- Display a beautiful 404 page and hide parts of the navigation
- Reveal
Good points Mat
In theory you have good points but in the real world it is more
complicated than that. See my comments below:
On 23/05/14 19:49, Mat Carey wrote:
- Notify the administrator about a 404 by email with a response back to
the server
But the server already knows about the 404, JS
I had to deal with this on a script created IMG element the other day. I
used onerror to deal with it.
For xmlhttprequest you can use the status field.
Why is that not enough?
Silvia.
On 23 May 2014 18:06, Michael Heuberger
michael.heuber...@binarykitchen.com wrote:
Good points Mat
In
On Thu, May 22, 2014 at 4:09 PM, Rik Cabanier caban...@gmail.com wrote:
Well, the issue with not having a standardized intermediate colorspace, is
that output will look different on different devices.
I theory, that should only be the case when drawing raw values through
putImageData.
I think he wants to be able to serve the exact same single page no matter
what the status code is (i.e. including `404`s) and then be able to react
to the initial page status code on the client-side.
A bit of an edge case as most people serve different pages with HTTP errors
but it is a logical
When is it safe for a user agent to garbage collect a BroadcastChannel instance?
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts
Given that another document might create a new BroadcastChannel
instance at any time, the
When is it safe for a user agent to garbage collect a BroadcastChannel
instance?
When there's no direct reference to the object and no onmessage handler
attached to it. (?)
On Fri, May 23, 2014 at 5:23 PM, Adam Barth w...@adambarth.com wrote:
When is it safe for a user agent to garbage
On Fri, May 23, 2014 at 5:54 PM, Michael Nordman micha...@google.com wrote:
When is it safe for a user agent to garbage collect a BroadcastChannel
instance?
When there's no direct reference to the object and no onmessage handler
attached to it. (?)
That doesn't play nicely with anonymous
Hi Silvia
Yes, I know this trick but in my opinion it's a waste of bandwidth (a
small one I know but multiply this with thousands of calls worldwide
every hour ...)
If we could obtain the status code from the first, raw HTTP request,
then there is no need for this IMG trick anymore.
Michael
On
On Fri, May 23, 2014 at 5:23 PM, Adam Barth w...@adambarth.com wrote:
When is it safe for a user agent to garbage collect a BroadcastChannel
instance?
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts
Given that another
12 matches
Mail list logo
