The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Yeah, we got a little unlucky on that chapter, we also had several things we moved to an appendix because they were tentative at the time of writing which have since become widely implemented (e.g. the Vibration API which became a W3C Recommendation today). Though given we did the bulk of the writing in 2011 and 2012 when so much of the spec was still tentative I think we got pretty lucky overall.

I think it's likely we will see some equivalent to these APIs in the future, for some background on why other vendors didn't implement these particular APIs check out Why no FileSystem API in Firefox?.

To answer your last question first: no, it doesn't matter. In JavaScript most semicolons are unnecessary as the parser will insert them automatically. For example (and referring to your statement "'re essentially declaring a variable. Therefore, it needs to be terminated with a semicolon"), this is perfectly acceptable to browsers:

var a=1, b=2, c=3

alert(a + b + c)

I believe the habit of putting a semicolon at the end of every line but not after function/class definitions comes from C/C++, from which JavaScript inherited a lot of its syntax (note: I am not a C/C++ expert).

From my point of view: I spend a lot of time writing in a C-like language which does require semicolons so I'd rather just use them consistently than remember two sets of rules. My advice to you would be to pick the convention you are comfortable with and stick with it.

As far as the examples in the book are concerned I think this is just an inconsistency we failed to spot when proof reading, as you noted it has no functional impact.

Sorry mhnajlee, I don't know FFmpeg well enough to help you with this. I recommend you try asking on the mailing list:
> There is a tiny bug (or what appears to be a bug),
> when the chat button is submitted the browser loses
> the chat form. It clears completely and prints "OK".
> All 5 browsers react in the same way.
Sounds like a problem with the JavaScript - are there any errors in the console?

> Your last reply suggests that there are still parts of the code that need polishing.

At some point I deleted the folder containing the completed app and instead kept the folder which was mostly snippets for copy and pasting into the chapter. I need to recreate the finished app. I've been putting that off for a couple of months as I've been moving house but now that's done with (my bed is getting delivered today!) I really should get down to it.

All the interesting bits of the code as far as HTML5 is concerned are in the chapter, so I think it is possible to get out of it what I aimed for you to get out of it, but you will have to fill in a lot of gaps to make the app yourself.
Looks like this is a problem with the MSI file, try a different version and see if that works. I'm fairly sure the code in the book will work with 5.4.30, it's just that 5.3 was current at the time the chapter was written so that's what was used.
I think it's working correctly but the defaults in the Firefox console might have changed. Assuming you're using Firefox: click on the 'Net' drop down and ensure the 'Log' option is selected.
Sorry about that. I don't use Windows at home myself so I'm not much help with the specifics.

The focus of the book is the client side technologies so I picked PHP/MySQL as it was the most ubiquitous combination across Windows/Mac/Linux, therefore the one most likely that people would already have access to.

At some point this summer I'll try translating the example into a few different server side platforms to increase the odds of you getting something to work, though first I need to get the code for the second half of chapter four re-written.
> Thank you!

And, on behalf of my co-authors and myself, thank you! I hope you continue to enjoy it.
Your best bet is to follow the instructions on the PHP website, if there's been any changes to the install process since I wrote that appendix then they'll be noted there. The PHP community is generally very good about helping newcomers so it is worth posting your problem on the php-install mailing list.
Sorry, at some point in the time between originally writing the chapter and the book actually getting released I've lost the full source files (should have made better use of source control, I know). I am planning to recreate the app and will update the GitHub repo once complete (this may be a while, currently in the process of buying a house). Please follow this ticket on GitHub to be notified:
Hello! HTML 5 & CSS3 is a more introductory book, the main content assumes prior knowledge of HTML and CSS but there are some appendices to help you get up to speed. The examples are mostly small and self contained. If you are willing to work hard and experiment with the examples it should have enough information to allow a beginner to get through it.

HTML5 in Action is a more in depth book, the examples are larger, more realistic applications which take up a chapter each. You need to know HTML and JavaScript already to get the most out of it, there is no direct coverage of CSS3 (we make use of CSS in the applications, but don't try to teach people CSS).
This is from the preface:

> This book is for developers who have a decent understanding of
> JavaScript and HTML syntax. If the terms loop, array, and JSON
> are completely unfamiliar to you, you should brush up on those
> before proceeding.
Sorry for the delay, hope you're enjoying it smilie
The book is complete and currently going through the final proofreading and typesetting process.
OK, glad you got to the bottom of it smilie

I'll investigate it further at my end and see if I need to make any code changes, I did my coding primarily in Firefox so I'm surprised it's not working now. Possibly there's been a small change in the 18 or 19 releases since I last tested everything.

You will always get the message about unsupported types in Firefox if you list h264 sources, it shouldn't be a problem as long as there are other sources that it does support (it reports the error on a per source element basis, not after it's been through all of the source elements).
Hi Ed

> Does the <video source src= property support URLs? >
I'm not really sure what you mean by this, the examples in the chapter are URLs (they're relative URLs).

> It fails with
> [02:29:44.682] HTTP "Content-Type" of "text/plain" is
> not supported. Load of media resource
> http://localhost/DevVid/VID_20120122_133036.webm
> failed.
Your server is not setting the correct MIME type in the Content-type HTTP header, are you on Apache or IIS?

That looks right, but it clearly isn't working if your .webm video is getting served with "text/plain" as per your reported error. I don't own a Mac so can't be much help with that directly, possibly the server needs restarting to pick up the settings?
In Firefox hit Ctrl+Shift+K. In most other browsers (and in Firefox if you have Firebug installed) hit F12.

If you replace the divs with spans then add a rule label > span { display: block; } then you should have valid markup and the same resulting layout (warning: I've not tried it yet).
Hi Irwin.

Sorry about that, the appendix will definitely be there and the references to all of them will get checked before publication. Re-ordering the appendices is something that can only take place when none of the authors or various editors and proof readers are working on them so we can't always keep them completely in sync.

The content about channel messaging previously appeared in the same appendix as the Node setup information but I felt that it was sort of 'tacked on' there (the only link was that it was all content that was originally written for chapter 4) so I moved it to a separate appendix.


Hi Jake

I'm not sure exactly which polyfill is referred to in the chapter, but there's a whole list of them here (look for the heading 'Web Forms' about a quarter of the way down the page).


OK, at least it's working now then!

Hi Adrian. Are you sure you've not downloaded the free sample chapter rather than the latest MEAP edition?


Hi Glenn. We are working on a dedicated website for the book, though at the moment the actual writing is taking priority. In the meantime you can indeed download the sourcecode from the book's page on under the heading resources.


Hi Irwin, thanks for your feedback.

I think the problem here is that earlier versions of Chrome implemented some broken support for date inputs. This was reported as an issue, and that support was removed in Chrome 16. I'm not sure of the exact dates this chapter was written but I suspect it was before the release of Chrome 16.

There is always a risk of this sort of thing happening to us because browsers are updated so quickly, we will be reviewing the entire manuscript before publication to ensure that everything is correct before going to press.


The new elements are mostly described in terms documents rather than applications, even then there are some obviously appropriate mappings, for example: nav as you already mentioned; article is "a section of content that forms an independent part of a document or site", so a good match for dashboard widgets and other embeddable components; aside is a good match for incidental content, for example a settings pane which slides in over the main app.

However, if your goal is to add semantic markup to applications then you'd be better off investigating ARIA (Accessible Rich Internet Applications) as well as just HTML5. It has a far richer set of roles and states than offered by the HTML5 semantic elements on their own. You might also find interesting the 'Strong native semantics and default implied ARIA semantics' and 'Default implied ARIA semantic' tables in this section of the spec.
Just to add my two penneth on this thread: having your app look the same in all browsers is a false goal. The only person that's going to look at your app in more than one browser is you and (possibly) other web developers. From your user's point of view it's more important that date pickers (for example) look the same across websites, rather than that the web picker on a particular website looks the same in all browsers.
I think we might have a small error there, it depends on whether the field is required or not. If the field is required then it is invalid when there's nothing in it, or when the wrong sort of thing is in it. If the field isn't required it will only be invalid after the user has entered an incorrect value into the field. For some things a one character entry is guaranteed to be invalid (eg. emails) so the style will flash to invalid for those first few characters. You should be able to see the difference in this jsFiddle (in a supported browser smilie ).

Hi Tychicus. This isn't the iText forum, you could try asking your question here.


Hi jwdaigle

The goal of <em>HTML5 in Action</em> is to cover HTML5 at a 'professional level'. We feel that there are plenty of books which have great coverage of the features of HTML5 but not so many that deal with how all those features combine into real applications. The plan is that each chapter (apart from the first and last) will be built around a full example application so that you can see how all the features fit together, and we will be focussing on web applications rather than web pages.

That's the goal anyway, whether we live up to it or not you'll have to let us know smilie

One thing that will be lacking is any in depth coverage of CSS3. We will, of course, use CSS3 where appropriate within our examples but the focus is HTML5.

My other book, <em>Quick and Easy HTML5 and CSS3</em> is intended to be more introductory. It won't go into the same depth as <em>HTML5 in Action</em>, but it's trying to be a more broad introduction. Of course, there's nothing stopping you buying both books smilie

I hope that answers your questions, if you have any more please just ask.


It seems to work fine for me:

Do you have some CSS rules which apply to headings?
Hi Dennis. Thanks smilie

I think you're right, the problem is going to be that by the time that happens we'll all be looking forward to HTML6 and HTML7!
Hi Jonathan.

I'm not involved in the process for this sort of thing, but on the home page at the moment it says "Hello! HTML5 & CSS3 ePub + Kindle available Oct 31."


Yeah the gradients stuff is a bit of an adventure, there are at least three different versions supported across the various current browsers:

  • The original Apple/WebKit syntax

  • The proposed Mozilla syntax

  • The current W3C syntax

The code in the chapter in the current MEAP uses is outdated following the change in the W3C syntax earlier this year, though I did recently go through and update everything for the final publication process so the examples (when you get them!) all correspond to the current W3C spec, and the browser support section has a full cross browser example.

In the current W3C version the syntax you're quoting would be invalid, you could have the left to right gradient or the angle but not both:

background: linear-gradient(to right, #000, #fff);


background: linear-gradient(315deg, #000, #fff);

A cross browser rule for that last one would look something like this:

#gradient {

background: -moz-linear-gradient(to bottom right, #000, #fff);

background: -webkit-linear-gradient(315deg, #000, #fff);

background: -o-linear-gradient(to bottom right, #000, #fff);

background: linear-gradient(to bottom right, #000, #fff);


Different browsers have different levels of support, for instance Firefox currently has support for the new W3C syntax for linear gradients but not radial ones, and will also support the old Mozilla syntax in -moz- versions. IE10 will support the W3C syntax un-prefixed, Opera supports it unprefixed, and Chrome/Safari support the old WebKit syntax and the old Mozilla syntax with the -webkit-

This is a pain for authors as well as readers in the short term, but in book timescales I'm anticipating that by the time the book has gone through all the proof-reading and typesetting and printing to actually be available from bookshops, everyone will be using the new W3C syntax. In the meantime if you need any specific help with making the examples work in current browsers please post here.


Hi lmhaskins, thanks for your feedback

I agree that the purpose of the outlining algorithm could be more clear but I think how I've described it is technically accurate. There's actually nothing in the HTML5 spec that declares what it's for, only an algorithm for creating the 'document outline' (or as I've described it 'table of contents', or as you've described it 'outline structure').

The only specified requirement for it that I'm aware of is in the W3C's User Agent Accessibility Guidelines (Implementing Guideline 1.10 - Provide alternative views). I think you're right that I should mention this, I'll see if an update can be made there.


Sorry Alejandro, I've not been getting updated for this forum for some reason so I missed your post.

I'll try and get the source code download sorted out, in the meantime I've attached the Web Workers example.


Hi, thanks for the feedback.

1. Setting it to -0.4em worked OK in all the browsers I tested. I agree it's not perfect, but then layout with CSS won't be perfect anyway until we get wide support for flexboxes and grid layouts. At that point the need to do any layout with inline-block will mostly disappear.

2. In this situation the HTML white space handling rules are an inconvenient obstacle, I don't think making the markup less readable is a good solution either.

If you're interested there's a good summary in this CSS-Tricks blog post: Fighting the Space Between Inline Block Elements.


Sorry, I somehow managed to unsubscribe myself from post notifications on this forum in about March. I'll see if I can find out what happened to the source code.


Sorry. I'm guessing that on MacOS these files are hidden, in much the same way as Thumbs.db on Windows or dot directories on Linux so people just don't notice. I'll mention it to my editor but I expect there'll be times people just forget about things they can't see.


Hi Alejandro

Apologies for this - that code was originally written back when Opera was the only browser that supported the API and it doesn't now work in Firefox and Chrome (though it does still work in Opera). One of the reasons it doesn't work in Firefox and Chrome is that the validity is checked before the submit event is fired. This can be fixed by attaching to the invalid event instead: fldName.oninvalid

The other reason your example isn't working is that the field isn't actually invalid when you submit the form - put the required attribute on the input field to trigger it.

I've put a working example on jsfiddle for you to look at (this forum just makes a mess of the code, sorry), I'll update the code in the book the next time I'm working on that chapter - thanks for bringing it to my attention.


Apparently Safari has some issues with the <tt>required</tt> attribute which I wasn't aware of (more details here). I'll update the compatibility tables in the eBook version when it next gets revised.

Generally you should always validate on the server too, and provide JavaScript fallbacks for browsers without support.

Hi Gary. The letters are lower case in the screenshot, it's just that the font I used for the screenshots (Komika Hand) looks identical in upper and lower case. I agree it's possibly misleading in an isolated example, but I wanted to use the same font in the comic sections and in the screenshots.

I'll reconsider the font choice there, but re-doing nearly all the screenshots will unfortunately be a lower priority than actually finishing all the writing smilie

Woody, sorry, but the drawings and the conversations (though not so much the inane) are a part of what makes the Hello! series books. If they really put you off then there are several other books on the market and some forthcoming titles from Manning which may suit you better.

Thopmson4822, sorry about the graphics - the MEAP versions are under certain constraints as far as file size is concerned which means the graphics in the PDF don't always come out very clear. All the text, including the listings that are currently part of graphics, will be properly typeset in the finished versions (both printed and ebook), the graphics will be reviewed by a graphic designer, and all the code will be available for download. In the meantime the code that's in graphics is because I wanted to indicate a layout that couldn't be easily achieved in Word, I'll try and figure out a way to also include the code in plain text for a future update (which might be as simple as also including the plain text).

In case you missed it in the run up to Xmas (I know I did), the release of Opera 11 brought several new HTML5 forms features, including being the first browser to implement the color input type (see attached image). Of course this means that section 3.3.7 of the MEAP is now out of date, I'm re-writing that section for a future update.

% is the modulus (or remainder) operator:

What browser were you having problems with?

Thanks Greg. It looks like we made the same mistake in chapter 2 as well but got it right from chapter 5 onwards. The order looks to be correct in all cases (alphabetical: Chrome, Firefox, IE, Opera, Safari) but the Chrome and IE icons are swapped.


Hi Richard

I thought I'd better post an update here since the finished book ended up not including the example applications (even without those chapters the book was significantly longer than the initial agreed page count). If you're still looking for this sort of thing from a book, HTML5 in Action is our upcoming title which is based around sample applications (each chapter apart from the first one develops a full application).


Hi Richard. Sorry, I've not completed that part of the book yet. There are many examples of similar sorts of apps available online, here's a couple which you could take a look at:

Thanks Ron, I'll correct the manuscript.

Thanks Christian. I've corrected the manuscript, the changes should filter through in a future update.

Thanks Larry, for this post and the other two. I'll make the corrections for the next update.

And once more things have changed - the onforminput event has now been dropped, so ignore that section of chapter 3 for now. I'll re-write the next time I'm updating that chapter.

Good news, looks like onforminput is staying, here's Hixie's comment on the bug report:<blockquote>Since you can't register capturing handlers declaratively, and since
form controls can be all over the place in the DOM now, I think 'forminput' and
'formchange' are still very helpful and have clear use cases. As as
straightforward demonstration of this, try to rewrite the examples in the spec
that use these features to do them without onforminput/onformchange and see
whether it's still as simple.</blockquote>

The forminput event now looks likely to be removed from the HTML5 spec. The only browser to have implemented it so far is Opera, and it is possible to replicate the functionality through normal event bubbling if you use attachEvent for adding events rather than doing them inline in attributes.

Assuming you have a function updateOutput to update your output elements, then this event registration:

document.getElementById('myform').addEventListener('forminput', updateOutput, false);

Is functionally equivalent to this one as long as you don't capture and block any input events:

document.getElementById('myform').addEventListener('input', updateOutput, false);


Message was edited by:

Changed second code example, last parameter is not significant.
I've just noticed the two graphics at the bottom of page 39 are in the wrong order. Erwin should come after the conversation between AJ and Greg. Greg's first line of the conversation is: "I’ve had a look at the outlining algorithm, do I really need to understand that in order to write HTML documents?"

I think this is just Word being temperamental, it should be correct in the next update.

Thanks Jesse. I've corrected that in the manuscript, it will be fixed on the download in a future update.

Hi darrenj, thanks for reading.

The goo on 58 and 59 is supposed to be vertical text, the column headings are supposed to read (in order):

Metadata Content
Flow Content
Phrasing Content
Interactive Content
Embedded Content
Heading Content
Sectioning Content

This seems to be a quirk that creeps in between me writing the manuscript in OpenOffice and the staff at Manning opening it in Word, when the chapter is properly typeset it shouldn't be a problem.

HTML5 allows both XML and HTML serialisations. If you serve your pages with the application/xhtml+xml MIME type then you can use the XML serialisation, but then your markup has to conform to more strict rules, one of which is that all attributes need to have quoted values, so then that code would look something like this:

<section id="rob" itemscope="itemscope" itemtype="">

As it is, I've used the more forgiving HTML serialisation throughout so far which allows stand alone attributes, which I've take advantage of, as well as other stuff like mixed case tag names and unquoted values, which I've chosen to avoid (for consistency).

Hi Javier

It won't affect the topics covered or the general aims of the book, there will of course be some changes to the content as we receive feedback from readers and reviewers but this would have been happening anyway without the name change.

Hello everyone!

Thanks for taking the time to read the book, please post any feedback or requests for clarifications here.