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...
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.
If I typo the card number and there's no JS code to tell me that, I need to submit the form, wait for it to error out, have to re-enter all the billing address information, re-enter the card number, and try this whole process again. I've resorted to re-typing the card number in the "find" box and making sure that it matches the number in the form's field, just to avoid this crap.
A handful of lines of JS that runs the Luhn checksum on the number in the "credit card number" field is not at all CPU intensive and can save people from such data entry errors.
>
zkms 10 hours ago | parent | on: Performance notes
If I typo the card number and there's no JS code to tell me that, I need to submit the form, wait for it to error out, have to re-enter all the billing address information, re-enter the card number, and try this whole process again. I've resorted to re-typing the card number in the "find" box and making sure that it matches the number in the form's field, just to avoid this crap.
That doesn't necessarily have to be the case. If done correctly, the page could come back with errors and the form already filled out. If the connection is secure enough to fill out the form - it must be secure enough to return your data you entered.
FYI, I'm playing devil's advocate here a bit to see how far you can push this.
I think javascript is a nice addition to client side validation of forms, but it must not impact how they use the system. Having a piece of JS run and not allow me to submit a form is really terrible design, especially when the validation it is doing is running incorrectly.
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 :) ).
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.
