The Art and Science of CSS

nateklaiber writes "The Art and Science of CSS was a quick read (208 pages) and packed full of valuable code examples. Unlike other CSS books that teach you the specifics of CSS with vague examples (not vague in a bad way), this book teaches you specific examples and gives you extra resources. This book is somewhat of a cookbook of commonly used CSS methods. Each author brings their unique writing style to the table, and each chapter focuses on a specific aspect of design and its CSS and styling methods." Read below for the rest of Nate's review. The Art and Science of CSS author Jonathan Snooks, Steve Smith, Jina Bolton, Cameron Adams, David Johnson pages 208 publisher Sitepoint rating 5/5 reviewer Nate Klaiber ISBN 0975841971 summary This book is a cookbook of commonly used CSS methods. Chapter 1 starts with Headings. The author of this chapter gives a brief introduction to hierarchy and branding, and how you can achieve more control with your look and typography. As typography is discussed, he moves on to talk about image replacement and the many techniques available to us today. There is no perfect solution when it comes to image replacement, but the author does a great job of showing current methods, their advantages, and their disadvantages (including an in-depth section on sIFR).

Chapter 2 is all about Images. The author starts by showing you how to create a basic but aesthetically pleasing image gallery. The task at hand is to create the enlarged version, the thumbnail page, and the galleries page while keeping the markup lean and semantic. Each of these are put together very nicely with flair not usually seen in off the shelf image galleries. The author also discusses how to create images (in context) with captions, including a nice use of transparent PNGs. The authors creative use of captions give you options outside of the box (both semantically and philosophically) of normal captions that are seen all around the web.

Chapter 3 shows us that backgrounds don't have to be boring. This is a very simple chapter that discusses backgrounds of the past (repeating pictures, large pictures, etc), and then looks forward to the present in getting creative with your backgrounds. He uses a case study as an example, and it shows specifics of positioning and layering.

Chapter 4 jumps into Navigation. Different types of navigations are discussed (vertical, horizontal, tabbed, variable width, etc) and shown with specific examples. The author shows how to take from each of those to create advanced navigation systems using images and your semantic markup. I think that from this chapter a user could create an advanced navigation simply because the foundation is set pretty solid before he gets to the advanced section. This chapter goes hand-in-hand with chapter 1 when talking about image replacement.

Chapter 5 discusses the dreaded (sometimes feared) Forms. Forms come in all shapes and sizes and it is up to us to build them accordingly with the user in mind. The styling in this chapter spruces up what is a rather mundane form while giving you great flexibility and hooks to extend yourself. The author discusses the several different layout types (top aligned label, left aligned label, right aligned label) and shows how to enhance each. If you work with forms often, this chapter will help you whip up a clean interface for the task.

Chapter 6 is everybodys favorite chapter Rounded Corners. The author gives you an arsenal of tools (and knowledge) to attack the task of adding rounded corners. He discusses the different methods (horizontal stretching, vertical stretching, and full flexibility) and shows you how to achieve each keeping in mind the task of keeping the markup minimal and meaningful. We also get a brief glimpse into what CSS3 will have to offer us with multiple backgrounds per element.

Chapter 7 closes out the book with Tables. Tables still have a strong place in web development and the author shows you how to use tables properly (with semantic markup) and then how to give them a little visual jump-start and interaction. The markup presented here helps you give clear meaning to your tables as well as building with accessibility in mind (which is always important with tables, specifically). We round off the chapter looking at some interaction enhancements via Javascript that we can use with our tables (sorting, striping, and hovering).

Overall I found this book to be an excellent read. It was short and to the point, and gives the reader a great starting point (as well as inspiration). The book itself is well designed. My only qualms with the book is that the code examples are listed in full in many places, which gives less room for content related to the chapters. As I said in the beginning, this was a fairly quick read but well worth it. I would say that this is for an intermediate CSS developer, as specific CSS is not discussed in great detail but given to you as a way to achieve a specific design task. If you are familiar with CSS and need a quick way to achieve the tasks listed above, then this book is perfect for you.

You can purchase The Art and Science of CSS from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Learn CSS from a book?

[chris098]

I'm really not sure that a printed paper book is the proper way to learn CSS methodologies. There are so many resources on the web now, and "learning by doing" helps the content stick much better (in my opinion).

Re:Learn CSS from a book?

[Anonymous Coward]

If you actually read the book, you would know that this is a book where you "learn by doing". I just finished this book and I thought it was a great read for some helpful CSS tips.

Re:Learn CSS from a book?

[The Clockwork Troll]

You are right that the book is not a comprehensive reference for browser variations, although it does bring up differences between the CSS specification and actual browser implementations (ca. 2007), when they are critical to the content being discussed.

For example, in the chapter on Backgrounds, the book points out the relatively limited browser support for the background-origin property.

In the chapter on forms, the book mentions that only in the latest generation of browsers can you actually style input elements by selecting for type (i.e. via CSS attribute selectors).

Although robust web development requires understanding the many browser quirks that abound, I can also understand the rationale behind the authors' approach in this book, which generally is implementation-agnostic.

They are betting that as time goes on, browsers will tend to converge to the spec, and antiquated browsers will represent less and less of the browser population. In other words, the book as written will only become more accurate with time (with respect to existing specs and browsers in actual use), while information about variations in today's browsers diminish to the status of curiosities.

Re:Learn CSS from a book?

[hobo sapiens]

Many templates on the web *are* really bad, but a quick visit to alistapart.com or csszengarden.com will give you some decent ones.

If you are one of those dweebs who just takes web templates without understanding how they work, then yes, you might not find the four column layout with double headers and pie menus that you so desperately think you need.

But, if you use those templates as I suspect they were intended, namely, to look at how they work, you can make your own design. Things like negative margins, auto margins, etc, may not be readily apparent if you have never seen them in use. But once you see them in practice, you should get all kinds of ideas on how to make them work for you.

If you want to be the sort of person who understands how these templates work, download them and play with the CSS. See what breaks it, see what makes it tick. That is how you become conversant with loads of neat CSS tricks. Pretty soon, you won't need those templates.

Re:Learn CSS from a book?

[Anonymous Coward]

Many templates on the web *are* really bad, but a quick visit to alistapart.com or csszengarden.com will give you some decent ones.

With all due respect to the people behind the CSS zen garden, it is most definitely not a good example of web design.

There's always been a contingent of web designers who hate new things coming along that they don't understand and don't want to learn. They dislike CSS for this reason (among other, more sensible reasons), and they rationalise this in a number of ways. At first it was lack of browser support. After browser support became more common, it morphed into the odd (if you know what you are doing) claim that it was impossible to create good-looking designs with CSS.

So along comes Dave Shea and sets up the zen garden, to which people contributed good-looking stylesheets. People were arguing for years that CSS meant boring designs, and the zen garden shut them up for good. Which was great, of course.

But don't for a second think that they are good examples of web design. They are not. Some of them are, of course. But the zen garden was an exercise in art, not design. Many of the zen garden designs look great, but are awful in terms of design. Remember that the difference between art and design is that design is supposed to be functional first and foremost. In this respect, many of the zen garden designs fail because they are unreadable, have awful contrast, are a pain to scroll, and all kinds of other mischief. But they look nice, and that was the point of the project.

If you are looking for ideas, then go ahead and use the zen garden for inspiration. But don't blindly follow what somebody has done and expect it to be good design, because there are many things that, if implemented on a real website, would utterly fail their visitors.

I don't need another CSS book

[niceone]

What I need as a 4'x2' poster (or possibly a flashing neon sign) saying: "You CAN NOT use // comments in CSS".

Your post

[p3d0]

Cromar's post makes a good point. It is concise and understandable, though well over half the post is one big sentence fragment. Overall, I'd say it's worthwhile reading for anyone who is thinking of reading Nate Klaiber's review.

Re:Am I the only one

[slughead]

Old: Download a hunk of HTML. Browser renders it. If the ISP's spotty (maybe the setup of that HTTP transaction fails 5% of the time), then one out of 20 times you don't get any HTML to render. So you reload and all's well.
New: Download a hunk of HTML. Download a separate .css file, or two, or three, or four, sometimes from the same server, other times from some other server. If the ISP flakes out on you 5% of the time, and you have 5 different files to download, then (.95^5 = 0.76) about one time out of four, you get nothing, and have to reload.

If the ISP flakes out 5% of the time, somebody needs a new ISP.

Caching CSS files and using CSS effectively can make the total code smaller and, since .css files are cached, drastically decrease future load times. So the page is smaller now, and requires yet even less downloading later.

Old: Javashit is a security risk.
New: Javashit is still a security risk, but we'll make damn sure that none of our content renders correctly unless you turn it on, because how else are we going to run our browser-detection script that determines which of the half-dozen stylesheets (see above) we want your browser to use.

'Javashit' is what allows web pages to function as cross-platform software applications without having to rewrite. Though coding for 5 web browsers at once is a bitch, it's a price I pay gladly.

Also, the evolution of the internet into 'efficiency' and 'efficacy' using javascript and CSS isn't nearly as big a problem as all the different browsers interpreting the code differently.

Christ, you have to upgrade to IE7 just to get transparent PNGs to work correctly (unless you work around it).

Old: Any font you like, as long as it's Helvetica, Courier, or Times Roman. But it'll be the version of Helvetica, Courier, and Times Roman that your OS designers knew would look good with its engine, at the sizes that look good on your display device.
New: Any font you like, as long as you're running the same DPI on your monitor as the web designer was running on his screen. If not, it'll look about two sizes too small, or two sizes too large. But it'll never look like the "right" default font that the pre-CSS browser would default to.

Uh in CSS you can change the sizes of items based on pixels and 'em' (not sure what that means). Basically, 'em' scales the dimensions based on font size, so you can zoom in on a page and have the elements change size as well.

As far as the new way of dealing with fonts and the problems with differing DPI's.. wouldn't that be the case in the old way as well?

Yeah, let's just go ahead and bitch about how people have multiple monitors and 30" displays now--things were so much better when 1024x768 was the biggest you had to worry about.

Also, having vector-based elements such as flash can up-scale sites to any resolution while keeping elements the same size (called resolution independence). Nobody seems to be doing much of that though.

Old way: Simple pages which take forever to load and have few fonts
New way: Complex pages which require good programmers to setup, some of whom are inconsiderate to users of rare resolutions/browsers.

You forgot...

[KingSkippus]

Old: Spend literally days planning and laying out tables so that you can make sure stuff is lined up correctly and (gasp!) maybe put a menu on the left or something.

New: Assign it a CSS attribute and call it done.

Old: Want to change the font of your site? Go through Each. And. Every. Single. Page. and change it.

New: Change one line in one file.

Old: Create HTML files that were several kilobytes worth of extraneous #@$*! attributes do the most minor of things. Want the data in a table centered? Be prepared to modify hundreds (thousands?) of td tags. (Even programmatically, this is stupid.)

New: Define the attribute once in one place and have it apply to the whole file.

Old: Everyone who wanted to display anything meaningful on the web had to be an HTML coding expert as well as a design expert.

New: There's a pretty good division of labor that will if desired, allow the designers to be designers and the developers to be developers.

Old: Every browser had its own standards of how tags and their attributes were interpreted.

New: Every browser still has its own standards of how tags and their attributes are interpreted, but it's a lot better and tons more consistent than it used to be.

Old: 99% of all web sites looked the same, like crap, because although lots of people kinda sorta knew HTML, coding a site consistently pretty was a lot of time and effort, most of the time, prohibitively much.

New: Lots of sites still look like crap, but at least they're their own unique brand of crap. Seriously, web sites have gotten generally much prettier, and most importantly, easy to use because of CSS and, yes, Javascript. Simple example: I use Gmail as my e-mail client now. Without CSS and Javascript (and a related subject, AJAX), there wouldn't be a chance in hell of using a web application as my e-mail client. And before too long, it looks like Google is going to have some really nifty other office-type applications. And Google's not alone.

I could go on, but do I really have to?

Look, CSS isn't perfect, there still needs to be some work done both by the W3C and especially the browser developers to make it reach its ultimate goal of separating content from presentation. But the fact that it has a few downsides doesn't take away from how much better the world of the web is now than it used to be.