If you've ever tried styling form inputs then, like me, you probably just tweak their margins so they position nicely, and then go home and drink away the feeling of defeat. Styling most form elements is an incredibly difficult task. Trying to style file inputs across browsers, however, is virtually impossible.
I style a lot of forms while working on JIRA. I updated the visual styles for the Forms component within AUI (our common UI library), however I always had to ignore the file inputs. They stick out like a sore thumb amongst the other form elements.
There are many other workarounds, but most are quite dated and none of them met the requirements I had.
Say hello to Fancy File Input
It's accessible, i18n is easy, all states can be styled completely, it's all CSS-based so it looks beautiful on a HiDPI display, it plays well with other plugins, is maintainable (LESS, unit tests, grunt, bower), and as far as customisability is concerned … well … go take a look at the demos.
How to get it
You can either check out the source, or
bower install fancy-file-input (once this bower bug is fixed).
How to use it
It's very simple to use.
IE8, IE9, IE10, IE11, Firefox, Chrome, Safari, Opera, iOS6+, Android 3+, Windows Phone 8*
* the styling works, however Windows Phone 8 does not yet allow access to files, so they are effectively disabled.
I gave a lightning talk at SydJS in October about the difference between FastClick and FastActive. The demo gods were unkind and none of my demos worked on the night (a last-second refactor broke them).
I've improved the demos since then — try them out with your touch device of choice.
The essential difference is:
- FastClick is 8KB and reduces the actual delay when tapping a link
- FastActive is 0.45KB and instead reduces the perceived delay
Both solutions have their pros and cons. I'm going to stick with FastClick on my blog because the server hardware backing it (Amazon S3 + CloudFront) is fast enough to notice the difference. If, however, I was working on a project which wasn't just static content being loaded from a CDN, I'd definitely be weighing my options.
I've yearned to have a blog for a while now, however I'm an extremely lazy person. Simply thinking about the effort involved in having to keep the hosting server secure, whatever framework I used updated, and moderating comments for spam always turned me off.
Someone mentioned Jekyll on Twitter one day and it sounded perfect for me. Essentially it's a script which takes the content of your articles/pages (in markdown, HTML, etc) and merges them with templates you create and spits out flat HTML files. No framework required — just a server to host the files. Lazy Sean approved.
Before even writing a single line of code, I made a mental note of what my priorities were for the site:
- It needs to be accessible
- It needs to be fast
I nearly put being fast as the first point, however I realised I'd rather have a slow site that is accessible over a fast one that isn't. Also, being fast improves the user experience and can have a positive effect on how high your site is ranked in search results.
How to be fast
I love reading about little tips and tricks people use to optimise their sites. Because this is "just a blog", I decided there would be:
- no JS unless absolutely neccessary
- no reset styles
- as few requests as possible
- optimised for a cold cache — I'm guessing that most of my articles will be read on a mobile/tablet, from random Twitter posts, not recurring visitors
Not adding analytics JS was an easy call. Lazy Sean rightly said that if I have analytics I will need to keep an eye on them. If my articles are popular then I may hear about it on Twitter. That's good enough for me, and hey that's another request avoided (not to mention the occasional delays caused by GA).
Reset styles are great when you're creating a complex interface, especially if there are forms involved. The styles needed to render a blog post are minimal so I don't see the point of resetting the world and then setting the 15 or so styles I'd need.
Putting all my styles in the head rather than linking to an external file was another thing I debated. I may change my mind later but for the moment due to the fact the styles are only 5KB, and that I'm optimising for someone with a cold cache (and possibly on a 3G/4G connection), I figure it's less expensive to send them down with the page content than to fire off another request for them. I'm not sure what the packet size is for mobile data but I doubt sending down 10KB instead of 5KB will slow things down more than adding another request. Another request avoided.
Web fonts are all the rage but I get so annoyed when trying to read an article and the page hangs while fetching fonts from Google/Typekit/whatever. Stock fonts, while looking kinda average, are still readable and will work fine. More requests avoided.
Testing is important
After a bit of testing on mobile I realised I'd need to add FastClick.js or cop a 300ms delay whenever a link is clicked. I'd love it if other browsers added something like the proprietary
-ms-touch-action: none CSS property so JS wouldn't be needed, but until then FastClick will remain. Annoying but neccessary.
CDN all the things
I'd always thought a CDN would be expensive, but the pricing for services like Amazon CloudFront, Cloudflare, and Fastly are now much more affordable — at least when you're only hosting small html pages. I chose the Amazon stack mainly because I'm lazy and there are many well-written articles explaining how to set it up.
After a lot of fiddling I'm really happy with how it's turned out. Lazy Sean is pretty chuffed that all he needs to do is create an HTML file and then run a script.
As of the writing of this post, posts are loading in around 6-20ms, with the Load event firing shortly afterwards at around 70ms. It also gets full marks for both Desktop and Mobile from Google PageSpeed Insights, and all A's on WebPageTest.
As someone who does most of their blog reading on an iPhone while commuting, I love with how articles look. It's nothing fancy and I'd love to hear any (constructive) criticism people have.