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?

[dthable]

Nor will reading a book make you cry trying to cope with the different implementations in different browsers. I'll assume this book does what most do and just sticks to the CSS specs.

Re:Learn CSS from a book?

[mytrip]

A lot of the examples on the web are garbage. Try finding really good resources on liquid css tableless designs with code for cross browser support. It's a pain to find exactly what you want in many cases.

Re:Learn CSS from a book?

[CastrTroy]

A book can be a very good resource. While learning by doing is definitely the best way to learn CSS and many other technologies, having a good reference book can be nice. Having a book that guides you through different examples can really help. I recently learned Regular Expressions by reading O'Reilly's Mastering Regular Expressions. While I didn't "Master Regular Expressions" by just reading the book, it gave me a nice starting point, and it's a great reference when I'm coding.

Re:Learn CSS from a book?

[MyLongNickName]

It depends. If it is theory, I like a book. It gets me away from a PC where I am in a coders mentality. If it is coding, then I agree online is the way to go.

BTW, too many coders consider themselves programmers...

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?

[shadowrat]

I agree you can't learn CSS without "doing". I'm not sure a book is going to hamper someone trying to learn CSS. The tutorial is either read from a web page, or a printed page. It's still up to the reader to roll up their sleeves and do what they read.

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.

CSS gives me a headache

[also-rr]

Not the actual CSS which is, with five minutes of practice, very easy to use. Much better than tables all over the place. The headache comes from IE dang 6 and below.

Since I can't legally test in IE6 (no Windows license, and browsershots.org takes a 4 hour round trip for Windows screenshots) making IE6 specific tweaks is a pain in the backside. I'll finish up eventually I'm sure, in the mean time I plan to just turn off CSS for those users.

As a side note CSSED is really nice for those of you who like editing their CSS by hand.

Re:CSS gives me a headache

[Anonymous Coward]

http://ipinfo.info/netrenderer/index.php

Check that place out. It'll render in all versions of IE, it's free, and it's reasonably fast.

IE6 and below *IS* a pain in the butt, I totally feel your pain. I've had many a (LITERAL) headache from wrangling the box model with its hacky display.

Re:CSS gives me a headache

[Anonymous Coward]

Of course, you don't need a separate Windows licence to test Windows/IE6. MS makes a VM available:
http://www.microsoft.com/downloads/details.aspx?Fa milyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displa ylang=en

Okay, it's a VPC image, but even if you're not able to run VPC then you can convert it to a VMWare image...

Re:Everyone's a critic.

[e9th]

Yes. This read like a high school book report.

Re:CSS

[Falesh]

Agreed, it is a cracking book that sets you on the right path. After that you can learn extras from sites like A List Apart, CSS Beauty, css Zen Garden, etc.

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".

Re:Am I the only one

[moore.dustin]

Way to confuse bad web masters and design on the language.

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

[Anonymous Coward]

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.

Wait, what ISP are you using that fails for one in twenty requests? Assuming an average of four external resources on a page (a low estimate for images alone), that means one quarter of all of your page loads are failing in some way already. Really?

New: Download a hunk of HTML. Download a separate .css file, or two, or three, or four,

Don't blame CSS for web developers doing a shitty job.

sometimes from the same server, other times from some other server.

Don't blame CSS for the connection limit HTTP imposes.

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.

External resources are hardly a new thing that CSS brought about. External resources have been present since Mosaic times (e.g. images).

If web developers wanted to, they could stuff the CSS into the page itself and avoid the external resource fetch. But that's actually counterproductive for most users. Why should web developers punish the majority of their users in order to work around problems you are having with your shitty ISP?

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.

Aren't you forgetting something? Those figures are only for the first page load. Because stylesheets are shared between pages, they don't have to be fetched for subsequent page loads. As long as you visit more than one page on a site, you end up downloading less data overall.

Old: Javashit is a security risk.

How mature.

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.

Like I said before: don't blame technology for what happens when idiots get hold of it. You're complaining about stupid, ignorant web developers, not the "new way of doing things". Competent developers don't do that sort of thing, despite using the same new technology.

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.

Rose-tinted glasses. <font size=2> was incredibly common, and designers didn't know any more about end-user devices than they do today.

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.

Again, this is caused by incompetence, not technology. Noticing a theme yet?

Sick to death of CSS? No, you're sick to death of incompetence. Don't lump everybody using CSS in with those kinds of idiots. The problems you describe aren't caused by CSS, they are caused by idiocy.

Re:Word

[CastrTroy]

Why not just use an editor that supports code highlighting. That way you'll be able to see that the stuff you just typed in isn't comments.

Re:Everyone's a critic.

[Anonymous Coward]

Yes. This read like a high school book report. Hey, my teacher liked it.

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.

Re:Am I the only one

[__aawkdb2598]

An 'em' is the width of one character 'm'.

Thus:
'1 em' is this wide: m
'3 em' is this wide: mmm

It's a pretty good metric.

Re:Am I the only one

[theuedimaster]

Wow... you've got it all wrong buddy.

CSS brings an amazing number of options to the table, and it most certainly does not limit your ability to make a site that is very accessible. Sure, the ability to change so many options does incur a greater possibility of someone making a mistake - but that's not the problem with CSS, that's a problem with the person writing CSS.

You are right about CSS making web-dev much easier for those writing the code. For the same reason that OO is nice, the separation of the old HTML into a few distinct parts is much cleaner and easier to write. As well as that, it makes updating amazingly easy. By having so many parts, it's also easier to find errors - since it's so much easier to now narrow down things.

Haha, and a browser detection script? If you're using that, then you know your website is a little outdated (especially if you're using it to choose stylesheets - with ajax, I can understand). But even if you were going to do one, a good web-developer will have fallbacks that the website can safely ease into if there is no js.

And about the many files thing, welcome to the new world. People have faster internet connections, more reliable connections, and can refresh very easily. I know that's a dangerous mindset to have, but forget it, sometimes you have to take a step forward. And the increase in probability that the site won't go through is negligible sir.

Easy solution

[Penguin Programmer]

Write your pages for mostly-standards-compliant browsers, then use http://dean.edwards.name/ie7/ to make them look right in IE. Sure, your pages will take an extra few tenths of a second to render in IE, but it saves you hours of fucking around to make it look right.

Re:Easy solution

[The One and Only]

If you're savvy enough to disable JavaScript, are you going to be using IE? I don't think so.

Re:Easy solution

[VGPowerlord]

The last time I used IE, disabling Javascript happened automatically if you went into Internet Options, Security, and moved the security slider up to High. It's not exactly hard, particularly if you have people who dink around in the options panel.

"Oh, high security? I'd better turn that on!"

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.

Re:Am I the only one

[MP3Chuck]

No.

The 'em' unit is equal to the computed value of the 'font-size' property of the element on which it is used. The exception is when 'em' occurs in the value of the 'font-size' property itself, in which case it refers to the font size of the parent element.

Source: http://www.w3.org/TR/REC-CSS2/syndata.html#length- units

You're confusing em with ex, whereby 1ex == 1 x-height of the current font size at its current size.

Your

[FishWithAHammer]

I feel that p3d0's post is perfectly understandable, though the author nit-picks at Cromar's post in a way some might find natty and irksome. I would recommend it to anyone thinking about reading Cromar's post.