Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

CSS Cookbook 121

Michael J. Ross writes "Anyone involved with the coding of Web sites likely knows that Cascading Style Sheets (CSS) should be used for styling the content of their sites' pages — setting text sizes and fonts, setting background colors, sizing margins, positioning images, and more. CSS allows the Web developer to specify the visual appearance of the site, separately from the HTML, and thus to be able to make changes in the future within a single stylesheet, rather than hunting through the HTML and modifying every occurrence of each affected element. The benefits of CSS are many, but so too can be the frustrations when the developer turns for help to CSS books heavy on theory and light on practical explanations. For every Web site 'cook' feeling the heat in their cyber kitchen, there is an ingredient that can help: CSS Cookbook." Read the rest of Michael's review,
CSS Cookbook
author Christopher Schmitt
pages 538
publisher O'Reilly Media
rating 8
reviewer Michael J. Ross
ISBN 0596005768
summary Practical solutions to common CSS challenges


Written by award-winning Web designer Christopher Schmitt, this book is published by O'Reilly Media, under the ISBN 0596005768, and is in its second edition, having been updated for Internet Explorer 7 and Firefox 1.5. The book has its own Web page on the publisher's site, offering the book's table of contents, the index, Appendix D ("Styling of Form Elements," in PDF format), and links for reading and submitting book reviews/comments, as well as reading and reporting errata (there are none, as of this writing).

The book's 538 pages are organized into 12 chapters, which cover the major areas of interest to the Web developer: CSS overview, typography, images, page elements, lists, links and navigation, forms, tables, page layouts, printable pages, hacks and workarounds, and design considerations. Appendix A briefly describes some of the better online CSS resources, including tutorials, design guides, discussion groups, technical references, and tools, such as the W3C validators. The next two appendices cover CSS 2.1 properties, proprietary extensions, selectors, pseudo-classes, and pseudo-elements.

The fourth and last appendix, on the styling of form elements, details how 20 CSS properties affect eight form elements, as displayed within Windows Internet Explorer 5, 5.5, 6, and 7; Mac Safari 2; Windows and Mac Firefox 1.5; Windows and Mac Netscape Navigator 7.2; and Opera 8.5. The form elements considered are: checkboxes, file upload elements, radio buttons, text fields, multiple options, select elements, submit buttons, and text areas. The author does not explain exactly what page elements are meant by "File Upload" (at the beginning of the appendix) or "File Input" (the actual section title). Presumably he is referring to the file display field and Browse button, and not the file locator dialog box, which is determined by the browser and operating system. More importantly, he does not explain what is meant by "multiple options" nor "select elements," and neither term is listed in the book's index. Future editions of the book would benefit by beginning every element's section with an example, showing the code as well as the element's appearance on a Web page. Despite this obvious omission, this appendix could prove a godsend to anyone concerned with how these various types of elements are affected by CSS within these eight major browser versions. As noted earlier, the appendix can be downloaded for free.

HTML/CSS books generally fall into two broad categories: Introductory books are usually sufficient for beginners, because they cover the basics. But they are typically useless to the veteran developer who is struggling to understand why Internet Explorer is mucking up yet another page that looks fine in Firefox, Opera, and Safari — and how to work around the problem. Advanced books assume that the reader already has a relatively solid understanding of the technologies, and uses that basis as a foundation from which to explore sophisticated design techniques. But even those books prove inadequate for the developer who is simply wondering how to best use pure CSS to do such presumably straightforward tasks as positioning some images horizontally, with small captions centered underneath each one. In fact, many of those advanced books seem to have little interest in clearly explaining how the reader can do what the author has done, largely because the sample projects and their source listings are too long and involved, thus burying the critical HTML and CSS in pages of code.

There is clearly a great need for one or more HTML/CSS books aimed at the developer who already understands the basics, and wants to apply that knowledge for building robust Web pages, all while following defensible best practices. The O'Reilly "Cookbook" titles are intended to fill that gap, by presenting the material in the form of recipes, each comprising a brief statement of the problem to be solved, a summary of the solution, and a discussion of the solution's details. Oftentimes additional resources are referenced, in a "Sea Also" subsection, which might have one or more links to relevant Web sites. The discussion subsections usually have sample code, in addition to a figure showing the code's output.

Possibly the greatest benefits of the cookbook format, is that it forces the author to clearly state the purpose of each section, and then to get right to the point of how to achieve that purpose. This prevents the meandering seen in many of the advanced design books, which is the main reason why they can be so frustrating for the developer who wants to quickly find out how to perform a specific task on a Web page, such as the image positioning task mentioned earlier. Possibly the biggest downside to the cookbook format is that it results in contrived problem statements, such as the very first one in CSS Cookbook: "Problem — You want to use CSS in your web pages." Is that truly a problem? Is it not much more a goal or task, than some sort of problematic difficulty?

Yet aside from any misleading subsection titling, the recipe format does cause any (largely) expository material in a technical book to get chopped up into somewhat artificial pieces. It is more noticeable in the first chapter of this particular book, titled "General," in which Schmitt explains the fundamentals of CSS: selectors, classes and IDs, properties, the box model, style sheets, comments, shorthand properties, floating images, absolute and relative positioning, and using CSS with the more common page development tools. As the author gets into more advanced topics — for which individual subsections can stand more on their own — the recipe format works fine. One advantage is that the section titles end up being detailed enough that the reader can, in most cases, quickly find the relevant section to address their needs.

Overall, this book is a fine addition to O'Reilly's growing list of programming titles. However, like all books, it is not perfect. It does not cover all of the more common tasks that the average Web programmer might want to accomplish — but it does hit the bulk of them. Sadly, all of the figures in the book are in black and white, including those displaying colors on the sample Web pages. Shades of gray are just not optimal. Fortunately, in most cases, the crux of the technique is discernible. In addition, the sample code has too many instances where layout is achieved using tables, and not pure CSS. Lastly, the book's index — similar to that of so many other technical books nowadays — could certainly use some beefing up. After all, if the reader cannot find the desired material using the table of contents, the index is their last hope, before resorting to time-wasting page flipping.

In terms of HTML and CSS information, the topics are well chosen, and the coverage of browser hacks and workarounds is excellent. Also, the most critical parts of the code are helpfully bolded. For those readers completely unfamiliar with JavaScript, it is used only where unavoidable. The book's material is neatly presented, and the author's writing style is straightforward and approachable.

On balance, CSS Cookbook is to be recommended to any developer looking for a CSS guide that is concise, clearly written, well-illustrated, and addresses the most common challenges in building Web pages.

Michael J. Ross is a computer consultant, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.


You can purchase CSS Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

CSS Cookbook

Comments Filter:
  • by Anonymous Coward on Monday November 20, 2006 @04:28PM (#16920088)
    IE 7 was in open beta over a year ago
  • by jfengel ( 409917 ) on Monday November 20, 2006 @04:31PM (#16920130) Homepage Journal
    IE 7 had been in beta for a while. They probably had the thing printed up even before IE 7 was formally released, figuring that the last beta would look an awful lot like the final version.

    If nothing else, they'd rather be the first guys in the shelf with an IE 7 book and be wrong than the last guys and be right. An author friend of mine quit writing technical books precisely because she hated losing market share to badly-written books that came out sooner.
  • by CastrTroy ( 595695 ) on Monday November 20, 2006 @04:43PM (#16920324)
    Do people really buy the first book that comes out, or do they look at reviews and try to buy the best book? It would seem from my experience that a bad book is probably worse than no book at all, since you're getting fed misinformation, or at best spending money on something you're not using. I don't just go to the store and buy the first book I see, I read the reviews to make sure I'm buying the right one. Is this different from what the average Joe does?
  • by MikeFM ( 12491 ) on Monday November 20, 2006 @05:01PM (#16920640) Homepage Journal
    IE7 is compatible with most of the CSS stuff I use at least so usually there are only a few bugs that have to be worked out rather than the tons that I had to deal with under IE6. I suggest just making one standard style sheet that works with Firefox, Safari, and Opera, a IE7 stylesheet that tweaks the minor bugs out, and then a stylesheet for all outdated IE browsers which should make the site usable but plain. So long as the site is usable who cares if people still using IE4 like how it looks? If they haven't cared to update their browser then obviously they don't know the difference anyway.
  • by Anonymous Coward on Monday November 20, 2006 @05:22PM (#16920946)
    The problem is that like BASIC, HTML is easy to learn by tinkering, without getting a good grounding in the theory. It's possible to write good, elegant BASIC or good, elegant HTML, but there are a lot of total crap tutorials for both that get people started with bad habits early.

    Unfortunately, there are a lot of people with bad habits writing HTML tutorials too.

    One of the big problems is software developers who have a basic grounding in "bad" HTML and use it to lay out programatically generated sites. Developers in general don't want to bother to learn CSS - they seem to think it's the sugar on top - "just" a graphic design thing. So you see a lot of crap HTML work out there - and a lot of table layout.

    For a sublime, pure-CSS experience (make sure and load some of the stylesheets on the right-hand side), check out http://www.csszengarden.com/ [csszengarden.com]
  • by itlurksbeneath ( 952654 ) on Monday November 20, 2006 @05:45PM (#16921318) Journal
    And, as a followup to your question, the answer is "yes". Check out HP [hp.com] and Yahoo! [yahoo.com] in a "view source" window. Lots of "div" tags and not any "table" tags that I could see in a casual glance.
  • by Bogtha ( 906264 ) on Monday November 20, 2006 @06:04PM (#16921630)

    I don't think it is technically possible to write a completely compliant page that works in both and uses proper CSS and XHTML. I could be wrong.

    You are wrong. There are a few different factors at play here:

    1. Internet Explorer doesn't understand, and thus ignores, many parts of CSS. This doesn't affect compliance because you can usually find another part of CSS that Internet Explorer does understand, to accomplish the same effect. For isntance, Internet Explorer doesn't supprot display: table-cell, which is the easiest method of doing columns in CSS, but you can use floating elements for the same effect.
    2. Internet Explorer misunderstands some parts of CSS. This is less of a problem than it was. You'll get many people complaining about the "broken box model", but this was actually fixed way back in 2001 for those developers that don't trigger "quirks mode". Usually you use hacks - which can come in valid and invalid flavours - to supply alternative code to Internet Explorer. For example, * html #foo { width: 50%; } is perfectly valid CSS, yet is ignored by every standards-compliant user-agent and listened to by Internet Explorer.
    3. XHTML is intended to be served as application/xhtml+xml, which Internet Explorer doesn't understand at all. However, in a compatibility concession, RFC 2854 expressly condones serving it as text/html. Lots of people are confused about this, but the facts are simple if you actually read the specifications. Serving XHTML 1.0 as text/html does not make it invalid, and is completely in line with the specifications. However, all user-agents will actually treat it as HTML and not XHTML. This is by convention, not mandated by the specifications though, and you should not write XHTML expecting it to be interpreted as HTML.

    The anonymous coward was completely correct - it's perfectly possible to use valid code with Internet Explorer by simply limiting yourself to the subset of code that works in Internet Explorer and is defined by a W3C specification. This can be extremely frustrating at times, but it's usually better than the alternative.

    In addition, you shouldn't really focus on the XHTML bit. There are very few people who actually need XHTML, and despite the buzz, it has nothing to do with standards compliance or CSS. XHTML 1.0 and HTML 4.01 are functionally identical in these respects.

  • by Anonymous Coward on Monday November 20, 2006 @06:37PM (#16922116)
    that HP sight uses conditional CSS for IE6, IE5 and IE. So I think hackless-CSS is not here yet.
  • mod parent doofus (Score:1, Informative)

    by Anonymous Coward on Monday November 20, 2006 @07:14PM (#16922570)
    Parent apparently didn't load any of the style sheets.

    Dude, there are TONS of high-contrast basically-eye-gouging styles in which you can view http://www.csszengarden.com/ [csszengarden.com] as well as styles with even lower contrast than the front page default style.

    If you haven't loaded any of the style sheets, you're missing the point of CSS Zen Garden entirely...
  • by Asztal_ ( 914605 ) on Monday November 20, 2006 @07:45PM (#16922960)
    There's little point. There haven't been many changes in the layout engine from Firefox 1.5 to Firefox 2.0, in fact, these were avoided. Most of the rendering engine changes are going into/have gone into Gecko 1.9, which will become the base for Firefox 3 (There will be an "official" alpha of Gecko 1.9 some time next week, if you're interested). In comparison, IE6 to IE7 is very large difference in capabilities and compliance.

    Not to mention, IE7 came out before Firefox 2.0... :)
  • by rh2600 ( 530311 ) on Monday November 20, 2006 @10:35PM (#16924492) Homepage
    Browsers tend to do bad jobs at styling forms, mainly because the form elements are part of the OS UI and are painted last by the OS.

    Try styling a form button in Safari. You can't, because Apple have (rightly in my mind) decided that these UI elements are part of OS X's visual vocab and user's know what they should look like. If you try to style a button for other browsers then it's likely it will look horrible in Safari - so then you have to target Safari separately... messy.

    OS X also offers a totally different (and arguably better) file upload form element (which interesting can't really be styled in any browsers anyway). So when you have a nicely styled form, and then drop in a file upload element it looks like crap.

    So if you want a form consistent with the OS interface, and that is consistent amongst all form elements, and across all browsers, don't style it.

    This is all without discussion accessibility and font-scaling issues around styling form elements and using image replacement techniques on buttons. It's not worth the effort, and it breaks in many many cases. You are better off spending time making a more usable form itself, and adding in smart validation and the like ;)

Neutrinos have bad breadth.

Working...