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?

[CraniumDesigns]

i bought this book a couple weeks ago. it is very good. shows you specific ways of doing things, special tips, and is basically just a very nice book that can be applied to real world specifics and give you new ideas for your own designs. we're definitely not going back to tables. i for one love css as it makes for cleaner code and is much more accessible for mobile users.

Re:Learn CSS from a book?

[CastrTroy]

I agree. One example (although not related to CSS) is how many PHP+MySQL examples you'll see where they're using queries constructed at run time and not prepared queries (prepared queries stored procedures). Personally I think that people shouldn't be using mysql_* and should be using something like PDO to make your code a little more database agnostic, but that's just me. Many of the examples you find on the net are just crap tutorials written up by people who are just starting out programming, saw some other really bad tutorial, and wanted to show of their 1337 skillz.

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?

[falconwolf]

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

While learning by doing may be the best way to learn, many still need a physical book they can use. I find it much easier to have a book I can look at, read, while I am working on something than not having anything. As for usng resources on the web, it's easier for me to have a printed page than to try to switch between a text editor, a browser window that what I'm working on is displayed on, and one or more windows of pages on what I'm trying to learn. Using one monitor it may take a little tyme to switch between and find the correct window. With a printed page though I can look at the page as well as a document I am working on at the same tyme. And it's cheaper than having more than one monitor.

Falcon

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.

Re:Learn CSS from a book?

[valmont]

someone please mod parent up.

Re:Learn CSS from a book?

[VGPowerlord]

I agree, mod grandparent up.

Re:Learn CSS from a book?

[Anonymous Coward]

well, well...make a stupid comment and get modded down. Funny how that works.

parent poster basically rephrased grandparent. mod that up for what reason?

Re:Learn CSS from a book?

[booch]

Try finding really good resources on liquid css tableless designs with code for cross browser support. Yeah, I was trying to find a 3-column liquid CSS design the other day, and still can only find 1 that works with any of the columns as the longest, and with background color extending all the way down. It's the same one I've found a few times, but surprisingly, I haven't found anyone else doing it.

Re:Learn CSS from a book?

[Aliriza]

Yes also buying a book motivates me , It is just the begining and there as a reference , If I need something it is easier to search.

Everyone's a critic.

[cromar]

Good opening and closing paragraphs, but the descriptions of the chapters are somewhat repetitive and without much actual content.

I would like to know more about CSS, but I can't get a good sense of the quality of this book from the review.

Re:Everyone's a critic.

[e9th]

Yes. This read like a high school book report.

Re:Everyone's a critic.

[fbjon]

Good opening and closing paragraphs, but the descriptions of the chapters are somewhat repetitive and without much actual content. I would like to know more about CSS, but I can't get a good sense of the quality of this book from the review. Brings up an excellent point, but introduction is plagued by choppy grammar. Also, not constructive enough critique.

I'd like to read the entire review, but I can't get a good sense of its quality from the parent post.

Re:Everyone's a critic.

[Anonymous Coward]

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

Re:Everyone's a critic.

[nateklaiber]

Cromar,

Thanks for the feedback.

This book really is more of a cookbook of sorts. I don't think it really teaches the intricacies of CSS, but helps extend CSS for those who are already very familiar with it. I definitely have some other books that I would recommend if you are interested in learning CSS.

This book was a quick read, and with multiple authors the chapters were not very lengthy. I tried to give a brief scan of each chapter with some insight to what the chapter covered. If I were to go into too much detail, I would be re-writing each chapter. The chapters also consisted largely of code examples which take up a good chunk of space.

Feel free to contact me if you have any specific questions. I have found that I can't please everyone with my reviews. You said there wasn't enough, while others in this thread said the review was too long. I want to find a good balance so I really do appreciate the critique.

Re:Everyone's a critic.

[juiceCake]

I cannot recommend enough, Web Standards Solutions by Dan Cederholm, and CSS Mastery, by Andy Budd (with others.) Excellent examples, reasons listed for the methods used, possible problems, and browser issues. Beautifully written with very nice and simple examples. The fundamentals done right in my opinion.

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

[BigBadBus]

Which one? Las Vegas, New York or Miami? :)

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:CSS gives me a headache

[roedelius]

how anyone can develop for the web without immediate access to IE6 for constant debugging/testing is beyond me. IE6 is the dominant browser. an XP OEM license on eBay is $90 bucks, well worth the cost if your situation is as bad as you make it sound.

CSS

[kevin_conaway]

Was anyone else (I'm talking to you Slashdot) put off by the reviewers writing style (you know what I'm talking about)? I found it hard to read (especially considering the length of the post) when he kept deviating (yes, deviating!) from his review by interjecting his comments (and numerous they were) into the post.

On topic, I found that the Head First XTHML book to be a great introduction to CSS as well as XHTML.

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.

Re:CSS

[nateklaiber]

Kevin,
Looking back at the review now I can see my abundance of deviations. I apologize for the interjections, and hope that you can look past that and still get some information from the review.

This helps me improve my writing of reviews - so I appreciate the feedback.

I haven't checked out the Head First book yet - but it does look like it would be a good starting point. I am at the point that with most of the CSS books I have read I start to see all of the overlapping. I like books that can bring something fresh and different to the table. This is why I liked this book - it examined real world scenarios and layout options.

CSS books come in many different flavors. Some are CSS specifications broken down. Some are just explanatory of the different selectors. Some, like this book, give real world examples. And still others such as Transcending CSS, challenge you to move forward in your designs.

Again, thanks for the critique.

Re:CSS

[kevin_conaway]

Sorry if I came off snarky.

I mentioned the Head First book because it lays a necessary and solid foundation in XHTML and CSS and then leaves it up to the reader to explore the obscure corners of each

Re:CSS

[Anonymous Coward]

I agree 100%.

Head First XHTML is probably the best beginners guide to XHTML and CSS I've ever read. (I was asked to review it and several others for my company's library.) It's one of the few that doesn't assume what you should know, and doesn't patronise you when teaching the basics.

Re:CSS

[Anonymous Coward]

What I find distracting (I mean REALLY distracting!) is an abundance of parenthesis (yes, parenthesis!) interrupting text!

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

Am I the only one

[Anonymous Coward]

...who's sick to death of CSS?

CSS seems to be nothing more than a way of making life easier for Webmasters, while making life suck for the actual consumers of web content.

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.

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.

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.

Seems like we'd just gotten away from "This Site Best Viewed At 800x600"... only to get back to "This Site Best Viewed At Two Font Sizes Smaller on 96-DPI monitors running at 2048x1536, Because The Web Designer Built It On A 72DPI monitor, But The Other Guy's Websites All Have To Be Two Font Sizes Smaller on 72-DPI 21-inch monitors running at 1280x960 Because The Website Designer Had A 2048x1536 96DPI monitor When He Wrote It".

The point of CSS was to get away from that bullshit, not make it more firmly-entrenched.

Re:Am I the only one

[moore.dustin]

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

Re:Am I the only one

[TheRaven64]

If your web server is set up correctly, it will set the caching headers for CSS to a large TTL so that you can grab the CSS quickly from your web proxy, or keep it in your browser's cache. This means you only download the presentation information once every few days, rather than every single page view.

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

[Anonymous Coward]

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

Way to confuse "on" with "with".

Re:Am I the only one

[Falesh]

Dredging up bad practice and pinning it on CSS is just daft.

Re:Am I the only one

[Anonymous Coward]

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

Assume 20 resources on a page, one

If you have the HTML and 19 images, then 19 times out of 20 you'll get the HTML and 18 out of 19 images. Graceful failure 19/20 times, reload (no HTML) 1/20 times.

If you have the HTML, 4 stylesheets and 15 images, then 25% of the time you'll get nothing worth rendering, and it doesn't matter how many images you got. Graceful failure (HTML+4/4xCSS, 14/15 images) 75% of the time, Definite reload (no HTML) 5% of the time, graceless failure (HTML+3-of-4CSS), also necessitating a reload, 15% of the time.

> > Javashit is a security risk.
>
>Competent developers don't do that sort of thing, despite using the same new technology.

I'm not talking about the developer. I admit that CSS makes life easier for the developer. I'm talking about the end user. From a security perspective, the user has no way of gauging developer competence until he/she visits the webpage, at which point the damage is done. The only safe thing for the user to do is turn off the feature that enables the vulnerability. Or did you think people wrote things like Noscript, Flashblock, and so on for the fun of it?

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

Then why, after 10 years (and dozens of display resolutions, and regular web browsing on four operating systems) of never, having to manually change the font size of rendered HTML, am I now having to hit and Ctrl-plus once on Slashdot (since its CSS redesign a year or so ago), Ctrl-plus twice on Wired (for the past few months), Ctrl-minus twice on Fark (but only once on my other box with the 72dpi monitor at 1600x1200, to get the same goddamn font), and I'm still figuring out what to do with Digg this week?

Suppose the bitmaps for "10-point" Helvetica at 72DPI are easier on the eyes than their "12-point" equivalent. Just because 96/72 is 1.33333 doesn't mean I want to see that font rendered as 13.3333 points. I don't run at 1920x1200/96DPI because I want the same amount of text (but rendered across more pixels) than I had 1600x1200/72DPI, I run 1920x1200/96DPI because I want more of the text, at the same (pixel-by-pixel) size on my lower-end monitor.

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

The problem is that CSS enables as much idiocy as it prevents. A monitor isn't a piece of paper.

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

[Anonymous Coward]

Declared font sizes in pixels so that they merge with the styling background images correctly (our buttons are plain text in table cells with background images).

At least the font sizes are fairly large: 18-30 pixels tall.

My screen is 1024x788, and spans something like a 30 degree angle (dpi is meaningless).

Re:Am I the only one

[uhlume]

Your comments re: DPI differences make it clear that you don't know the first thing about CSS. Nice troll, though.

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.

Re:Am I the only one

[Anonymous Coward]

Wank wank wank, ooh "Javashit", aren't you professional? Cranky boy needs a nap?

CSS is resolution independent, fucknut.

Re:Am I the only one

[Anonymous Coward]

Assume 20 resources on a page, one

If you have the HTML and 19 images, then 19 times out of 20 you'll get the HTML and 18 out of 19 images. Graceful failure 19/20 times, reload (no HTML) 1/20 times.

So basically, what you are saying is that you aren't counting missing content as failure, but you are counting missing style as failure? Don't you think that's a bit backwards?

Have you missed the fact that all those external resources - that you demonise in CSS' case - are responsible for bringing down the likelihood of the HTML itself failing? If it's a beneficial effect, why aren't you counting that in CSS' favour? It sounds like you're biased.

Can you just clarify whether you actually see a 5% failure rate for HTTP requests or if you made that up as a pathological example? Do you really think it's wise to judge technology based upon cases that are far outside the norm?

If you have the HTML, 4 stylesheets and 15 images, then 25% of the time you'll get nothing worth rendering

If the page content without stylesheets isn't worth rendering, then the web developer is incompetent. And there's simply no need for four stylesheets for the vast majority of websites. You are describing either pathological cases or the result of incompetence.

I'm not talking about the developer. I admit that CSS makes life easier for the developer. I'm talking about the end user.

No, what you are doing is describing the negative effects that the end user experiences, and blaming that on the technology, despite the fact that the problems were caused by something else entirely.

Then why, after 10 years (and dozens of display resolutions, and regular web browsing on four operating systems) of never, having to manually change the font size of rendered HTML, am I now having to hit and Ctrl-plus once on Slashdot (since its CSS redesign a year or so ago), Ctrl-plus twice on Wired (for the past few months), Ctrl-minus twice on Fark (but only once on my other box with the 72dpi monitor at 1600x1200, to get the same goddamn font), and I'm still figuring out what to do with Digg this week?

Because a) you were fine with the font size that was trendy with designers a decade ago and b) you aren't fine with the font size that is trendy with designers today.

Ten years ago, it was common to have designers ignore the wishes of the end user and reduce the font size with HTML. These days, it's common to have designers ignore the wishes of the end user and reduce the font size with CSS. The technology doesn't matter. The difference you are seeing is that tiny font sizes are trendy, whereas a decade ago it was merely small font sizes that were trendy. Force a web designer from today to design with nothing but HTML, and you know what he'll do? Use <font size=1>. And you'll still complain about the font size because it's not the technology that matters, it's the intent of the designer that matters. It was always possible to create stupidly small text, it's just that it's taken a while for the insanely end-user hostile designer attitude to permeate the industry.

The problem is that CSS enables as much idiocy as it prevents. A monitor isn't a piece of paper.

No, the problem is incompetence. There's no make-this-unreadable: extra-web-2.0 !important CSS property, the defaults are sensible and CSS is explicitly designed for end-user control. The problem is that designers are choosing to make their designs this way. Sure, with one hand tied behind their back they aren't able to fuck things up in precisely the same way as they can today, but that's not the point is it?

Re:Am I the only one

[Sancho]

'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. While the rest of your rebuttal to the troll was spot on, this one is simply bullshit. Javascript allows for flashy cross-platform software applications. CGI was done long before AJAX, DHTML, and Javascript.

But I think that the point he was making was more that requiring Javascript just to pull down the right stylesheet sucks. There are lots of good reasons to disable Javascript (mostly security-based) and requiring it for site functionality sucks, particularly when all you're doing is displaying content (rather than really interacting with the user).

Re:Am I the only one

[nbert]

Javashit is still a security risk, but we'll make damn sure that none of our content renders correctly unless you turn it on That's not really a problem related to css. You should rather blame those using JS to solve browser issues. If you need seperate stylesheets for Firefox and IE you can use comments:

<!--[if IE]>
<link rel="stylesheet" media="screen" href="/css/ie.css">
<link rel="stylesheet" media="print" href="../css/ie_print.css">
<![endif]-->

Firefox won't load it, but it recognizes import (as opposed to IE). Of course this is not really the most beautiful way to do it, but it avoids CSS hacks and javascript.
However, if Safari and Opera are in the mix, this solution won't work. On the other hand I don't know of any website using scripts for css which actually cares about those...

Re:Am I the only one

[suv4x4]

Am I the only one ...who's sick to death of CSS?

I'm working with CSS for years and yes I'm sick of it. But I'm more sick of your short post, than my years of CSS.

That should speak volumes. There's basically almost nothing correct in there, and if there is, it's well hidden between a myriad of wrong assumptions, outright lies and poor understanding of web technology. Sucks for you.

Re:Am I the only one

[Anonymous Coward]

Informative?

Try Funny.

This is totally wrong, but /IS/ rather funny.

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.

Re:Am I the only one

[tksh]

Ah, so in summary, you're sick of web designers who claim to know CSS but really don't.

Seriously, the problems you described echo of my experience six years ago when we had Netscape 4 and IE5. A lot of plain bad designers were trained back then and if you visit the sites they design now, yeah, you're going to run into the same experience. The good designers use ems and grid layouts for sizing, specify font-families nor use JS browser detection for stylesheet loading.

Re:Am I the only one

[Anonymous Coward]

> Can you just clarify whether you actually see a 5% failure rate for HTTP requests or if you made that up as a pathological example?

For the record, I've seen it once or twice; usually it was flaky DNS and a client that didn't cache properly. If you can't resolve images.slashdot.org, for instance, you have to wait a second or two until you can resolve it. Telling the browser to cache CSS pages "for a long time" doesn't often help, because in the event of failure, all that got cached after the delay is "503 - there ain't no images.slashdot.org", and if the DNS failure was transient, that's worse, because, the browser isn't necessarily gonna retry!

But to answer the meta-question, yes, it was brought up as a pathological example to illustrate the principle that requiring dozens of TCP/IP connections to multiple hosts (www.foo.com, images.foo.com, css.foo.com, a dozen "providers" of ads, assuming those aren't already pre-emptively blocked) equals more ways for things to fail.

> Because a) you were fine with the font size that was trendy with designers a decade ago and b) you aren't fine with the font size that is trendy with designers today.

That'd be fine! Tongue-in-cheek, I'd just make it "one <font size> smaller" or "one <font size> bigger". It seems that what's trendy with designers today is either (a) fonts that render as 4x6 pixel globs, or (b) font choices that show up as 8x12-pixel hugeness (1920x1600, 96dpi), with no middle ground. What's trendy with designers seems to be "whatever's either too big or too small, use anything but the default!", which makes no sense to me.

> No, the problem is incompetence. There's no make-this-unreadable: extra-web-2.0 !important CSS property, the defaults are sensible and CSS is explicitly designed for end-user control. The problem is that designers are choosing to make their designs this way. Sure, with one hand tied behind their back they aren't able to fuck things up in precisely the same way as they can today, but that's not the point is it?

No argument there. Georgia's a great font, but I'd rather see things fall back to Times Roman, where at least it looks half-decent at all sizes on all platforms. This guy's rant from 7 years ago puts it better than I did.

Here's another article with some screenshots that illustrate the problem. Those screenshots don't look too bad... but the differences would be greatly magnified at even one "font size" smaller. Augh.

Re:Am I the only one

[nateklaiber]

The only issue I have with conditional comments is that they are proprietary to MS and they are embedded in the markup. In most cases I will have a default.css, which in turns uses @import for my typography, color, layout, reset, and hacks. Yes, I compress and combine when necessary. However, as much as I hate hacks - I would rather manage hacks in a separate stylesheet, then add extra markup that was given to use by Microsoft due to their crappy support.

So, while it is a solution - I would rather manage all of my CSS inside of my CSS. Then, when a hack is fixed, I can remove it from the stylesheet. When all hacks are fixed I can remove the entire stylesheet - but I never had to edit the markup to remove the stylesheet or change information specific to IE.

There are pros/cons to both - I just don't like the idea of using conditional comments to achieve the task. Better yet, build your layouts so they don't require hacks. Well....that might not always be possible. ha.

Re:Am I the only one

[Anonymous Coward]

For the record, I've seen it once or twice; usually it was flaky DNS and a client that didn't cache properly.

Well then I fail to see how unreliable HTTP is relevant. If 5% of HTTP requests are failing, you've got bigger problems than stylesheets. Furthermore, if it's flaky DNS, then that means that only hosts that use different hostnames to serve their stylesheets would be affected, and only on the first visit per session. These are an extreme minority of websites.

Telling the browser to cache CSS pages "for a long time" doesn't often help, because in the event of failure, all that got cached after the delay is "503 - there ain't no images.slashdot.org"

You've missed the point. Caching means that subsequent errors are avoided. If you visit twenty pages on a site, only the first is subject to any failure. The following nineteen come from your cache and don't have the opportunity to fail because no HTTP requests are being made.

Furthermore, 503 responses aren't cacheable by default, and I've never seen any server or proxy generate 503s that also explicitly permits caching. Have you ever seen a cached 503 response?

But to answer the meta-question, yes, it was brought up as a pathological example to illustrate the principle that requiring dozens of TCP/IP connections to multiple hosts (www.foo.com, images.foo.com, css.foo.com, a dozen "providers" of ads, assuming those aren't already pre-emptively blocked) equals more ways for things to fail.

This is not typical behaviour though. The multiple hostname trick is a workaround for a limitation in the HTTP specification, not a failing of CSS, and it's used on a minority of sites to speed up access. It became popular around the same time as CSS because broadband connections started pushing the limits of HTTP at around that time.

Being able to think up a bizarre scenario that bears absolutely no relation to typical end-users simply isn't relevant. Perhaps if a significant portion of your users all had flaky connections it would be different, but even you, the person coming up with this example, can only manage "I've seen it once or twice".

You don't optimise for improbable scenarios. You optimise for the common case and make sure that reasonable improbable situations don't fail horribly. A broken net connection that fails 5% of the time is not reasonable to cater to, especially when it slows down access to your website for virtually everybody else, not when it slows down your developers, and not when it increases the amount of bandwidth you use.

No, there aren't "more ways to fail". There's one way to fail - failed HTTP requests. And if you're seeing that, then your web surfing problems are far worse than the odd stylesheet going missing and you shouldn't expect all the websites in the world to work around it for you.

What's trendy with designers seems to be "whatever's either too big or too small, use anything but the default!", which makes no sense to me.

Ditto. This has been true for longer than CSS has existed and is technology independent. Take away CSS and the problem would remain.

Re:Am I the only one

[Verte]

What you miss is that NOW, you can turn it off, all by removing a file. Before, attributes were all part of the HTML. If it looked like crap on your machine, you were stuck with it.

Re:Am I the only one

[SirJorgelOfBorgel]

Christ, you have to upgrade to IE7 just to get transparent PNGs to work correctly (unless you work around it). Yeah, if only transparent PNGs worked correctly in IE7, that would be true.

To list 3 of the (for me) most annoying issues with transparent PNGs in IE7 (I can probably think of about 10):
1) Transparent PNGs (image tag, not background) of 1x? can rotate CCW 90 degrees for no apparent reason. This will cause other transparent PNGs to not be shown at random (some will, some wont). (NB: This seems to be a Vista specific IE7 problem, it does not happen on XP SP2)
2) Same PNG construct as (1) absolutely positioned with height 100% may result in a random height (usually in the 100k-px), results vary with every refresh. This can really mess up a page. (Does not happen with non-transparent PNGs)
3) You cannot use the Alpha filter (shame on MS for not implementing CSS::opacity in IE7 in the first place) on transparent PNGs in IE7 natively, unless the element that has the Alpha filter applied (which may or not be the IMG element or any other element with the transparent PNG as background) - or any other element between that element and the one displaying the PNG - has a non-transparent background-color or background-image. The result is that any pixel which is not fully transparent or fully opaque, will become black. The workaround? Don't use the PNG 'IE7-native', use the AlphaImageLoader filter instead (this and Alpha filter together, make websites need a special style sheet for IE6 AND IE7, apart from the style sheet for real browsers).

Read http://blogs.msdn.com/ie/archive/2005/04/26/412263 .aspx for some implementation specifics on PNGs in IE7. The author (one of the IE7 devs) pretty much admits IE is not built to handle per-pixel transparency.

In my experience, it's best to simply treat IE7 exactly the same as IE6 for PNG images, at least then you know it works. (In other words, if you're planning to do anything neat, dont use IE7s 'native' PNG, just use AIL as with IE6, it actually works better)

Let's just face it. IE is a disease. Newer versions may fix some things, but I truely believe that every new IE version just adds another style sheet with accompanying conditional comments, and IE will never really work as any of the 'real' browsers. I wish the IE dev team would just pull something like: HTML document has doctype ? use-webkit : use IE6-engine. At least then the web would be able to move forward. I for one are sick and tired of building something for FF, having it work in every other browser on every other platform I have access to, but having to make significant changes (i.e., add special stylesheets and javascript) to support IE6 and even 7. Sure, 7 has LESS issues than 6, but it's still a piece of crap code that should never have been released.

Re:Am I the only one

[ErikZ]

IE7 is awesome compared to IE6. The problem is that IE6 will be around for a long, long time, so you still have to program your pages for that broken-ass piece of shit.

What's IE6 % now? I think it was 50% of browsers last time I checked.

Re:Am I the only one

[markandrew]

in answer to your question: yes, you are the only one.

but thanks: i didn't think such a drastically bad understanding of how HTML/CSS works was possible. i stand corrected.

Re:Am I the only one

[nbert]

I agree that they are not the most beautiful solution for this problem. On the other hand I hate declarations such as "*/#..." even more because they are not even proprietary solutions, but plain hacks. Those Tags sometimes even solve problems which are Firefox related. I recently had to give Firefox users a link to a printable version of pictures displayed in flash - Firefox justs cuts them in half when printing, even though they are displayed correctly on screen. IMHO it's better to define two stylesheets than to just fill one with CSS code which two browsers will interpret differently...

Xforms.

[Anonymous Coward]

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

Wasn't Xforms suppose to take care of this?

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

[Anonymous Coward]

Provides better validation abilities too.

Re:Xforms.

[VGPowerlord]

Unfortunately, it sends data as XML instead of as a query string (which regular forms do even via POST). This is probably what's kept it from catching on.

Notable absence

[Dancindan84]

They forgot to remind everyone to run with their knives out.

Word

[everphilski]

I admit I'm a bit of a hack, helping someone out with a web site, and a c++ coder by day... yeah... all of a sudden sh*t stops working, and I didn't edit the code! I just added comments! wtf... 20 minutes later I figure it out. Sadly this happens multiple times :P

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

[everphilski]

for some reason my copy of vim isn't syntaxing it ...

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.

get this

[Anonymous Coward]

if you've got half a brain then go learn flash/flex2.
bit more tricky than css but then it isn't crap.
end of.

Perhaps IEs4Linux?

[Anonymous Coward]

If it's Linux you're running, this: http://www.tatanka.com.br/ies4linux/page/Main_Page might help.

It's not always "exactly as seen in Windows", but you can get 90+% there before sending your page off for rendering.

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

[Anonymous Coward]

It also makes your stylesheet reliant upon JavaScript. If you don't mind your pages falling apart when JavaScript is not available, then go ahead.

Re:Easy solution

[The One and Only]

Would they fall apart full stop, or just on IE? If they only fall apart on IE if JavaScript is somehow not turned on in IE, I'm hardly going to cry.

Re:Easy solution

[VGPowerlord]

Like it or not, IE is still the majority share of the browser market.

If even 5% of IE users disable Javascript, that's still a larger market share than the number three (Safari) and four (Opera) browsers combined.

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

[Anonymous Coward]

You're assuming that the only way in which JavaScript can be unavailable is if the user switches it off. What about well-intentioned relatives who know that you won't stop using the big blue e? What about corporate proxies? What about just plain screwing around in the settings without knowing what you are doing?

Re:Easy solution

[The One and Only]

I think you've narrowed it down to a sufficiently tiny subset there.

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

Re:Easy solution

[Anonymous Coward]

You think corporate filtering of JavaScript and group policies disabling JavaScript are a tiny subset? Get more experience.

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

[VGPowerlord]

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.

This is a bad example, because there is a tag/attribute combination in HTML4 to apply attributes to an entire column in a table. Example: <col align="center">

... wait for it ...

The catch is that Firefox and Safari (and possibly KHTML itself) don't support it.

Not sure you're actually familiar with CSS

[weston]

It ain't perfect, and in fact, in some cases, it's a pain, but your points don't seem like the reasons why.

CSS seems to be nothing more than a way of making life easier for Webmasters, while making life suck for the actual consumers of web content.

Actually, sometimes it makes life *harder* for webmasters, especially if they've drunk the table-free layout kool-aid.

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.

Don't know which ISP you're using, of course, but I'm not even sure I see anything like this even 1% of the time for CSS. And seeing css files loaded from other servers? Also rare. And you get the advantage that layout/styling code put in the css file only has to be loaded once.

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.

Are people really using Javascript detection? Most of the discussion and practice I'm familiar with focuses on:

(a) Using filter hacks to target browser specific CSS (sparingly)
(b) Making sure the actual content of the page is viewable/readable even if the stylesheet isn't used for some reason.

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.

CSS can be used to fix fonts at the wrong size. It also has all the tools for picking font sizes the old method had and a few new ones with relative sizing merits.

Now, I think CSS is a pain for layouts. For some reason, the observation that there's a use for semantic tabular markup seems to have blinded the w3c and others involved to the fact that tables are a great tool/concept for layout. The differences IE has from the spec are a royal pain (though I have to say that IE6's box model actually makes more sense than the CSS 2.1 spec's, so much so that I'm glad they didn't use follow spec there, and the day I can actually choose it via CSS 3 won't be a moment too soon). The fact there's no easy CSS way to center an item in a container element sucks (and please don't point me to the hacks that require knowing the height of either element or javascript stuff). Waiting until css 3 to allow multiple background images on an element was shortsighted. I could go on.

However, I'd rather have all of this than go back to HTML 3.2. The markup is cleaner and easier to edit, it's genuinely smaller, it's easier to make global changes, and some layout and decoration tasks are just, plain and simple, easier because of it. Remember the days where if you wanted a bordered box you had to barf out a 9-celled table?

<div style="border: 1px solid gray"> content here </div>

over:

<table border="0" cellspacing="0" cellpadding="0">

<tr><td bgcolor="gray"> </td> <td bgcolor="gray" height="1"> </td> <td bgcolor="gray"> </td></tr>

<tr><td bgcolor="gray" width="1"> </td> <td> content here </td> <td bgcolor="gray"> </td></tr>

<tr><td bgcolor="gray"> </td> <td bgcolor="gray"

Snook not Snooks

[dabbaking]

The guys name is Jonathan Snook, not Snooks. Snooks sounds like a tasty treat!

Re:Snook not Snooks

[nateklaiber]

They have had it that way on Amazon since the book started shipping. In fact, they had him listed as 2 authors - Jonathan Snooks and Jonathan Snook. I would have thought it would have been corrected by now. Or - snook has a double personality.

Am I the only website?

[Anonymous Coward]

"Christ, you have to upgrade to IE7 just to get transparent PNGs to work correctly (unless you work around [howtocreate.co.uk] it)."

And just how many websites use transparent PNGs (let alone PNGs in general)?

Re:Am I the only website?

[slughead]

And just how many websites use transparent PNGs (let alone PNGs in general)?

Well, to start off, this website uses PNGs.

Transparent PNGs are AWESOME. They're they only way to overlay alpha graphics in web pages. They allow you to save time both in writing the page and loading it if you want to have a neat looking page.

Say you have a website with a repeating pattern for a background and you want a foreground image to perfectly blend in with that background. Without transparent PNGS, you can use GIFs--whose pixels can either be "opaque" or "transparent", no translucency allowed--or you can make a huge image with both the background pattern and the overlay image combined, which would take forever to load.

Not many websites use transparent PNGs as a direct result of IE6 not directly supporting them. There is no reason, other than IE6, that transparent PNGs are not more common.

On some of the pages I've made, I've gone through great lengths to make alpha PNGs work in IE6 because they are just that useful. Ironically, it was Apple who discovered the best way to fix PNGs in IE (using CSS and a .htc file), here is something based on that, which I use on most of my sites.

I liked the approach

[deanoaz]

I just finished reading the book today. I haven't tried implementing the stuff in it yet but I'm excited about some of it.

What I really liked about the book is how they specifically discussed how different browsers (Firefox, Opera, Safari, IE6, IE7) react to the code and how to make their tricks work across them in spite of most issues. They show example renderings for the different browsers at intermediate stages of some of the design work and explain what's going on and what it will take to fix it for a specific browser (almost always IE).

I've read CSS books in the past that showed me some cool trick I wanted to do and then it took me forever to find (on my own) some way to get it to work across the browsers I was interested in. (or else I gave up trying)

CSS - isn't that for DVDs

[gfim]

I hope the book tells us what CSS stands for, cause the review sure didn't! Seriously, there are two common uses of CSS here on SlashDot. Why not tell us which one it is?

Re:CSS - isn't that for DVDs

[RDW]

Not sure about DVDs, but they definitely have a CD:

http://www.myspace.com/canseidesersexy

Hope this helps.

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.

Mod parent up - Informative. Stop modding GP.

[__aawkdb2598]

I stand corrected. Thanks for the correction, and may you be favorably moderated. :)

Re:Mod parent up - Informative. Stop modding GP.

[Carewolf]

Actually you are both right. W3c has just chosen a more international definition of 'em' for CSS than what it originally meant (imagine a font without the letter 'M'). For most fonts the two methods usually produce the same result.