Slashdot is powered by your submissions, so send in your scoop

 



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:
  • The review states that the book has been updated for IE 7 and firefox 1.5, but IE7 only came out very recently. How did they manage to get the book edited and checked so fast after IE 7 was released?
    • by Pharmboy ( 216950 ) on Monday November 20, 2006 @04:27PM (#16920082) Journal
      ...and since FF2 came out before IE7, how did they miss updating for it?
      • by Sancho ( 17056 )
        Ditto for Opera9.

        I think the issue is that there were substantial, backwards-broken changes to IE7's implementation of CSS. Firefox and Opera were pretty close to correct from the beginning, so web developers don't have to code directly for those versions of those browsers (as much--I'm sure tiny differences exist).

        And that's not even considering that IE has a much greater marketshare than the rest of the browsers, meaning any book which is going to talk about web development really has to discuss getting
      • 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 smoker2 ( 750216 )
        and since IE7 requires you to validate your copy of windows, who exactly is using it ?
    • Re: (Score:2, Informative)

      by Anonymous Coward
      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 jfengel ( 409917 )
          People probably do buy the best book they can, but when you're talking about a new technology a lot of people will rush out to buy something as quickly as possible. So while good authors are experimenting and researching, the ones who are just cranking something out are already on the shelves, and the people who rushed out to buy something aren't going to wait.

          In this case, for example, a lot of people probably feel they need something on the new tech so that their bosses can know that they're ready to supp
        • Joe doesn't even read. To him reading=audio books.

          I'm not knocking audio books, they have a time and a place, but they weren't meant to supplant reading altogether.
        • 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?

          Probably. From what I've noticed, most average Joes will go to the bookstore to get (say) "a CSS book". They flip through all the CSS books on the shelf, and pick whichever one seems to do the best job of covering whatever aspect of CSS they're trying to get a handle on at the time. Sometimes, they just grab the O'Reilly/Wrox/Addison Wesley/

  • by Anonymous Coward
    <!--[if IE 7]>
    <link type="text/css" href="stylesIE7.css" rel="stylesheet" media="screen" /
    <![endif]>
    <!--[if IE 6]>
    <link type="text/css" href="stylesIE6.css" rel="stylesheet" media="screen" /
    <![endif]>
    <!--[if IE 5]>
    <link type="text/css" href="stylesIE5.css" rel="stylesheet" media="screen" /
    <![endif]>
    <!--[if lte IE 4]>
    <link type="text/css" href="stylesIE4.css" rel="stylesheet" media="screen" /
    <![endif]>

    • by Anonymous Coward on Monday November 20, 2006 @04:40PM (#16920274)
      <!--[if IE 7]>
      javascript:self.close() /
      <![endif]>
      <!--[if IE 6]>
      javascript:self.close() /
      <![endif]>
      <!--[if IE 5]>
      javascript:self.close() /
      <![endif]>
      <!--[if lte IE 4]>
      javascript:self.close() /
      <![endif]>
    • 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 hav
      • Re: (Score:2, Interesting)

        by cloudkiller ( 877302 )
        Explain your stance to the person/persons paying you to make a super-duper-lookin' site and you will find yourself with one less client. Besides, can you really blame the people who sat down, used IE4 and said, "This is garbage, why would I ever want to upgrade garbage?" In fact, I think we should hold these champions of Windows 95 up as examples. They have been immune to the Windows-upgrade hype since the beginning. Either that or they have just been waiting for Vista for a reaaaaaaaaaaaaly long time.
        • by MikeFM ( 12491 )
          I've never had a client that cared so long as the site was usable for everyone. Most are very happy not to double or triple their costs just to support a few losers who are still using browsers from 1997.
    • by IflyRC ( 956454 )
      Guess the browser wars are still alive. Hm, competition is supposed to be good for the consumer right? Usually it just means more work for the developer.
    • Conditional comments were first implemented in IE5.
  • by moore.dustin ( 942289 ) on Monday November 20, 2006 @04:35PM (#16920204) Homepage
    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.

    Use of hacks? Sweet!

    Hacks are a bad practice that has been challenged and debated for a while now. I though, and correct me if I am wrong, that conditional HTML statements were the best way to go. Nowadays, why would someone want a book that is going to lead you to write non-compliant code.

    • Re: (Score:3, Insightful)

      I though, and correct me if I am wrong, that conditional HTML statements were the best way to go. Nowadays, why would someone want a book that is going to lead you to write non-compliant code.

      It depends upon what your application for the code is. As for why anyone would write non-compliant code, that's easy... most users will be using a non-complaint browser (some version of IE).

    • Re: (Score:3, Insightful)

      by Duggeek ( 1015705 )

      The issue with coding is not compliance with CSS standards (those are well published [w3schools.com]) but rather in how the various browsers interpret those standards.

      The code is standard; the parsing and rendering methodologies are not.

      I, for one, appreciate a book that addresses these non-standard behaviors when parsing standard code. The review posted by samzenpus exposes these insights, and contrasts them from the plethora of "standards reference" books. (many from the same publisher [oreilly.com])

      Sometimes, hacks ar [incutio.com]

      • by Bogtha ( 906264 )

        The issue with coding is not compliance with CSS standards (those are well published [w3schools.com])

        Please don't link to the sleazy W3Schools when referencing the work of the W3C. They have nothing to do with the W3C [w3.org] and are not responsible for the CSS specifications.

        • The reason I linked to w3cschools was to illustrate how CSS is well-published. We all know WHO publishes CSS standards and who is responsible for them.

          Besides, I find content on w3cschools much, much more practical and relevant to my work in web design. Most of the content on w3c.org seem more relevant to browser-app developers. (except for those working on IE7, of course) To their credit, they do have nice tips for beginners [w3.org]; you might want to try them out.

          As to the (thin) implication that w3cschools i

          • by Bogtha ( 906264 )

            We all know WHO publishes CSS standards and who is responsible for them.

            Actually, I see people mistaking W3Schools for the W3C fairly regularly. Whether it is your intent or not, you help promote this misconception when you link the way that you do.

            As for your personal issues with w3cschools, I suggest you take it up with them.

            It's not just me that has a problem with them [mozillazine.org].

    • Many designers would love to use conditional comments if they had CSS block granularity. Instead, the idiots at Microsoft only implemented them at the HTML level, making a maintenance mess.

      Conditional comments would be so wonderful if you could put them in a .css file like this:

      .someclass { position: fixed; }
      /* @user-agent(MSIE < 7) .someclass { position: absolute; } */

      .otherclass { cursor: pointer; }
      /* @user-agent(MSIE < 6) .otherclass { cursor: hand; } */

      That way, the purpose of each MSI

    • Hacks are a bad practice that has been challenged and debated for a while now. I though, and correct me if I am wrong, that conditional HTML statements were the best way to go. Nowadays, why would someone want a book that is going to lead you to write non-compliant code.

      Non-compliant code is the only way to go.

      Take a look at any complicated JS application. There's bound to be at least one place where things are 'hacked' to work in different browsers.

      I remember when I wrote my first real website and got it t
  • by Anonymous Coward
    ... is that it's FAR more valuable trawling the net for information, using forums etc. to get answers than have to to pour through so many pages searching for specific examples or answers to your problems.

    My work got me a few CSS books and when the boss asked if I'd read them, I indicated I'd used them briefly for reference, but no, not as such. He wasn't too impressed until I pointed out the recent sites I'd created, all validated, all exactly to spec and all AA accessible, not to mention extreme light wei
  • by pestie ( 141370 ) on Monday November 20, 2006 @05:02PM (#16920648)
    I'm not trolling, I swear. But I've been playing with Firefox's DOM inspector lately, and I've noticed that every single major site I've visited and "inspected" has used a nested-tables layout. Reading Slashdot will lead one to believe that that's the greatest sin one can possibly commit in HTML design, yet it seems to be done everywhere, all the time. It's my personal opinion that some things are just way easier to do with tables than CSS, and that's why people keep doing it. Am I right?
    • by Anonymous Coward
      Most commercial websites have to support all incarnations of IE, Netscape, Safari, Netscape, Opera, with the mix of Mac/Windows/Linux, etc. Due to the unfortunate state of CSS compatability among different browser versions, coding with HTML tables is the most universal way of formatting on the web.

      Hence most companies opted for using tables, hopefully that trend is going to change when most people move on to CSS spec compliant browsers.
    • Re: (Score:2, Insightful)

      by RalphSleigh ( 899929 )
      Yes, quite right. There is CSS to emulate table layouts, but until I.E supports it tables are simpler, easier and dont require loads of hacks for each browser. Its what happens when you try and use a language designed to describe STYLE for LAYOUT. CSS is great in the cathedral of web standards for styling documents sent over HTTP, however its a little lacking for websites.
      • by shmlco ( 594907 )
        That's because the hacks who designed CSS were "purists" who didn't believe in the idea that sites needed layout in the first place. One has only to look at the mess you have to go through to get CSS to do something "simple" like a standard three-equal-length column format with a header and footer to understand this.

        They believed that all web sites should be floating, amorphous blobs of contextually-tagged content, and that "layout" is something one does when dealing with quaint anachronisms like paper.

        It's
    • 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]
      • You shouldn't have posted anon (your post might go under the radar).

        I agree with everything you said. I'd just like to add that many people want to look for excuses not to learn CSS. If you are doing a quick one up site, sure do it the quickest way possible (nvu or dreamweaver using tables), but if it is something that is to last the stays of time CSS is soo much more flexible. If you didn't check out the csszengarden link [csszengarden.com] then do so now. All the designs have the exact same html. The only thing changed be
        • by shmlco ( 594907 )
          cssZenGarden is cool, but you need to understand that many of the tricks the various layouts use on don't work on a production site.

          Example: Quite a few layouts absolute position many of the elements... but they can only do this because they know the exact size and amount of text in each container. Do a site with dynamic, variable-length titles and content and those layouts would fall apart.

          Or the way they use background images to do all of the dirty work, which means that many of the layouts won't print co
          • by Briareos ( 21163 )
            many of the layouts won't print correctly if the user's browser has bg printing disabled

            That's what defining different styles for printing using "@media print { ... }" so you get perfectly readable text without any background images is for...
            • by shmlco ( 594907 )
              Doesn't help. Or, rather, you're missing the point. Since all of the images used are background images, none of them would print in that case. No backgrounds. No accents. No buttons or bullets. No logos. No photos. Nothing.
        • Where CSS falls down, and this mostly an IE thing, is with dynamic widths. That Zen Garden page does not, in any of the layouts, resize to fill your browser's screen.
          • That is true. I've had a much easier time doing table based sites that extend to the full width of the browser.
      • by Lando ( 9348 )
        I don't see anyone else mentioning it, but the csszendarden does not render for me. I'm using the latest Foxfire on Linux x86_64. Any clues as to what the problem might be?
        • by Lando ( 9348 )
          Nevermind, apparently it takes several minutes for the css to process and come up. Either than or loading external files are taking a long amount of time.
    • Yes. And people in third world countries defecate in open latrines. Please do not do that either. But if you must do one of these two things, shit out in the open field, it's only slightly smellier, and will go away far faster than a tables-based-layout.
    • Also, the major sites that are using table-based layouts aren't redesiging their sites anytime soon either. Have you ever tried to redesign a table-based site? The recommended method involves command prompt and deltree'ing the front-end.
    • Why is a valid question modded as funny? Anybody got some mod points left, change this to informative (even though, technically, it's interrogative). And to add my 0.02 to the question, it's that people don't want to take the time to figure out a decent design within the constraints of currenly supported CSS. You can do just about any design in CSS you can with tables, but not all of them (maybe 98%). The end result is, of course, smaller, easier to modify and modular enough to take apart and put back t
      • by gfxguy ( 98788 ) on Monday November 20, 2006 @06:33PM (#16922052)
        I disagree. I've tried to use CSS instead of tables for things like multiple columns and centering, and I can spend hours trying to make CSS look like the table layout that just works on every browser, or I can just use tables.

        Every single CSS methond has some kind of drawback that requires some kind of hack to fix if it's even fixable at all.

        Yes, there's a great deal to be said about separating presentation from content, but like OOP, CSS is no silver bullet.

        They could solve about 99% of the things tables are used for by simply having a "float: center", but even if they did that it would take like 10 years for all the different web browsers to implement it and you'd still be supporting all the old ways, which is why people still use tables.

        Don't get me wrong, I really try and I use the books I've purchased on CSS and website design and online resources including news groups and so forth, and I'd really rather use CSS than tables (and I usually accept a layout that I'm not always happy with just to do it), but this whole "tables are evil" thing will only be true when CSS can do the layouts you can so easily accomplish with tables.

        And contrary to your assertation; the kind of simple "center this" kind of layout I'm referring to doesn't give you a nightmare of nested tables and cells that are hard to figure out where they are.

        Here's an example: a simple centered box that grows or shrinks in width based on dynamic content. A simple unordered list, for example. If the options are small, the entire table is small and centered. If some of the items are wordier, the table automatically grows wider to accomodate the longer list item. If you don't want the table to grow too wide just for the one option (you'd rather it wrap before it gets to 100%), you can put it in a div that narrows the maximum width of the table. In this case, it could simply be a single cell table.

        In CSS, you don't get dynamic width based on the content - you get a percentage width or a specific width. The only way to center it in this case is to use javascript (or you could aproximate it with server side scripting). Believe it or not, after weeks of debate on the CSS newsgroup, that was the answer I got: don't use tables, use scripting to compensate. I'm sorry, but no.
    • Re: (Score:2, Insightful)

      by Duggeek ( 1015705 )

      I'll grant you that tables are often employed to do what cross-platform CSS seemingly can not; yet, there are also behaviors CSS can do that are not possible with tables.

      Yet, I will stipulate that CSS alone can often emulate, or even improve upon, the cumulative effect of rigid-table design. (even without using the DreamWeaver "layer" implementation, though I believe it will ultimately come around anyway)

      The explanation I hear again and again is that Table v. CSS is a "high-road,

    • Re: (Score:3, Informative)

      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 Anonymous Coward
        that HP sight uses conditional CSS for IE6, IE5 and IE. So I think hackless-CSS is not here yet.
    • You are correct.

      The tables are still a preferred method of laying out information. However DIVs are taking off I think, for example in two of my latest projects we use tables and divs, using table rows to present rows/cols of data and using divs to position portions of the page that are not just records of data. We also use divs inside table columns in one of the project to achieve layout flexibility.
    • Re: (Score:3, Insightful)

      by RedSteve ( 690399 )

      ESPN.com had a high-profile conversion [mikeindustries.com] in 2003 that was supposed to reduce its load time and file size signficantly. A peek at the front page today shows that, in fact, the site is contained within divs. On the downside, however, it appears that the front page designers have gotten lazy -- currently the page does not validate against its embedded doctype.

      As for why tables-based layouts are done 'everywhere', it could be because of a lot of reasons: no time to do a proper redesign, no desire to mess with a

      • by Bogtha ( 906264 )

        ESPN.com had a high-profile conversion in 2003 that was supposed to reduce its load time and file size signficantly. A peek at the front page today shows that, in fact, the site is contained within divs. On the downside, however, it appears that the front page designers have gotten lazy -- currently the page does not validate against its embedded doctype.

        It never did. I distinctly remember when it was first launched, Mike did a couple of interviews saying, in effect, "Aren't standards great!", follow

        • Ah, now that you say that, I recall that. Thanks for the refresher.

          Ah well, at least I could use my incorrect recollection to successfully push for a standards reform at my job... ;-)

    • by Java Ape ( 528857 ) <<mike.briggs> <at> <360.net>> on Monday November 20, 2006 @06:09PM (#16921706) Homepage
      In my opinion, you've hit the nail on the head. I use CSS-based layouts on my web sites, mostly because it was supposed to be a "best practices" issue, and partially because the inheritance is powerful -- I can make the left menu on every page in the site a top or bottom menu by changing just a couple of lines. However, CSS layouts don't usually degrade well in older browsers: you may see al your elements sequentially, for example. And getting pixel-perfect layouts is STILL problematical. That is to say that I can usually define a left-menu that is, for example 100px wide, and below the header, but it may not be EXACTLY 100 px wide in all browsers, and if I'm nesting multiple elements these little differences can cause big headaches.

      The solution, of course, is to rely on a bunch of hacks to present slightly different rules to different browsers, forcing all of them to display the correct bounding-box, margin, padding etc. And now we're writing unsupported, undocumented nasty hacks that will come back to bite us each time a browser is updated, which as a previous poster pointed out is an obvious no-no.

      Nested tables are not elegant, they're not CSS-based, they're not extensible etc. But they work. A 100px cell displays as at 100 px pretty darn reliably, without a laundry-list of hacks and hints. A menu placed to the left of the content STAYS to the left of the content, it doesn't suddenly display after the content block. From a practical standpoint, tables are simply more robust and more reliable than CSS-based layouts, at least with the flakey browser support CSS layouts have. I've pulled lots of hair out to get my CSS layouts as good as they are, because I believe in CSS, but I think a smarter man would have used tables.

      • by Bozdune ( 68800 )
        Thank you for writing the comment I would have written. Probably better than I'd have written it, too.
      • by ChaosDiscord ( 4913 ) * on Monday November 20, 2006 @07:59PM (#16923174) Homepage Journal
        However, CSS layouts don't usually degrade well in older browsers: you may see al your elements sequentially, for example.

        The entire point of CSS is to "degrade well." You've confused "displays identically on mainstream browsers with large resolutions" for actually degrading gracefully. To take a single example I have a lot of experience with, those beautiful table layouts fall apart on small displays. Maybe you can reasonably assume modern laptops and desktops have a resolution of 800x600, but what about my phone (128 x 160) or my Palm (320x480). A table based layout falls apart. But a CSS based layout using floating sidebars degrade reasonably gracefully on my palm. My phone doesn't support CSS and I frequently disable CSS on my Palm for speed. In both cases the CSS based layout may be dull and sequential, but it's perfectly readable. For web sites about presenting useful information this is great. Table based layouts turn into hard to read messes. Now my Palm's browser has a great feature that tries to detect tables-as-layout and linearizes them, and it's pretty good, but it occasionally trashed actual tabular data. Because people use tables to mean two totally different things ("I want this thing exactly here for visual impact" vs "This is tabular data"), my Palm can't try to present a graceful degredation.

        • by ltrm ( 845045 )
          If I had mod points right now I would be giving them to you. This is exactly point of HTML, if it's written with standards in mind we can reformat it easily regardless of device. Its also worth remembering that CSS support in browsers is only going to get better. Where as table based layout will always have problems associated with them.
        • Yes, and it is a great annoyance to me when I try to visit some sites on my Palm (Treo 650) and they totally fail to render. Some sites really look bad. Wikipedia, for instance, with its combination of table-based and css-based layout is unusably bad in Blazer, Palm's default browser. I actually have to put my browser in wide mode (I normally use optimized mode), and try to find the login link on the page, and try to click on it (it's behind the wikipedia logo). Once I am logged in, I have a different d
      • by Ed Avis ( 5917 ) <ed@membled.com> on Tuesday November 21, 2006 @09:38AM (#16929492) Homepage
        I think the point is that wanting 'a 100px cell' is kinda silly. The size in pixels should always change according to the output device: on a 1200dpi laser printer, making your cell 100 pixels wide will be rather small. Are you _sure_ you always want to specify the exact number of pixels? Isn't it better to give general guidance and let the rendering engine make some of its own decisions?
        • by jandrese ( 485 )
          That's what kills me about CSS though. If you don't specify exact dimensions it is very hard to layout a site. It gets worse when you want a couple of fixed width columns (say a sidebar ad and a menu) and then have the rest of the page dynamically sized to fit the screen. Without using tables this takes some serious CSS voodoo.
      • OK, I'm replying to my own comment, which probably makes me a troll of some sort. Several people have pointed out that CSS degrades more gracefully than HTML, where graceful means the content is still readable, even if the presentation is NOT what the author had in mind. Others object to the use of pixel sizes in my examples. Thus are holy wars begun!

        A good web page should meet three criteria: Utility, accesibility and asethetics. Naturally, these three goals are effectively mutually exclusive, and EV

    • by Bogtha ( 906264 )

      It's easier to use something you know rather than something you don't. A lot of web developers are more comfortable with table layouts than with CSS because they have more experience with them, and the stupider, lazier ones use this as an excuse to not bother with CSS. And, because they continue to eschew CSS, they just get more and more experience with table layouts and the problem gets worse. This is only offset by new developers entering the field, the old ones retiring, and the smart ones switching.

    • No, seriously. I know it must be heresy to say it on here, but, even without throwing IE into the picture, CSS caused me enough headaches to get out of web development. I mean, geez, you can do fancy things, but when the things that are no-brainers with tables take an entire afternoon to do with CSS, you have to stop and wonder what the guys who came up with it were on.

      CSS 3 looks like it might finally be sane, but you know CSS 3-supporting browsers won't be widely for years and years. I don't blame people
      • by interp ( 815933 )
        I'm not a native speaker, but isn't style different from layout? Doing layout with a style language always looked akward to me. Which may explain, why it takes an entire afternoon. [Yes, I know it supposed to be used for layouts, but still...]
        • by jandrese ( 485 )
          Perhaps, but since the other half of your page is the content (which is supposed to have neither style nor layout), you're kind of stuck doing the layout in the CSS.
    • yes; have a look at http://www.redhat.com/ [redhat.com] - you'll find some nooks and crannies left from a previous table-based design, but the majority of the site is pure css with not a table to be seen.
    • by caudron ( 466327 )

      It's my personal opinion that some things are just way easier to do with tables than CSS, and that's why people keep doing it. Am I right?

      In part, yes. It is easier to design sites that are formatted as we have grown accustomed to them in the old table layout manner.

      CSS, however, frees the designer from the constraints that table layout imposes. They allow for a great deal more layout freedom and moreover they make it about twice as easy to design sites that are A11y compliant (at least as per the paramet

    • Before the merger with SBC, AT&T's corporate site used XHTML 1.0 Strict and CSS (tableless, except for data tables and some forms) for its pages.

      For more details:

      http://www.joesapt.net/2006/03/01/00.50.00/ [joesapt.net]
      http://www.joesapt.net/article/weeklystandards/par t1 [joesapt.net]

      Unfortunately, much of that work was pretty much left to die when SBC completed its acquisition of AT&T.
    • Am I the only one who thinks using floats to create columns is just a hack? Floats, as I understand them, we designed to allow text to flow around a div, picture, whatever - NOT to be used to create columns. If they were, then why does css 3 have a new column layout feature? I, for one, continue to use tables to define columns because I don't like taking elements out of the flow via floats. Does it really matter? Probably not... I don't even know why it matters to me so much - I guess its just the principl
  • A book? (Score:2, Insightful)

    by daeg ( 828071 )
    A book? on CSS? Why? Do you often find yourself writing CSS without Internet access?

    Personally, the only way for me to know a particular cross-browser CSS approach works is to actually test it on every browser I can. Kinda hard to do that with a book.

    And if these guys were real CSS gurus, they would have written their book in XML and CSS and used Prince to convert it and then open sourced the book code.
    • by Psiren ( 6145 )

      A book? on CSS? Why? Do you often find yourself writing CSS without Internet access?

      Some people (myself included) just like to sit back and read a book to give themselves some familiarity with the problems before they get down to doing the actual work. This is especially true of a cookbook, which is less of a reference than a source of neat ideas.

      And if these guys were real CSS gurus, they would have written their book in XML and CSS and used Prince to convert it and then open sourced the book code.

      I can't

      • by j-pimp ( 177072 )

        And if these guys were real CSS gurus, they would have written their book in XML and CSS and used Prince to convert it and then open sourced the book code.

        I can't tell if you're being facetious, or you're just a prat. I fail to see why after having writen a book the author should be expected to give away that work.

        Auctually there may be some merit to his point. I don't think he should give the whole book away. However, Knuth did write his own document processing system to deal with all the math i

  • Should simply read: Don't
    • why not?
      • Re: (Score:2, Informative)

        by rh2600 ( 530311 )
        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 totall
  • One of the goals of CSS is to separate presentation from content. When I first got into web design, I drank the Web Standards Kool-Aid (coming from a programming background, I can't believe I let myself get suckered into using CSS hacks). I have since come to realize that there are other more efficient ways of achieving that separation without resorting to tableless layouts that require you to spend > 80% of the development time on 10% of the browsers out there. ASP.NET 2.0 master pages go a long way bu
  • I remember purchasing a paper-based AJAX book about a year ago. The book was out of date and had a gazillion typos, such that none of the source provided runs without a bit of discerned editing on the reader's part. (Similar dissatisfaction occurred with other paper-based computer books.) Every time, I found that the web provided better tutorials on the matter.

    From the review, I don't see any reason to jump out to purchase the book. Cookbook items are already provided ubiquitously. Even a casual search on

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...