This is brilliant technique by Remy!
If you’ve got a custom offline page that lists previously-visited pages (like I do on my site), you don’t have to choose between localStorage or IndexedDB—you can read the metadata straight from the HTML of the cached pages instead!
This seems forehead-smackingly obvious in hindsight. I’m totally stealing this.
- Obey the Law of Locality
- ABD: Anything But Dropdowns
- Pass the Squint Test
- Teach by example
Okay, I knew about the Python shortcut—I mentioned it in Going Offline—but I had no idea it was so easy to do the same thing for PHP. This is a bit of a revelation for me!
Once in the desired directory, run:
php -S localhost:2222Now you can go to “localhost:2222” in your browser, and if you have an index.html or .php file in your root directory, you’re in business.
Hui Jing describes her motivation for creating the lovely Penang Hokkien site:
People who grew up their whole lives in a community that spoke the same mother tongue as themselves would probably find this hard to relate to, but it really was something else to hear my mother tongue streaming out of the speakers of my computer.
She ends with an impassioned call for more local language websites:
If the Internet is meant to enhance the free flow of information and ideas across the world, then creation of content on the web should not largely be limited to English-speaking communities.
A clever use of localStorage to stop data from being lost when your visitors are offline.
A really deep dive into the lang attribute, and the :lang() pseudo-class (hitherto unknown to me). This is all proving really useful for a little side project I’m working on.
A directory of the regular science, technology, and creative events happening in Brighton.
My back-up strategy is similar to Brendan’s (using Super Duper and Backblaze):
In backup parlance there’s a thing called 3-2-1. That is, you should three copies of your files — two locally on different devices and one off site.
But I only do my local back-ups once a week (eek!)—I should do better.
A new webby meet-up in Brighton organised by Davs Howard. It’ll be one the first Thursday of the month at The Joker. I often find myself in The Joker on Thursday nights anyway (for the wings) so I’ll be heading along to the inaugural event on February 1st.
Practical advice from Ire on localising web pages.
Here’s the flow that eBay use for the font-loading. They’ve decided that on the very first page view, seeing a system font is an acceptable trade-off. I think that makes sense for their situation.
Interestingly, they set a flag for subsequent visits using localStorage rather than a cookie. I wonder why that is? For me, the ability to read cookies on the server as well as the client make them quite handy for situations like this.
Well, I guess it’s time to change all my locally-hosted sites from .dev domains to .test. Thanks, Google.
This looks like a useful tool, not just for testing locally-hosted sites (say, at a device lab), but also for making locally-hosted sites run on HTTPS so you can test service workers.
A write-up of the BrightSparks programme that Clearleft is taking part in.
Each company agreed to help support one local child from a low-income family, on free school meals or with a yearly household income of under £25k.
The website for Brighton’s astronomy meet up:
Every month we will have one or two talks aimed at beginners with an interest in learning more about astronomy, but assuming no prior knowledge.
Also, we will take our telescopes out to observe in and around Brighton on clear evenings - on the seafront, Hove and Preston Park, Devil’s Dyke and beyond.
A quick drag’n’drop way to base 64 encode your web fonts so you can stick ‘em in local storage.
A really handy bit of code from Aaron for building a robust file uploader. A way to make your web-based photo sharing more Instagrammy-clever.
Some very handy techniques for working with right-to-left text.
Yes, yes, yes! Karen drives home the difference between mobile and local (and there’s more about the myth of the mobile context).
If you’re making an argument for delivering different content to mobile users, or prioritizing content differently based on their context of use, stop for a minute and ask yourself if you mean local content. And if you do mean local content, then say that. Claiming that your travel example extends to cover the “mobile use case” leaves out millions of tasks and users.
Just to belabor this point: people use mobile devices in every location, in every context. Just because you know what type of device someone is using or where she is doesn’t tell you anything about her intention.
It took me a while to get my head ‘round it, but this routing service from 37 Signals is handy for testing local sites on multiple devices (kind of like showoff.io).