That is unkind.
That is unkind.
We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities.
Going to Chicago. brb
Ah, I see. Sounds like a shitty app. Or maybe it’s a shitty iOS-level sharing thing.
When I was writing about the lie-fi strategy I’ve added to adactio.com, I finished with this thought:
What I’d really like is some way to know—on the client side—whether or not the currently-loaded page came from a cache or from a network. Then I could add some kind of interface element that says, “Hey, this page might be stale—click here if you want to check for a fresher version.”
Trys heard my plea, and came up with a very clever technique to alter the HTML of a page when it’s put into a cache.
It’s a function that reads the response body stream in, returning a new stream. Whilst reading the stream, it searches for the character codes that make up:
<html. If it finds them, it tacks on a
But then I was discussing this issue with Tantek and Aaron late one night after Indie Web Camp Düsseldorf. I realised that I might have another potential solution that doesn’t involve the service worker at all.
Caveat: this will only work for pages that have some kind of server-side generation. This won’t work for static sites.
In my case, pages are generated by PHP. I’m not doing a database lookup every time you request a page—I’ve got a server-side cache of posts, for example—but there is a little bit of assembly done for every request: get the header from here; get the main content from over there; get the footer; put them all together into a single page and serve that up.
I’ve published the code as a gist.
script element on each page, I have this bit of coducken:
var serverTimestamp = <?php echo time(); ?>;
serverTimestamp holds the timestamp that the page was generated. When the page is put in the cache, this won’t change. This number should be the number of seconds since January 1st, 1970 in the UTC timezone (that’s what my server’s timezone is set to).
Date object, I use a caravan of methods like
getTime() to end up with a variable called
clientTimestamp. This will give the current number of seconds since January 1st, 1970, regardless of whether the page is coming from the server or from the cache.
var localDate = new Date(); var localUTCString = localDate.toUTCString(); var UTCDate = new Date(localUTCString); var clientTimestamp = UTCDate.getTime() / 1000;
Then I compare the two and see if there’s a discrepency greater than five minutes:
if (clientTimestamp - serverTimestamp > (60 * 5))
If there is, then I inject some markup into the page, telling the reader that this page might be stale:
The reader has the option to refresh the page or dismiss the message.
It’s not foolproof by any means. If the visitor’s computer has their clock set weirdly, then the comparison might return a false positive every time. Still, I thought that using UTC might be a safer bet.
All in all, I think this is a pretty good method for detecting if a page is being served from a cache. Remember, the goal here is not to determine if the user is offline—for that, there’s
The upshot is this: if you visit my site with a crappy internet connection (lie-fi), then after three seconds you may be served with a cached version of the page you’re requesting (if you visited that page previously). If that happens, you’ll now also be presented with a little message telling you that the page isn’t fresh. Then it’s up to you whether you want to have another go.
I like the way that this puts control back into the hands of the user.
Looking at the schedule for @ParisWeb this October, I think I’m in the René Descartes room, therefore I am in the René Descartes room.
I have a feeling I’m going to spend the next month starting every conversation with “So have you seen that great CSS Tricks article by @CassieCodes?”