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?

[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?

[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?

[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:Am I the only one

[moore.dustin]

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

Re:Xforms.

[Anonymous Coward]

Wasn't Xforms suppose to take care of this?

No. XForms separates the form's data model from the markup. It allows you to mark up forms as you see fit, rather than grouping them into one element arbitrarily. It's a similar effect to the separation of content and presentation that CSS allows, but smaller in scope and applied to a different area.

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: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

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

Re:Xforms.

[Anonymous Coward]

Provides better validation abilities too.

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