HTML5 Poker cheat sheet: a web app
Towards the end of my degree, me and my housemates used to play a fair amount of Poker — no- or low-stakes, with the emphasis mainly on beer. Over the last few years I hadn’t really played at all — I don’t get any enjoyment from playing online or against a computer, and as far as I’m concerned it’s a game that can only really be enjoyed with friends. Following a recent reminder of why it’s such a great game (during a stag party in Swansea) I was inspired to get a regular night going with some mates, and for the last month or so we’ve been sitting down for some cards once a week (there’s still an emphasis on beer).
During college, we had a rather dog-eared crib sheet sitting around at all times — basically just a printout of a PDF with explanations of the hands from best to worst. Plenty of people who came round to play had never played before, or just weren’t confident enough that they could remember the right order. When I started inviting folk round recently, I knew that it’d be useful to have one handy — although in our post-printer household, I downloaded the PDF to my iPad’s Dropbox and left it up on screen. It didn’t take long to realise that a nice looking, readable HTML5 version would be a great little side project to keep my occupied for an evening. So I built one.
The Cheat Sheet
The cheat sheet was always going to be pretty straightforward — a list of possible hands, from Royal Flush to high card. Obviously this doesn’t need anything too fancy — the aim is for a novice player to be able to glance quickly at the list to ascertain the relative strength of their hand without giving anything away. I built it with the onscreen dimensions of an iPad web app (1004x768px, allowing for the 20px status bar at the top) in mind, as this was where I was planning to use it — although obviously it was designed to look fine on any web-capable device. The visuals design was a fairly straightforward idea based on casino tables — the felt background texture is actually taken from my own card table, photographed and then beaten into a seamless pattern in Photoshop!
Marking up the hands was a great little exercise in semantic HTML (if enjoying that is wrong, I’m glad I’m not right). My original plan was to use small versions of my illustrated playing cards for the examples, but it quickly became obvious that this was the wrong method — too many graphics, and not instantly readable enough. I was really pleased with the final iteration of the cards, which are generated entirely with four graphics (one for each suit) and a bit of CSS to beat the full content into graphical form. The whole page works just as well without any graphics or styling, which I usually take as a sign that the markup was right in the first place!
For those interested in the HTML5 side of things I should point out that on release, I had marked up the two main areas of content as <section>s, and the individual summaries for each hand as <article>s. I reversed this recently, having just finished reading through Introducing HTML5 by messrs. Lawson and Sharp, which made the point that <article> refers to discrete, self-contained areas of content, while <section> applies to content which needs grouping for context (incidentally, the book is well worth owning if you work with HTML5 at all — I wish I’d had it when I built this app).
The chip calculator
The app lets you set various details, including the amount of chips in your set (and the values you’re assigning to each colour), the number of players who are joining you (plus any extra buy-ins you’d like to hold back) and so on. It then divides the available chips up based on this, as well as letting you know the value this represents. If you want players to have less chips (for example, if you want a shorter game) you can also set the maximum total lower. You can also tell it how much it costs to buy-in — it calculates how much in real money each chip is worth, to give players a bit of much-needed real-world context!
The app is also persistent thanks to a small local storage script which runs every time you update anything. This means that you should be able to set it up for your own purposes once — then you just have to change specific details (like number of players) when you next come back to it. Although this would have been possible with cookies, it’s an unbelievable amount more straightforward with local storage — I could have saved every variable separately, but in the end it seemed quicker and more convenient to use JSON.stringify to convert my data object to a string and store it as a single value.
Opera hates graphic designers
Okay, so that’s a scandalous lie, but it’s a scandalous lie which nicely illustrates the one major problem I ran into with the chip calculator and HTML5. All of the input fields on the form have the shiny new HTML5 type attribute of number — which makes sense, as the required input for any given one is a number. Aside from the semantics, there’s also the fact that iOS devices bring up a numeric keyboard for this input type — which is extremely helpful. Aside from Opera, no other browser currently supports the number attribute, so just default to ordinary text inputs.
Unfortunately, Opera is hell of clever when it comes to these new HTML5 input types — the above shows how that browser handles this. From what I can tell, there’s no way to reign in or override these form controls either, save for giving up and using a text field in place (I could be wrong, but I certainly didn’t find a way). In fact, in the book mentioned above, Bruce Lawson points out that not being able to overstyle form elements is a feature, not a bug:
— Introducing HTML5 (chapter 3)
“ Although it’s tempting to style the stuffing out of your form fields... whatever your branding people say, it’s better to leave forms as close to the browser’s default as possible. ”
Although I definitely see his point — I’m old enough to remember when scrollbars were regularly unrecognisable (and often purple) — in this case the difference between browser’s implementations makes life pretty difficult. Not to mention that for some (if not all) of these particular fields, the ‘step’ values aren’t terribly useful — who knows what huge or small numbers players are going to be throwing around in there.
Look mum, no network
One thing that I had worked with before that I knew would definitely feature in this project was offline caching. It’s particularly handy for iOS devices, as it allows you to save the site to your home screen, and then run it as a stand-alone app with or without network connectivity. I’d already used it to create a set of portfolio mini-apps for my iPad, and it’s pretty easy to set up, although it can be a bit temperamental to debug — I’d definitely recommend adding appcaching as the last stage of your project. You could quite easily write a server-side script to automatically update the cache manifest whenever you make changes to your site or app, although I used a static manifest for this project.
Originally, I was planning to take the lazy option and leave the site as is for mobile devices, but (fortunately, in the long run) there turned out to be a huge problem with that. The Safari reference has this to say on the subject of viewport settings for web apps:
“ Apple recommends that you set the width to device-width so that the scale is 1.0 in portrait orientation and the viewport is not resized when the user changes to landscape orientation. ”
Very reasonable! However, what the documentation doesn’t mention is that since iOS4, Apple seem to be enforcing this recommendation — zoom and viewport settings work as you’d expect when you’re viewing the site in vanilla Safari, but are completely ignored once the app is saved to the home screen. Not sure if this is a bug or a feature, to be honest — but it meant the app as designed for the iPad was pretty much unusable. A small-screen media query fixed that, serving a second stylesheet which totally rearranges the layout for mobile devices.
Which, let’s face it, is what I should have been doing in the first place.
Although I built this as a learning project (and to make my own poker games a little simpler) I hope some of you find it handy. If you have any feedback or suggestions (or bug reports, come to think of it) please don’t hesitate to get in touch.