Antony Kennedy

Have you tried some basic debugging?

function addAspect() { alert('function called'); }

Otherwise, your output must be different from other people's. Use view source, and a diff tool to compare. Or you have javascript disabled? Or you are running locally instead of via a server?

It has nothing to do with your if statement.

This is wrong:

var aspect = document.getElementById("aspectResult").value;

This is right:

var aspectResult = document.getElementById("aspectResult"); var aspect = aspectResult[aspectResult.selectedIndex].value;

Which browser are you using? Post your code.

Congratulations! Hope you enjoy the book!

Hi.

Although some browsers allow you to access the current value of a select box directly, this is not the preferred way or most compatible to do it.

All browsers do expose a property called "selectedIndex" against the select box, and the select box itself is an array of objects with properties called "text" (the displayed value) and "value" (the actual value).

There are various bits of your code that are not ideal, but hopefully this example explains where you are going wrong.

function addAspect() { var aspectResult = document.getElementById("aspectResult"); var aspect = aspectResult[aspectResult.selectedIndex].value; switch (aspect) { case "Option1": var print = "This is option1"; break; case "Option2": var print = "This is option2"; break; default: var print = "Unknown option"; break; } document.getElementById("mainBlock").innerHTML = print; }

Hope that helps.

Opinions are divided on the use of sprites.

For mobile devices, you should use sprites as much as possible. However, they should be sensible. Don't load lots of sections that you are only going to need on a few pages – have a global sprite sheet for all pages, and individual "feature" sprite sheets.

For desktop devices, I am (personally) of the opinion that sprites can quickly becomes too difficult to manage. I believe that you should use them for multiple states of things like buttons, or for images that you would typically have to preload or risk having to wait for the image to download (or face a website that feels unresponsive). While it is definitely true that less HTTP requests is usually more important than filesize, don't go so far that you create something that is a nightmare to maintain or pass on.

We deal with this in the book, yes.

I hope this is helpful.

The HTML5 (and other) Doctype can trigger differences in rendering and affect browsers decisions of rendering modes (such as Quirks Mode). Support for the audio and video tags, although part of HTML5, have low level browser support. Although HTML 4.0 Transitional does not, technically, support audio and video tags, I am not at all surprised that they are rendered.

However, things like the box model, margins, padding, display methods of elements and so on, will certainly not be consistent with varying doctypes. And you are only, so far, testing in Firefox 3.5 – whether or not this works in other, older or newer browsers remains to be seen.

With the wrong doctype, you will also not be able to use validating tools correctly.

To get rid of one more variable that could be the cause of bugs and unexpected rendering problems, use the doctype, and use it consistently.

You're very welcome. Thanks for the support. I hope you like it!

As long as you are considering caching from the outset, and putting effort into minimising the payload and HTTP requests, there is no reason Joomla cannot be thought to be just as appropriate as other CMS'.

Hi Marco.

We discuss some of the ways to get the best performance on mobile devices in the book, yes.

Where you are asking about using JS or CSS, I assume you mean for things like transitions, transforms and animations? In which case, yes, we discuss those in some detail.

Hope that helps.

Hi Paul.

Great question. Yes, we talk a lot about print stylesheets and things to consider. You don't need to use @ rules for this (although, you can of course) the media attribute in the link tag has much better browser support, although it does incur an extra HTTP request (even when you're not printing!).

A great print CSS article is one written by Eric Meyer for A List Apart. Although this was written in 2002, it is still very relevant today. We talk about some of the more complex printing techniques in the book.

I hope this is helpful!

Hi Leroy.

Absolutely - we talk about media queries and devices other than the desktop in great detail.

So, I'm going to deal with this as two separate questions.

Common mistakes CSS developers make:

Number 1 - not planning for the future. Too often, developers build something that works *well enough*, and then just add to it as they need to. This works okay in the short-term, but as the site grows the CSS quickly turns into A Big Ball Of Mud. Legacy CSS is a nightmare to refactor, and locating unnecessary properties or selectors is, in the best case, very difficult, and in the worst case impossible. Plan for the long-term. Document well. This will help avoid unexpected errors like IE refusing to read any files after the 31 CSS file limit, or ignoring the end of any CSS file longer than 288KB. You may laugh, but these are very real issues (which are difficult to isolate without experience) that I have seen mature websites encounter.

Number 2 - being too precious. We want to avoid non-semantic class names where possible, and adding extra classes or IDs can feel dirty, and inelegant. However, semantics in class names (unless they are *very* common) are something that only developers really care about - Google and screenreaders couldn't care less. (An exception to this would be something like "bigRedBox" – this is obviously not future-proof). Although not ideal, let's be pragmatic. If you have to use them, presentational classes like "floatRight" are okay. If all they are doing is floating things right, what else would you call them?

Building complex CSS3 selectors to avoid adding classes is rarely the best solution: they are malperformant, often fragile, have poor browser support and are difficult for new developers to understand.

What CSS mistakes might discourage visitors?

Number 1 - (as mentioned by David) designing for a single browser. This doesn't (or shouldn't!) often happen in sites with high traffic, but I have seen it occur. You need to know your audience. Use your reporting tools to figure out which browsers your users are using, and make sure to test and ensure they have a good experience. Perhaps they only provide 1% of your traffic, but if that equates to 100,000 users a month that is still a figure you need to be considering.

Number 2 – too many files/huge CSS. CSS has much greater performance implications than many people think. Particularly for mobile users, every file downloaded incurs latency and lag in presenting the content. Always work towards best practises, keep files small, use build scripts to concatenate and minify… Above all, minimise the amount of HTTP requests.

I hope this is helpful. There are hundreds more tips like these in the book. ;)

Hi Rogerio,

This is a tricky question. As I'm sure you know, HTML5 is a blanket term for a whole array of elements, APIs and features. CSS3 really lives separately from HTML5.

We certainly talk about some HTML5 features, and problems you might run into – and we also talk about lots of CSS3 stuff. However, the book is really about your development practises, debugging, being pragmatic, ensuring it is easy to onboard new engineers, etc. We don't go into great reference detail on all of the properties and so on… this is already covered in many fantastic books. We talk specifically about challenges you can expect to face if you are working on a very large site, expecting large volumes of traffic, or in large fast-moving teams.

I hope this helps.

Hi Ryan,

So far as covering specifically how to deal with media queries and the features you can query by – absolutely, this is discussed in great detail, along with some of the caveats and likely problems you may encounter. We also talk about differences between devices (and accessibility considerations) and advice on how to address those in the most performant fashion.

I hope that answers your question!