dracos

I agree the tax-free childcare form could certainly be improved (I've even written a script to do the three-monthly reconfirmation for me, see my latest gist, though that's policy rather than tech!), but you can set up payments for the same day, you put today's date in (that is what I do; it gives a "You've asked for a payment of £x to be made to [site] today" extra confirmation step). There's nothing in the service manual page that says they couldn't enhance this form with a button as you're suggesting, and hopefully one day they will, though you're always actually worrying it could get worse...

Care to email and let me know which station you're talking about, and what the issue is? Haven't had any other mentions of this that I can see.

I’ve reworded that bit, sorry, it wasn’t very clear!

It is as krallja says; inlined on the very first request (so any caching headers such as ETag wouldn't help, though I do set them for anything subsequent) so there is no display blocking fetching the CSS needed for display (as I have little CSS, I inline all of it, but you might want critical CSS only).

I do think that credit card websites should implement card checksum, and what type of card it is (rather than asking you), if possible. I understand your points, but they do not change the fact that in this case a full server page refresh, possibly over a very slow/intermittent network, only to tell them something they could have been told instantly, is a poor user experience. Bad implementation, keeping in sync, or lacking server side validation, are bad developer practices just like having some of the page impossible to see without JavaScript. I think it is important to note that whilst my site works perfectly without any JavaScript, I am also a fan of using it where it helps the user.

Sorry to confuse, now fixed. Think I just predate all this standardization. I did mean KB (at least, that is what DevTools uses and from where I copied the figures :) ).

Yes, service workers would previously cap caching to 24 hours, see e.g. https://stackoverflow.com/questions/38843970/service-worker-... but as per the ticket mentioned there – https://github.com/w3c/ServiceWorker/issues/893 – they are moving to default no-cache, opt-in caching.

Just to note, though, that you can book tickets with Trainline, which you can't with traintimes.org.uk, it does have limits :) However, Trainline charge a booking fee – https://ehelp.thetrainline.com/app/answers/popup_detail/a_id... – and so I would suggest using any train operating company site (they all sell nearly all tickets), whichever one you find most agreeable.

Yes, the API returned in December 2010 and has been fine (from my PoV anyway) ever since.

It's OpenStreetMap: http://www.openstreetmap.org/

The code is on github ;) I only really have time to keep it running and e.g. move it to OSM, but pull requests always welcome.

No-one has minded for nearly three years, and TfL are the ones providing the data :-)

Thanks :-) I like to think they'd seen my original version, who knows, so don't mind my backport. Theirs was a bit snazzier, but far too empty for my liking!

It's more a work of art ;-) I basically show the data I get, but I don't fully understand it all - those Northern line trains all have a 477 id, which I think may be ghosts or tests or something else. Trains can jump lines if they're, for some reason or misparse, going straight from one station to another much further down the line.

A variety of reasons, including having to change stuff anyway for Google Maps v2 deprecation, preferring OSM's open model to Google with MapMaker, preferring Leaflet, and yes, possible cost too.

Thanks :-) It would definitely be good if the map could at some point highlight disruptions, or closed stations/lines, yes (along with other things it could show, such as trains at depots if we know where the depots are). Source is available at http://github.com/dracos/underground-live-map :)