By Melinda Szasz

HTML5 & CSS3 for the Real World!

By Melinda Szasz

After more than five months of preparation, and countless weeks spent on research, writing, and editing by the wonderful authors and publishing team – we’re finally ready to unleash the awesomeness that is HTML5 & CSS3 for the Real World.

As the newest book to be added to the prestigious SitePoint library, HTML5 & CSS3 for the Real World is what you’ve been waiting for.

You might assume that the person writing this blog post is a designer or a front-end developer, at the forefront of these new technologies? Well, that’s not the case.

I have a confession. I’m not a techie and I know nothing about code.

Yes, I work at SitePoint and have copied and pasted my way through creating a few HTML emails, but that’s about as far as my skills go. So, why am I writing this introduction if I don’t know anything about HTML5 & CSS3?

Because rarely does something this big come along that shakes the foundations of web development and affects everything in its path. Even for the likes of me.

This book has caused a huge stir in our offices. The buzz is unmistakable. There is something seriously cool about HTML5 & CSS3.

I know it, and you know it — HTML5 & CSS3 will change the way designers and developers work for the better.

And that, my friends, is a big deal.

One of our designers explained it beautifully when he said, “We’ve been locked in, trying to get petty tasks done with so much effort. HTML5 & CSS3 allows me to finally do cool stuff and have some fun”.

Well, that sounds pretty amazing to me.

For only $17, you can grab the digital version of this book to read on any of your tablets or devices! Available in EPUB, MOBI or PDF.

Learn more and grab your copy of this new title today.

  • Reini

    Why is the sample PDF not sent to me? I already requested the link with 2 different Email adresses?
    Regards, Reini

    • Melinda Szasz

      Hi Reini,

      Have you checked your junk folder?

      Send me an email at and i will send sort this out for you.


  • Alexis Goldstein

    To get a look at two of the JavaScript APIs discussed at length in the book, you can take a look at my two earlier blogs: and

    Hope you enjoy the book! I enjoyed contributing to it!

  • Jess

    When will this be in bookstores?

    • Melinda Szasz

      Hello Jess,

      It will probably hit shelves in a week or two.

      We’ve got some in stock right now if you would like one earlier.


      • Jess

        Thanks so much, Melinda! Like another poster, I’m also having trouble with the sample .pdf. My request does not seem to have worked. Thanks!

  • John

    I really don’t want to rain on the parade, but this post is incredibly misguided.

    The blurb for the book tells us that we can use HTML5 to create future-proof websites, which is a thoroughly meaningless statement. Future-proofing is not an issue. New browsers are going to continue to support older versions of HTML for decades. The problem with HTML5 is past-proofing. Older browsers have no support for HTML5 elements, and new browsers are inconsistent with the features they do implement. We still have to contend with IE6 – support for new HTML5 / CSS3 features will not be widespread for a very, very long time.

    Yeah, you can hack some of the new HTML5 tags into old browsers using JavaScript, that isn’t really the point. They didn’t decide to create HTML5 so we could change all our tags to tags. The exciting features are localStorage and video, neither of which will ever function in older browsers. Nor will the new canvas tools. The best bits of the specification will only ever work in newer browsers. CSS3 is a little better off, but not much.

    Another problem is that the specification is not yet complete, and wont be for years. They’re still fighting over video codecs. It seems pretty silly to develop sites to a specification when there’s a decent chance that specification will be altered somewhere down the line.

    Anyone working on a business website is going to stick with HTML 4.01 because it is a stable standard with almost universal support from browsers. It is capable of doing pretty much everything HTML5 can (if in a slightly less elegant way) and the end user is never going to notice the difference.
    HTML5 and CSS3 allow you to achieve cool things with little effort, yeah, but they’re only going to work for about 30% of your visitors. HTML5 wont be much more than a toy for developers to experiment with for a long time, and it will be years before it starts being used for serious business applications.

    • Louis Lazaris

      John, everything that was valid in HTML4, is now valid in HTML5, so there is no reason for any developer not to start using HTML5-based markup, and gradually start adding new things with each project, depending on the situation.

      An HTML5-doctype *alone* is enough to future-proof a website (to some degree), because that doctype will never change again.

      The book doesn’t endorse going crazy on every project with various new features, but helps developers gain a balanced approach that will allow them to start using as much as they feel comfortable with, while learning some less-supported stuff that they can use later on when browser support increases.

      • John

        Okay. Well you’re right, you can switch to a HTML5 doctype and still have your code work just the same, but I’m not sure why you would unless you were actually using HTML5 features. Simply slapping a HTML5 doctype on a HTML4 page provides no benefit (and is arguably detrimental), and you certainly don’t need a book to tell you how to do it.

        I object to this notion of “future-proofing”, as if we’re going to wake up one day to find that browsers have suddenly stopped supporting HTML4. Browsers will never drop HTML4 support. The idea that we need to switch to a HTML5 doctype or risk having our sites stop working is completely absurd. Future-proofing is an imaginary concept dreamed up to give people an extra reason to justify promoting HTML5.

        Don’t get me wrong, I’m not adverse to the idea of HTML5. I would be thrilled to be able to start using HTML5 and CSS3 today, but they lack sufficient support. The problem with web development is that a huge number of users cannot or will not upgrade their browsers. Currently, HTML5 lacks sufficient support to make it worthwhile. Even just to use the basic tags requires hacking it together with JavaScript if you want to support older browsers, and it will take years before HTML5 browser penetration reaches decent levels.

        Of course there is no problem with having a HTML5 / CSS3 book for developers who want to be ready when the technologies do become viable, or who want to create sites that take advantage of HTML5 regardless of browser support. I just think it’s disingenuous to say that you can easily use HTML5 features without any “tricky hacks or workarounds”, and using the fictional idea of “future-proofing” websites as a selling point is a cheap, dishonest marketing technique. As a SitePoint customer (I own several SitePoint books, and they’re all excellent), I am very disappointed to see them stoop to this level.

      • Louis Simoneau

        @John I completely disagree :) Lack of widespread support is in no way a reason to not start using some of the HTML5 and CSS3 features now—simply because, when used carefully, they degrade gracefully and often don’t even require any additional dev time.

        A few examples: 1) input types. HTML5 input types degrade to plain text fields in nonsupporting browsers, so you can start using them and getting the benefits of native inputs and validation on supporting browsers without any detriment to the rest of your users.
        2) CSS3 decorations (border-radius, text-shadow, box-shadow, gradients). Some might disagree, but I think a lot of us feel that using JavaScript, superfluous markup, or images for decorative elements is a pretty dirty “hack”. With CSS3, you can layer the “fancy stuff” on for new browsers, while still providing a perfectly usable experience to old browsers. And, to the argument that that won’t fly with clients, I point to
        3) Audio/video. It’s easy to put in fallback flash content using the same encoded source, so you can provide HTML media to modern browsers and degrade gracefully on older ones.
        4) Nearly everything else. Huge amounts of what’s in HTML5 and CSS3 are things we’re doing anyway with JavaScript. The best way to future-proof, though, is to rely on the native functionality for supporting browsers, and load in those exact same JavaScript solutions as polyfills for non-supporting browsers. That way, over time, more and more users will be bypassing the workaround JS hacks and relying on faster, more familiar native browser support.
        5) The rest. Even for things that can’t be polyfilled, like localStorage and canvas, to pick just the ones you brought up, support is increasing rapidly. localStorage is supported on all modern browsers and IE8+, canvas on all modern browsers and IE9+.
        6) Not to mention mobile. With extremely good support for HTML5 and CSS3, including the new JS APIs, on most new-generation mobile devices, there’s even *less* reason not to start using this stuff when working on mobile sites.

        Your point that “anyone working on a business website is going to stick with HTML 4.01” just doesn’t fly, in my opinion.

        I realize that HTML5 and CSS3 have been the subjects of a lot of buzz in the industry, and it’s normal to be skeptical of anything that comes with a lot of hype. I also understand that a lot of designers and developers have become really comfortable with the way they work, since the browser and spec landscape has been so quiet for the past 10-ish years. But I really do think this is another one of those times (like the original shift from tables to CSS layouts) where as an industry we’re going to have to learn some new skills and start pushing things forward.

      • Louis Lazaris

        John, I think you’re misunderstanding a couple of things.

        First of all, technically speaking, the simple “HTML5 doctype” is not really an HTML5 doctype — it’s an HTML doctype. It’s universal. It no longer is reserved for a single style of markup or syntax. It’s the future-proof doctype that ensures all past and future content (that is in line with the spec) will be valid. That same doctype will apply to all future markup.

        Second of all, when SitePoint’s marketing copy describes the fact that we should use HTML5 and CSS3 to avoid “tricky hacks or workarounds”, they are referring to things like rounded corners and gradients (to give two simple examples). In the past, to create either of those two things, you needed “tricky hacks or workarounds” (extra images, extra markup, or extra scripts). This is no longer necessary with CSS3. No, it’s not supported by all in-use browsers, but that doesn’t mean their statement is false or misleading. Everyone agrees this is one of the great benefits of CSS3.

        Also, when you say that it’s problematic to use JavaScript to enable the new semantic elements, and thus it shouldn’t be used, you’re basically disagreeing with Bruce Lawson, Remy Sharp, Jeffrey Zeldman, Paul Irish, Chris Coyier, Andy Clarke, Jeremy Keith, Mark Pilgrim, Dan Cederholm, and hundreds of other well-known standards proponents and experienced developers, all of whom believe that it’s okay to start using these technologies today.

        Not that I think everything those people say is gold; I disagree with some of those guys quite often, but in this case, it’s virtually unanimous, so it’s not entirely prudent to disagree here, unless you have compelling reasons.

        You might not know this but there were many people in the early 2000s that thought certain people were crazy for pushing CSS layouts. Those doubters continued using table layouts instead — and we all know what happened there.

        Nonetheless, I do appreciate you expressing yourself here, and I don’t blame you for having doubts about these technologies being useful today. I don’t love the situation we’re in browser-wise, but if we don’t move ahead, then we’ll be stuck creating IE8-only websites for another 5 years, and that would just be wrong.

        I suggest you download the sample chapters, which you can get here, if you haven’t done so already. You can read all of chapter one, which discusses the reasons it’s best to start using HTML5 and CSS3 today. If you still don’t like our reasons for promoting these technologies, then we’ll agree to disagree. :)

      • John

        I thought I’d get some strong opposition to these posts :)

        So, Louis Simoneau:

        I’m aware that you can do all of these things. But it isn’t like these are perfect solutions. In response to your examples: 1) Yes, you can use HTML5 input types which will degrade nicely in older browsers. But that just adds an extra layer of headaches. If you want to validate your inputs, you’re going to have to do it with JS anyway to support those older browsers. So now you have two methods of validation to keep up with – HTML5 attributes, and your JS validation. Since you’re going to have to write the JS anyway for older browsers, why not just use it for every browser? It’s easier to maintain that way, and achieves the same result.

        2) I don’t disagree on this one. In fact I do use CCS3 where I can, although some clients do insist on having a consistent appearance across all browsers. If it wasn’t for those client restrictions, I would happily use CSS3 progressive enhancement on all my sites.

        3) Yes, but now you’re having to test to see if <video> tags are supported, and serve up different content to different users. Which isn’t a huge deal, but it is an extra step you have to think about during development.

        4) Yes and no. As a general rule, if something already works in JS in a non-hacky way, I don’t see the point in using HTML5 / CSS3 to do it. Sure, you can use all your nice new features to do stuff and have JS act as a polyfill, but then you just end up with twice as much code to maintain – the HTML5/CSS3, and the JS. You still have to write the JS anyway for older browsers, so why not just serve it up to everyone? It just seems easier that way.

        5) At least 10% of people still use IE7, and IE6 is only just reaching the point where it can be ignored (about 4%). A lot of people still use old versions of FireFox. So I still wouldn’t feel comfortable using localStorage etc. when at least 15% (for IE alone), and probably more like 30% of my overall users aren’t going to have those features work.

        6) I generally create separate mobile versions of my sites, and you’re right in saying that they have better support for new features than desktop browsers. I have recently started using HTML5 for some mobile content.

        I think our main disagreement is a philosophical one. I just don’t see the point of using new HTML5 features when I’m going to have to write JS polyfills anyway – why not just use the JS and keep development and maintenance simple?

        You’re also right in saying that HTML5 and CSS3 have been the focus of a huge amount of (often ignorant) hype, to the detriment of pretty much everyone. But that isn’t why I’m wary of leaping on the bandwagon. I’m not adverse to learning new skills either – like I said, I would be very happy to never use HTML4 again if the support was there for HTML5. In the meantime though, I don’t want to end up having to write and maintain two sets of code. I had enough of that trying to get IE6 to behave for the last 5 years.

        Louis Lazaris:

        I understand the doctype difference. To be honest, I’m not sure what the problem with having different doctypes for different versions of the spec was. Having a single doctype for HTML seems foolish – HTML is liable to evolve in the years and decades to come, and I don’t know what’s wrong with having different milestones to identify which particular set of features we’re using. What would be the problem with <!doctype html5>, and then in the future when they inevitably start adding new features to the spec, html5.1 etc.? Is it really so hard to change the doctype that we need to set one infinite, universal html doctype and then never change it again? Why even bother including one at all? Browsers can (and in fact do) just go off the MIME type of the file. But that’s a wider issue with the spec itself.

        Fair enough, yes, you can do away with many cludgy workarounds using CSS3. They just aren’t going to work on all browsers, so if you want to provide a consistent user experience (which a lot of businesses insist on, regardless of the arguments for progressive enhancement) you will still need to fall back to those hacky fixes.

        Using JS to enable the new semantic elements isn’t really a problem, but it is just one extra thing to think about. I’ll concede your point though, it isn’t exactly hard to do. But new semantic tags aren’t the features of HTML5 that most people are excited about. It’s barely worth the trouble of re-writing code just to get the marginal benefits of the extra semantic tags.

        The analogy of the tables vs. CSS wars might turn out to be accurate here, I guess we’ll see in a few years. In that case, CSS was definitely an improvement, and was worth migrating to. But the reason tables were so popular is because they were easy to use. The argument for CSS was that it was a “purer” standard, with a better approach to some fundamental ideas (separation of content and styles etc.). The same argument exists for HTML4 (it’s easier to use at this point in time), but HTML5 isn’t all that much better than HTML4. It’s an improvement, yeah, but a more marginal one. It doesn’t represent a fundamental shift in how we write code like tables vs. CSS did.

        This is all largely a matter of opinion, and I guess it really comes down to how willing you are to mess around making sure your polyfills work and writing two versions of your code to support different browsers (something that I’m sure all web developers have plenty of painful experience with already). Businesses generally want as little hassle as possible, and right now, that’s HTML4.

        I’m not knocking the book, I’m sure it’s an excellent guide given SitePoint’s record of quality publications. In fact I’ll probably end up buying a copy at some point, even if it’s just as a reference while I play around with the new features in some personal projects. I do object to ridiculous terms like “future-proof” being used to market it though, and I think the sales page for it should have a giant asterisk next to it, with a note explaining that all the “ease of use” of HTML5 only applies if you’re willing to abandon older browsers.

    • John

      SitePoint seem to have helpfully removed some of the tags I used there. It was supposed to read:

      They didn’t decide to create HTML5 so we could change all our <div> tags to <section> tags.

      For some reason, it looks like SitePoint have decided to delete any text between < and > characters from user comments, but allow us to enter HTML character encodings (e.g. &lt;) which then get parsed and displayed correctly. Which to my mind is a very odd way of preventing HTML injection. It would be a lot more useful if they properly escaped these characters for us instead of silently deleting them.

      • kaf

        I noticed that too. Sitepoint uses wacky wordpress I think so everything works a little weirdly.

      • Louis Lazaris

        John, they can’t do what you’re saying because sometimes people want to include links in their comments, which use HTML anchor elements (i.e. the “a” tag). Sometimes people want to include code snippets, which sometimes require “code” tags so the code is more readable. Sometimes people want to use bold or italic.

        These are common uses for HTML tags in WordPress-driven sites, and all WP sites handle it the same way by default. Thus, if you want your HTML to be shown to the users, then you have to use the proper HTML entities.

      • John


        It is entirely possible to do what I am saying. They can easily convert the characters to the correct HTML entities if they want to. If exceptions need to be made for certain elements, then they can very easily code in those exceptions. There is no good reason this simple functionality couldn’t be included on the site.

      • Patrick Samphire

        “They didn’t decide to create HTML5 so we could change all our &ltdiv&gt tags to &ltsection&gt tags.”

        You’re quite right, of course, and nobody who knows what they’re doing should be doing this. *Some* divs will become sections. Some will become asides. Some will become articles. Some will become headers and footers. Some will stay as divs. And so on.

        The point is, as I’m sure you know, to add additional semantics to the markup. This isn’t as shiny and exciting as canvas and local storage and all the rest, but it is something you can add now. Yes, even if you use a javascript shim you’ll still fail visitors in certain older browsers with javascript turned off, but that’s a business decision for each site. Some people have to support IE5 still, and I pity them.

        I know that some people don’t think the extra semantics have any point, but then the same argument could be made to abandon almost every HTML 4 tag and replace it with a div or span with an appropriate class (and, believe me, I’ve seen that in sites). I’ve actually found that introducing these additional semantic tags has improved the structure of my sites and my code, because it makes me think harder about the functionality of each part of the code. And, because divs had no significant semantic meaning, I used to be more ready to throw them in to hang CSS off. Now, I code better and rarely have to use any tags that don’t add semantic value. Maybe I just used to be a bad coder, but I’m happy to be using these new HTML5 tags when I can.

      • Patrick Samphire

        Bollocks. Screwed up the character encodings… Must learn to preview my comments…

      • John


        The extra semantic tags are fine, even if some of them are fairly arbitrary and vague. I understand the point of them. It is however a bit of a pain to convert all your HTML4 to the new semantics of HTML5, and I’m hesitant to do so while the HTML5 spec is still subject to change. I’m not sure the extra work of converting my code to use the new semantics is really worth the marginal benefits of doing so. I do agree that it’s slightly easier to write good markup with the new tags though.

        Incidentally, if you had previewed your post, you would have encountered another fun SitePoint comments quirk: if you have more than one newline (n) character in a row, they get collapsed to a single newline in the comment edit box after you press preview. So if you like to leave an empty line between your paragraphs, you’re going to have to go and put all of them in again after you press preview. Which isn’t a huge deal, but it’s another stupid problem that should be easy to fix. I’m not sure why SitePoint is using such buggy wordpress code. Their motto is “become a better web developer” – you’d think they’d try to do that themselves on their own site.

      • Patrick Samphire

        John, you’re right. I have no intention of updating any of my old HTML4.01 sites to HTML5. That really would be pointless. But new sites? Yeah, I’m using HTML5 markup for almost all of them (although it has to be on a case-by-case basis, of course, depending on the site and audience).

      • John

        Yeah, using HTML5 tags in new sites is reasonable. I will probably start doing so myself soon. Unfortunately, that’s pretty much the only usable part of the HTML5 spec right now.

  • Sphamandla

    I’m currently reading a html5 CSS3 book myself and I must say the new standards make it easier to make beautiful things on a web page while having fun at the same time.

  • Jim

    I purchased the book this morning. I just went to the html5herald site and found that in IE8 – the page is broken, Chrome – video doesn’t work, and in FF the bike just disappears instead of rolling off the page.

    Hopefully the code presented in the book will work with out fault.

    • Louis Lazaris

      Hey, Jim. Thanks for the feedback on that.

      IE8 doesn’t support much of anything in HTML5 and CSS3, so that was not a priority for this project. Not to say that we’re encouraging that for any projects, but this book constitutes an HTML5 and CSS3 tutorial, so naturally there are going to be problems because we’re using a lot of new stuff.

      I don’t see any problems with the video in Chrome myself. Do you have a version number?

      Also, depending on the version of FF you’re using, it may not support transitions (you need FF 4+).

    • John

      SitePoint generally write good books, so I’m sure the code will work fine. The bit they aren’t telling you is that it will only work fine in supported browsers, and HTML5 browser support is patchy at best.

    • Louis Simoneau

      Hi Jim. I can’t seem to reproduce the problem you’re having with Chrome, I’ve tried on Windows and Mac and the video works on both. In FF4, the bike transition happens, though I just added an extra modernizr selector to not change the bg position if transitions aren’t supported, so if you’re using an older version of Firefox the bike won’t disappear (that particular transition isn’t specifically covered in the book, it’s a bit of an Easter egg in the demo—although we do cover all the properties and selectors that are used to create it).

      As for IE8, my bad. I tested the layout in IE7—where everything works fine. I’ve just managed to track down the bug, and it’s a weird one. In order to demo some new selectors, our code does things like:

      #main > div:first-of-type,
      #primary {
      width: 375px;
      padding-right: 4px;

      The first selector is a new hotness CSS3 selector, the second is an ID selector targeting the same element for older browsers. IE7 doesn’t understand first-of-type, so it ignores it, but it still reads #primary and applies the styles. IE8, for some reason, ignores the whole declaration block. IE8 in compatibility mode will render the layout correctly. Go figure.

      Those layout styles, being pretty basic CSS2.1 float layout code, aren’t covered in the book at all—they’re just there to hold the site together, so no need to worry about the book code on that count either.

      I’ve just pushed up fixes to those two issues, so they should be live on shortly.

      Thanks for buying the book, and for pointing out these issues.

  • Jay

    The images in the e-book I bought are over compressed with noticeable artifacts and some images are just plain blurry, what gives?

    • Anonymous

      Hi Jay,

      What format are you reading in? PDF, EPUB or MOBI?


      • Anonymous

        Hi Melinda, I’m reading in PDF, in the latest version of Adobe Acrobat.

        Thanks for your response — Jay.

    • Melinda Szasz


      The images in the PDF are as high resolution as we can make them without making them too small to see (because many of them are screenshots so we have a limited number of pixels to work with to begin with). We’ve double checked the PDF and all the images appear to be fine. There definitely should not be any compression artefacts as we only compress images as PNG. Can you try re-downloading your PDF and letting us know if you still have this problem?


      • Jay

        Hi Melinda, the pdf appears to be fine now. When I downloaded a week ago, the pdf file was only 3.5 MB, I’ve only just redownloaded it, the updated pdf is 9.3 MB. Thank you for your assistance, the images look crisp and clear now :).

        Cheers — Jay

  • Robbiegod

    I had been griping about the new video tag in HTML5 and how it works for awhile myself.

    As i understand it, HTML5 added a nice new shiny tag called video. But the browser vendors can’t decide on what format of video they want to support. So, FF uses OGG, Chrome will use WebM (VP8 codec (they’ve recently dropped support for H.264)), and Safari supports H.264. So, to use HTML5 video i have to make 3 different version of the video!!! This seems completely insane. What kind of standard is that?

    In addition to those 3 version, if I want to allow older browsers to see my video I have to provide a Flash player (because guess what? Flash runs on everything except iPods and iPhones.)

    Obviously what needs to happen is all browsers must at least adopt one common codec so developers don’t have to waste time making multiple versions of the same thing. Its wasted space, wasted time, and up until the iPhones/iPods/iPads became popular Flash has a nice, simple solution to all of this.

    Personally, I believe WebM will be the future with Google Chrome, IE, and Firefox eventually supporting it. I don’t think Apple will support WebM unfortunately.

    It really is a headache and the dudes writing the HTML5 should specify what codec is the standard codec. I believe WebM is the best option at the moment because it will free forever. H.264 is only being promised to be until 2016.

    • digiway

      Hear hear @ robbiegod!!!

  • Paul O’Brien

    Hi Louis,
    Re your comment :”The first selector is a new hotness CSS3 selector, the second is an ID selector targeting the same element for older browsers. IE7 doesn’t understand first-of-type, so it ignores it, but it still reads #primary and applies the styles. IE8, for some reason, ignores the whole declaration block. IE8 in compatibility mode will render the layout correctly. Go figure.”
    IE8 is behaving correctly (according to the specs) and if a browser encounters a rule it doesn’t understand then it should exit at that point (even in a comma separated list). That’s why you should never apply any pseudo classes/elements in a comma separated list unless you know that all browsers support them.
    Just wanted to clarify that IE8 is in fact behaving correctly here:)

Get the latest in Front-end, once a week, for free.