CSS: The Definitive Guide

Michael J. Ross writes "Every Web developer knows that Cascading Style Sheets (CSS) makes it possible to separate the contents of Web pages from the styling of the elements on those pages. This in turn confers tremendous advantages, such as allowing site-wide changes of appearance to be made just once, in a single stylesheet file, rather than in all of the pages containing the affected elements. The syntax and proper usage of CSS is not as simple as implied by many HTML/CSS books, most of which fail to provide enough detail as to how CSS is applied to page elements. Web developers relying upon these books soon find themselves hitting those limits, and becoming frustrated when trying to debug Web pages. CSS: The Definitive Guide, authored by CSS expert Eric A. Meyer, aims to fill that gap." Read on for the rest of Michael's review. CSS: The Definitive Guide author Eric A. Meyer pages 536 publisher O'Reilly Media rating 9 reviewer Michael J. Ross ISBN 0596527330 summary A comprehensive CSS reference guide.

Published by O'Reilly Media in November 2006, this title is now in its third edition. The first edition appeared in May 2000, and the second in January 2004 — with each one establishing the book as an immediate favorite among hard-core Web programmers. Each revision brought it up to date with the evolution of CSS as a standard, its support among the most popular Web browsers, and its usage within the Web development community. This latest edition covers CSS2 and CSS2.1, but does not include the CSS3 modules, including those that have reached Candidate Recommendation status, because their implementation is largely incomplete among most of the browsers.

Web veteran Eric Meyer presents the book's material in a methodical manner, starting with an overview of CSS's purpose and advantages, and quickly moving into the details of the technology: selectors, structure, inheritance, values, units, fonts, text properties, visual formatting, padding, borders, margins, colors, backgrounds, floating, positioning, tables, lists, and generated content (e.g., bullets of unordered lists). The last two chapters address user interface styles (system fonts and colors, cursors, and outlines) and non-screen media (such as paged and aural content). The book's 536 pages are organized into a total of 14 chapters and three appendices. The first appendix is a complete CSS property reference, spanning more than 40 pages, with visual, page, and aural properties grouped separately. For each property, Meyer explains its purpose, its valid values, the initial value, what elements it applies to, whether it is inherited, its computed value, and additional notes (if any). The second appendix is a reference for the selectors, pseudo classes, and pseudo elements. The third and final appendix is much shorter than the first two, but no less interesting, as it discusses a sample HTML 4 stylesheet, which is presented in the CSS2.1 specification as the recommended style sheet for developers to use.

As with all of their other titles, O'Reilly Media offers a Web page devoted to this book, where visitors will find links to online versions of the book cover, table of contents, index, registration form, reader reviews, and errata (of which there are none, as of this writing). In addition, the page has offers to receive a volume discount, and to read the book online as part of O'Reilly's Safari service.

Anyone who is considering purchasing this book might initially be concerned by the dearth of feedback on the Web sites of the publisher and the major online booksellers — in the form of few reader comments, and no reported errata. The prospective reader may wrongly conclude that this indicates a lack of interest in the book, and thus it must be unpopular — probably for good reason. But just the opposite is true, as demonstrated by the book's sales rank on Amazon.com alone: #4631, as of this writing. Unlike far too many of the other HTML/CSS books available, this one does not engender scathing reviews by customers angry with the books' shoddy writing and sloppy mistakes. Rather, Meyer's contribution is the type of solid reference book that the discerning Web developer will quietly place on their desk or bookshelf, within easy and frequent reach — possibly displacing a dog-eared first or second edition of the same title. Furthermore, the absence of errata should suggest that most if not all kinks have been worked out of the book, and not that the book is failing to receive careful readings.

CSS: The Definitive Guide benefits not just from its multiple revisions, but also from Eric Meyer's clear and complete writing style. Unlike his more advanced books, this one is far more approachable, making it possible for the reader to easily jump into the midst of any topic and quickly pick up the thread — as is essential for any technical reference work. The theoretical discussions and the sample code demonstrate his abundant experience in using CSS in the real world, discovering or verifying its idiosyncrasies, and pushing it to its limits. Most of the critical visual and positioning topics are well illustrated with diagrams and sample output, few of which are weakened by the lack of color in the grayscale figures. Last and certainly not least, readers should be pleased that the book's material has been updated for Internet Explorer 7, which promises to fix many inexcusable problems in earlier versions of the browser.

Rarely does one come across a programming book that has no significant flaws, and will likely become a favorite resource for developers everywhere. CSS: The Definitive Guide is a comprehensive, well-written, and welcome addition to the library of any Web developer who wishes to understand and utilize CSS better.

Michael J. Ross is a Web 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: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

My experience

[2.7182]

This is a great book, but my binding cracked after 2 weeks. Worth buying anyway though.

Re:My experience

[Rob T Firefly]

This is a great book, but my binding cracked after 2 weeks.

This is why I prefer hardbound CSS books, where you can make changes to the book's binding independently of its content.

Re:My experience

[CRCulver]

This is a great book, but my binding cracked after 2 weeks. Worth buying anyway though.

Your binding cracked. How was it bound? I don't buy too many books from O'Reilly recently, but the last one I bought, Python in a Nutshell uses a rather novel binding that allows the book to lay flat and is quite durable. I assumed all O'Reilly books would use this newer system. And even my oldest O'Reilly books from the mid-90s are still fine, no weaking of the glue in the traditional binding. Did you write to the publisher to complain? Often as a gesture of goodwill they will allow you to exchange the book if you write a paper letter written sweetly enough.

Re:My experience

[Azarael]

For the softcover books that you do end up getting a lot of use out of, some bookstores offer rebinding. Might be a little pricey, but may be better than having a reference that's in 3 or 4 pieces.

Re:My experience

[M00TP01NT]

This is a great book, but my binding cracked after 2 weeks. Worth buying anyway though.

If it had been a Windows book, someone else would have cracked it for you (and it wouldn't have taken two weeks).

Re:My experience

[Spacezilla]

I think that fact was exposed already, but I don't mind, because it's still funny. :)

Re:My experience

[Raenex]

I don't buy too many books from O'Reilly recently, but the last one I bought, Python in a Nutshell [amazon.com] uses a rather novel binding that allows the book to lay flat and is quite durable. I assumed all O'Reilly books would use this newer system.

Hmm, interesting. I haven't bought an O'Reilly book for awhile, but this is good to know. I did some googling, and the binding style is called RepKover. Apparently they stopped using this binding as a cost saving measure in 2001 after the dotcom bust, and resumed it in 2004. They don't use it for all books though (some are too thin or too fat).

Re:My experience

[Raenex]

This is a great book, but my binding cracked after 2 weeks.

It's probably cracked by design, so that it lays flat. (Credit: I had no idea O'Reilly books did this until reading reading a sibling post about an O'Reilly Python book; I'm just being more explicit and providing a link).

MOD PARENT DOWN. Referral spammer

[Anonymous Coward]

If you examine the link in the parent's post, it shows that he's using a referral code, kaleidojewel1-20. Scumbag.

A wonderful book

[SavedLinuXgeeK]

I purchased the previous version, and it was truly a clear and concise introduction and mastery of CSS. Mastery in the sense of understanding how CSS works, not in mastery of CSS Cookbook type "fixes". It was much better to learn the fundamentals of CSS before trying to understand why and how the hacks work the way they do. I still keep and use the book as a reference at my desk at work.

My question

[hypermanng]

It has been updated to account for IE7's ideosyncracies, but does it also cover the other browsers well? Every time I've started really using CSS, I 've gotten frustrated by the way each browser decided to support a different subset of CSS so I had to sit there and try everything before figuring out what non-IE-on-Windows browsers would make of the page. Probably the major browsers support much more of the CSS spec, but I was burned so bad last time I haven't wanted to touch it with a ten foot pole in several years.

Re:My question

[itlurksbeneath]

Css browser support. Pretty good guide. If you design for FF or Opera and don't use any hairy CSS, it should look pretty good in IE7 (assuming you're using a decent DOCTYPE) and can be tamed in IE6 with a few tweaks to fix things like the broken box model and such.

Interesting thing I noticed when scrolling through the guide linked above - the level of css support between IE6 and IE7 isn't all that different (maybe a handful of new items supported). So, IE7 was mainly a bugfix release. Five years and they finally fixed the CSS engine. Way to go MS.

If you can't see the sarcasm dripping from above, check your glasses.

Re:My question

[Fozzyuw]

it has been updated to account for IE7's ideosyncracies, but does it also cover the other browsers well?

Good question, each browser has different levels of support. If you check out some browser usage you can see a decent estimate of what browsers are most used. Then you can check out browser CSS compatibility.

Besides IE6 (I'm not supporting IE5 Mac), I do not see issues across (modern or heavily used) browsers very often, unless I'm trying to do some sophisticated, multi-column, nested, floating DIV design. Also, in my experience, complicated float designs usually can be simplified with other means to avoid X-browser issues.

The biggest problem with CSS is that it also required good (X)HTML markup. Sometimes your CSS is sound, but the HTML code is not proper or designed by design instead of designed by content. A good book on working through this is Transcending CSS: The Fine Art of Web Design whose authors are also well known in the CSS/Website world and quote from Eric Meyer (the author of the book being reviewed on this page) as well as others.

I've been starting to learn that lots of my CSS frustrations of the past have mostly been part of my fault not thinking about CSS properly and trying to make easy things more complicated. Though, it can still be said, there's still lots of room for improvement, in both browsers and CSS specs.

Cheers,
Fozzy

Re:My question

[owlstead]

"If you can't see the sarcasm dripping from above, check your glasses."

Can't see any sarcasm dripping of my glasses neither...

Re:My question

[BenoitRen]

You don't need a tweak to fix the broken box model in IE6. Using a proper DOCTYPE is enough.

Re:My question

[NoMoreNicksLeft]

"Hairy" meaning anything even remotely interesting, of course.

Suppose you have some background images, alpha png of course, and you want to do rollovers. Well, the right way to do it is to put all the images into a single image file, so that they'll all load at once, and help conserve bandwidth and http connections. You use background-position and width/height to specify which portion of the image to display where ever whatever.

Of course, 3 months later and IE7 is still lingering in the 15% of all unique visitors range, and IE6 is in the 30% + area.

So, you can do your background-position thing, or your alpha transparency thing. But god help you if you want both, because that nasty-assed filter hack might give you alpha, but totally fucks background-position (it's no longer a real background-image, after all).

IE7 is no better. Still no border-radius? That property alone would save who knows how many ters of bandwidth on the internet by reducing obscene javascript chicanery, round images, and godawful markup (bullets for rounded corners WTF!?!?!?). The same with box-shadow and text-shadow... these are things that a talented programmer could manage in just a few hours each, Microsoft. Worst of all, the pus-filled pimple that is the filter property and its equivalents are just so goddamn lame, that even if we don't mind writing non-validating stylesheets by including them, they won't look comparable enough to the moz/konq/webkit/opera/icab versions for us to use the stylesheet. Thanks Microsoft for guaranteeing another 10 years of using background images all over the goddamned place to do something css shoulda been able to do back in 2003.

Re:My question

[greenhaven]

If anything, that's an incentive to make people migrate away from browsers with poor standard support. Code the CSS for the standard, and then when Joe Sixpack sees the site looking like crap, perhaps somehow it will make them migrate to a better browser. Either that or some poor sucker at MS tech support gets an earful of screaming.

Re:My question

[zbuffered]

As a full-time web developer, I feel your pain.
For me at least, the only thing that makes it go away is booze and *html body{display:none;}

Re:My question

[Scaba]

You don't know much about Joe Sixpack, do you?

Good Book. Bad Index.

[popo]

The book is, as the OP states, excellent.

The problem lies with its index. Actually using the book is very difficult because the Index is so non-inclusive of the subjects within the book.

Worth getting, but be prepared to flip through it a whole lot more than you would if the Index was well written.

My 2 cents.

Simplify CSS development

[len_p]

Want to simplify CSS development? Just make IE disappear. Checking that the CSS works in IE is taking lot of time and is the most frustrating not to mention that you have nothing like Web Developer or FireBug. What to loose your neurons, make your CSS work in IE, hack after hack. bGR@!#!@#! len

Re:Simplify CSS development

[somethinghollow]

Code for FireFox, Opera, or Safari. Then use conditional comments to load a stylesheet for IE to overwrite the styles it finds problematic. While conditional comments seems like a hack to me, it's an officially supported by IE hack that is officially unsupported in every other browser. If other browsers ever support it, then the "hack" still works. If IE ever stops supporting it, it's just a comment. So far, it's the only method worth using and it isn't nearly as irritating as CSS hacks (that may or may not continue to work). I usually only end up adjusting box model stuff.

That said, IE still needs a lot of work to be compliant with CSS2. It sucks that my/our clients have to foot the bill for Microsoft's sub-par browser (instead of Microsoft).

Re:Simplify CSS development

[Paulrothrock]

I write two separate stylesheets and use a browser agent sniffer to switch between the two.

Re:Simplify CSS development

[FuzzyBad-Mofo]

[IE has] nothing like Web Developer

Actually, there is the Internet Explorer Developer Toolbar which is quite useful for debugging IE's quirks.

What does this book offer...

[moore.dustin]

... that all the free online resources offer? Is it merely organized data? Is it the examples? I find all of that readily available for many web technologies and even more so for PHP and CSS. Numerous sites exist that cover everything in several ways too. Is this book simply a consolidation of information that is otherwise free via a google search?

Re:What does this book offer...

[SavedLinuXgeeK]

In the same way that a Computer Science text book's information is freely strewn about the internet, so who needs them? The book teaches fundamentals, and the building blocks of CSS, where most examples and tutorials are aimed at getting you to be able to create content as quickly as possible. I can copy programming examples from a website, and even read their reasoning behind it, but I would not assume, for the most part, that they have the experience or authority to properly convey the information to me, the same way that someone who has taken the time to write a technically oriented book would. Basically you are getting experience and wisdom from the book as well as information, and not necessarily so with most online tutorials.

Re:What does this book offer...

[falconwolf]

... that all the free online resources offer? Is it merely organized data? Is it the examples? I find all of that readily available for many web technologies and even more so for PHP and CSS. Numerous sites exist that cover everything in several ways too. Is this book simply a consolidation of information that is otherwise free via a google search?

Some of us prefer hardcopy to read and work through or for reference. I am one, if I read too much on a monitor I get sore eyes and headaches. This doesn't happen when I read books. It's also easier for me to have a book when I try something than when I have to switch between the app I'm using and a browser.

Just because something is online doesn't mean it's better.

Falcon

Re:What does this book offer...

[mysticgoat]

What does this book offer... ... that all the free online resources [do not] offer?

Just one thing: Eric Meyer's insights into the theory and practice of CSS. A web developer reading one of Meyer's books is sort of like an aspiring novelist reading Steven King's book On Writing.

Re:What does this book offer...

[tehcyder]

A web developer reading one of Meyer's books is sort of like an aspiring novelist reading Steven King's book On Writing.

I can't decide whether that is a compliment or an insult to Meyer.

Re:designer not developer

[drinkypoo]

Why don't people understand the difference between a designer and a developer?

The web makes that distinction hazier and hazier. Many of us end up doing both in spite of the fact that we're not really suited to it, unfortunately. Of course, the software lets us get decent results easier and easier all the time, so that helps.

But even just talking about CSS, is doing CSS really just design? With all the stupid CSS tricks you have to play, it seems to me more like cross-platform programming than anything else.

I realize that CSS is not a programming language. More's the pity; if it were a little more like a language then a lot of things that are very hard to do in CSS and require dynamic styles (or at least assignation of styles) to do properly would be very easy. For example, I should be able to say that an element is n% minus the width of another element... But since I can't I have to figure out how many units (typ. pixels) are in n%, then figure out how many units wide the other element is, and then set the width of the element I was trying to size accordingly. And if the element I'm trying to fit in next to is sized in ems instead of px, I have to recalculate this data and resize elements every time the font size is changed.

Next time,

[piranha(jpl)]

Next time, use a URL proxy service, like the article submitter did for the link to their hosting company.

Re:designer not developer

[Anonymous Coward]

Believe me, working in a graphic design firm as a web developer, there is a large difference between a designer and a developer. Designers here work almost exclusively in Photoshop and only have to have the most rudimentary understanding of what can and can't be done using XHTML/CSS. I'd say that somebody who is used to looking at XHTML/CSS, coding from scratch, understands inheritance, and how these can be used to accurately reproduce major corporate websites across most any browsing environment qualifies as a developer.

IE is the roadblock

[fiannaFailMan]

CSS is great in theory and should make sites easier to maintain, but in my experience all this advantage is lost when hacking to get IE to support it. I seem to have to support IE OR the rest of the world's web browsers, but I can't seem to get certain pages to support both. I've had to revert back to HTML tables for my page layouts, and I'll be sticking with that until a more CSS-friendly IE becomes more widespread. I just spend a bit of time familiarising myself with CSS and using it for text styling and some positioning within my tables. I'm sure in a year or two it'll become feasible to use CSS exclusively, and I'm quite looking forward to it.

Re:IE is the roadblock

[juiceCake]

I find that making sure you use a strict XHTML doctype definition, IE behaves remarkably well. I can do all my layout and text styles in CSS and use the !important hack occasionally in style sheets rather than use conditional statements. Of course I can't use attribute selectors and so forth, but one day, one day...

There is, of course, some compromise, but it sure beats developing with tables, which is just a mess.

Re:IE is the roadblock

[8-bitDesigner]

Hey, don't knock conditional comments. While I'm all for semantics, the ability to target IE7 and IE6 and serve them their own stylesheet is immensely useful when you're handling things like IE6's penchant for doubling the margin on floated elements.

And yes, while it isn't a perfect solution, I'm just one find/replace away from tossing the IE6 stylesheet the minute its market share drops low enough.

Re:IE is the roadblock

[Serious Callers Only]

The best way to deal with this is to design for non-borked browsers, then adjust for IE, with several style-sheets for different versions of IE to account for the bugs. That way Opera, Safari, Firefox and any others will just work, and IE will work as well as it can, till they release a version without all the CSS bugs.

The IE conditional includes are a nice idea - I wish other browsers did that as well, because it would make working around the bugs a lot easier. The majority of your code goes in a normal css file, and then you can isolate bug workarounds in specific files.

<![if lt IE 7]>
Your stylesheet here
  <![endif]>

You can use a bug in IE Mac to code for that browser too :

<style type="text/css">
@import(stylesheets/MYIEMACSTYLESHEET.CSS);
</style>

What gets me about CSS is that when in use it feels like it was designed by people who didn't really care about

1. The poor people who have to write browsers which deal with all its intricacies
2. Aesthetics

It's difficult to implement because of the complicated box model (I don't think any browser has a completely bug-free implementation of CSS), and it's actually difficult to design things that look nice. Lots of lovely typographical/graphics stuff that should be easy to do (drop caps, hanging punctuation, proper indented paras, multiple column layout) is instead really quite difficult.

Re:IE is the roadblock

[Anonymous Coward]

I find that making sure you use a strict XHTML doctype definition, IE behaves remarkably well.

XHTML is not appropriate on Internet Explorer. I use XHTML 1.0 Strict on my site, but I also know that the vast majority of my regular visitors are using Firefox. I'd certainly never suggest using XHTML to make things easier on IE. You can get the same advantages, and avoid the complications, if you just use semantic-meaningful HTML 4.01 and CSS, making sure each validate.

Re:IE is the roadblock

[juiceCake]

I wouldn't knock conditionals. Many developers use some variations to achieve the results they wish.

Re:IE is the roadblock

[juiceCake]

Interesting read. I've experienced none of those problems but will keep them in mind. As for validation, of course, I always make sure they validate.

Re:IE is the roadblock

[brunascle]

i find XHTML is fine as long as you develop using the application/xhtml+xml content type, then switch to text/html for production. and obviously you'll have to develop using a broswer that supports XHTML (not ie).

that, or have your site change the content-type in a script, depending on what the browser sent in the Accept header.

if you're not using application/xhtml+xml in development, you might as well stop using XHTML all together, because chances are there are errors all over the place.

Re:IE is the roadblock

[koehn]

To everybody posting the obligatory "IE Sucks at CSS", while I agree with the sentiment, my own IE experiences got much less painful (and this goes for Firefox too) when I learned how the browsers tell between "quirks mode" (where rendering with CSS is a true crapshoot) and "standards compliance mode" (where rendering with CSS is... somewhat less of a crapshoot).

If your DOCTYPE tag at the start of your HTML starts with something like:
[!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
                        "http://www.w3.org/TR/html4/strict.dtd"] (in angle brackets, thanks Slashdot!)

Then IE/FF will render it in a fairly similar way. If you don't include the URI of the DOCTYPE ("http://www.w3.org/TR/html4/strict.dtd", above) then you're stuck in quirks mode hell.

That said, IE still sucks at CSS.

Re:IE is the roadblock

[fyoder]

For biz sites and such it's a pain, but just for fun sites can do something like this (try it in IE, otherwise a warning: full frontal male nudity). In a non-IE browser it's all css layout. It was 'for fun' and getting the css to work in IE would not have been fun.

Re:IE is the roadblock

[BLACKtactx]

So, in other words, not to dig or anything, but it sounds like instead of making your css pages work, you have taken the easy way out. Sure its hard, but the reward is great. There is absolutely no excuse to use table based layouts anymore, and ie is CSS friendly, its buggy sure, but completely possible with workarounds and various tricks. Good luck with the shift, i recommend switching fully now :-)

Re:IE is the roadblock

[fiannaFailMan]

not to dig or anything, but it sounds like instead of making your css pages work, you have taken the easy way out

And not to dig back or anything, but I spent about a week trying to get the page to work before deciding I had better things to spend my time on. Using tables I got it rendered in a few minutes. Right now the rewards are just not big enough to justify this effort. For layout changes, Dreamweaver will proliferate them throughout the site. Might not be as slick as CSS, but it works. Sometimes the 'easy way out' is what you need.

Re:IE is the roadblock

[juiceCake]

I don't find I need to develop in one and switch. That's what I usually do and find that's what's recommended in many books. Pages always validate unless you're saying that the validators will fail to catch errors and say a page validates as valid XHTML Strict when it isn't.

Re:IE is the roadblock

[brunascle]

well, yes, granted, if you're going to use a validator, that trumps application/xhtml+xml, so you're probably fine.

but there are certain things (most) validators wont even catch, but your browser will. e.g., in XHTML, CSS is case sensitive. took me a while to figure out that one.

Re:IE is the roadblock

[ve3oat]

When I started using CSS (I'm still just a beginner), I stopped worrying about how any browser would render my pages. All my pages comply with W3C standards. (Although, as a beginner, I still use some deprecated HTML.) My layouts are all relatively simple and if the browser, any browser, can't render it reasonably well, then To Heck With Them. No more hacks. Maybe I am foolish and idealistic (or just plain stupid), but the browser wars are over for me. CSS, XHTML (transitional), and W3C forever.

Re:IE is the roadblock

[Requiem]

Exactly. Tables are for tabular data, not design. Even I know that, and I might be the world's worst web developer (haven't really done any web work since 2000 or 2001). Once I learned CSS, I never went back. Being able to link to a single stylesheet in each document, and effect website-wide change, is simply fantastic.

Re:IE is the roadblock

[Raenex]

in angle brackets, thanks Slashdot!

You work with CSS and you can't figure out how to escape <angle brackets>? It's &lt; and &gt; if you use "HTML Formatted". Well, at least you previewed :)

Re:IE is the roadblock

[Raenex]

That works great if you are only responsible for yourself. Doesn't work so well for people getting paid to produce web pages that look reasonable. I agree with the sentiment though.

Not the only positive of CSS.

[shawn(at)fsu]

Every Web developer knows that Cascading Style Sheets (CSS) makes it possible to separate the contents of Web pages from the styling of the elements on those pages.
Or in the case of MySpace, CSS allows a user to make a website with no content look better by overdosing on the style.

Re:Not the only positive of CSS.

[RedSteve]

Um...did you just use "MySpace" and "style" in the same sentence?

Re:designer not developer

[CRCulver]

Yes, I wish CSS had support for if statements. I maintain a website in several languages. Now, if a span with xml:lang="es" appears in an English, French, whatever paragraph, it should be italicized, but if a span inheriting xml:lang="es" appears in a Spanish paragraph, it should be styled the same way as the surrounding text. Unfortunately, there's no simple way to do that in CSS. I have to write dozens of individual rules for each language like body:lang(en) span:lang(es) { font-style: italic; } instead of just declaring "If a span appears with a different xml:lang attribute than surrounding text, italicize, otherwise not".

Re:designer not developer

[Doctor Memory]

Why don't people understand the difference between a designer and a developer? The web makes that distinction hazier and hazier. Heh, not in my case. One look at my pages and people know right away I'm a developer...

Apt

[mfh]

If you get the book over O'Reilly's Safari service, what you're saying is very possible! (with the help of some custom CSS and Firefox)

Might be worthwile

[Da Fokka]

I haven't read the book, but given the fact that creating a simple three column layout that works on every browser and looks good too is far from trivial, one can conclude two things:

• Something's wrong with CSS
  
  
• This book may be worth buying

Re:Might be worthwile

[edmicman]

Heh, I agree. I, too, will probably have to check this out, but I know I've heard all over how using tables for layout is bad and using CSS instead is Teh Good. But every time I try and do a layout that would take two minutes with a table, and do it it CSS, it takes many times longer to get things to actually *work* and look right. Float that to the left! Oops, once I add another column, they're both squished to the top! Etc etc....

Re:Might be worthwile

[pwizard2]

I'm sure that admitting this is going to really hurt my karma, but in situations where I need a 3 column layout, I just use a table to create the columns because it always works.

I've never once had a client that actually cared about what I did with the code or if I used 100% kosher W3C-approved code. The only thing that all of my clients have wanted to hear is, "This works to solve the problem at hand and it will always work reliably."

I don't like to write kludgy code if I can help it because I consider it to be sloppy, but sometimes I just don't have a choice but to use workarounds.

Re:Might be worthwile

[Da Fokka]

I totally agree. Doesn't the fact that's it's so darn hard to make a simple three column layout mean that CSS is broken? I do exactly the same thing like you: using tables and hoping blind people will understand (I use ALT tags on every image to compensate ;).

Re:Might be worthwile

[RoseAlbert]

I have always had success with the example code explained on A List Aparat's Article "In Search of the Holy Grail" by Matthew Levine http://alistapart.com/articles/holygrail

Re:Might be worthwile

[emurphy42]

Under what circumstances does the following not work well?

#COLUMN1 {
        position : absolute;
        top : 10px;
        left : 10px;
        width : 20%;
}

#COLUMN2 {
        position : absolute;
        top : 10px;
        left : 25%;
        right : 25%;
}

#COLUMN3 {
        position : absolute;
        top : 10px;
        right : 10px;
        width : 20%;
}

Re:Might be worthwile

[Dirtside]

but given the fact that creating a simple three column layout that works on every browser and looks good too is far from trivial, one can conclude two things:

        * Something's wrong with CSS

Nothing's wrong with CSS on its own terms... but I still don't understand why people think that Cascading Style Sheets should be used for layout.

Granted, HTML wasn't designed with layout in mind, either, but it's a hell of a lot simpler to make a table with HTML than it is to futz around with CSS positionings. Which is probably why most people still do it that way.

Re:Might be worthwile

[juiceCake]

What's so hard about making a three column layout in CSS? Way less code and work than using a table.

Re:Might be worthwile

[larry bagina]

How about the circumstance that you want something after the 3 columns? The absolute positioning screws that up. How about the circumstance that the window is resized? At smaller widths, the columns overlap each other. How about the circumstance that you want all 3 columns to have the same height? Every 3 column css/div layout I've seen fails at some of the above or require multiple layers of non-intuive divs and css hackery that make a table layout seem elegant.

Tables are overused, but they're less problematic than a 3-column css layout.

Re:Might be worthwile

[emurphy42]

How about the circumstance that you want something after the 3 columns? The absolute positioning screws that up.

Some more experimentation leads to the following:

max-height : 400px; overflow : auto;

How about the circumstance that the window is resized? At smaller widths, the columns overlap each other.

The widths are defined as percentages. If your window is small enough to break that, then it's small enough that nothing will look good.

How about the circumstance that you want all 3 columns to have the same height?

See "max-height" above.

Re:Might be worthwile

[emurphy42]

max-height : 400px; overflow : auto;

...but you probably meant "make the three columns as tall as they need to be, then position something e.g. 10 pixels below the tallest one". Anyone got a good solution to that one?

Re:Might be worthwile

[larry bagina]

If the screen width is too narrow, a left/right scroll bar is acceptable (in fact, preferable) to me. I tried the original example with the min-width: property (which ff supports) but that actually made the div overlap worse when narrow.

Re:Might be worthwile

[nick_davison]

but I still don't understand why people think that Cascading Style Sheets should be used for layout.

It may have something to do with a standard called CSS-P where the P stands for Positional. Weirdest thing, you tell people they can position things and they go all nuts about wanting to, you know, position things.

Re:Might be worthwile

[emurphy42]

If you're okay with any window width less than (say) 800 resulting in a left/right scroll bar, then you can define the column widths in terms of absolute numbers of pixels. This also keeps the columns at those widths when the window width is greater than 800, which may be considered either good or bad, depending.

Re:designer not developer

[Bertie]

My definition of a designer is that their role stops short of writing code, whether that's HTML, CSS, whatever. They don't concern themselves with how something's implemented, because then you find yourself thinking like an engineer, and working in terms of what's most expedient, rather than like an end user, and thinking in terms of what's best.

So if you're using this book, you're a developer, not a designer.

Re:designer not developer

[Peganthyrus]

Have you tried italicizing all spans with a lang attribute, then de-italicizing english-in-english, spanish-in-spanish, french-in-french, etc?

span:lang {font-style:italic}

body:lang(en) span:lang(en),
body:lang(es) span:lang(es),
body:lang(fr) span:lang(fr),
body:lang(dk) span:lang(dk) {font-style:normal}

paint with broad strokes, then carve out the exceptions.

(and check the syntax; I've never styled arbitrary xml documents, just ordinary HTML.)

Remember folks...

[jo42]

Tables Are Good.

Re:Remember folks...

[BLACKtactx]

yes they are...... for tabulated data :-)

Microsoft CSS thought about this...

[sheldon]

Seriously, I saw this in a css file:

td.LockTopLeft {
/*IE5+ only*/
    left: expression(this.parentElement.parentElement.parent Element.parentElement.scrollLeft);
    top: expression(this.parentElement.parentElement.parent Element.parentElement.scrollTop-1);
}

My initial response was what the hell does that do? But it actually locks this table entry within a parent div tag.

It's basically like the behavior in Excel where you freeze the top columns or something like that. So it's not a bad behavior to have, but like you say the only way to do it is to know ahead of time where everything is. difficult with dynamically generated data.

and so Microsoft embedded like javascript language into their CSS. It's completely non-standard, not supported by anybody else. And I keep wondering when will we something like this in the standard?

Re:Microsoft CSS thought about this...

[brunascle]

i had to do something like that once, where the left column and top row were frozen. i used javascript instead of CSS, though, and it worked in both IE and firefox.

for just the top row there is an easier way to do it, though, but IE doesnt support it: separate the header of the table using a thead and set it to position: static, i believe.

Re:designer not developer

[telbij]

Then your designers are better than your developers. A good developer should inherently understand the benefits of clean HTML, as well as the subtleties of what can be accomplished with CSS much better than a designer. Developers are always thinking in terms of code reuse and maintainability (at least if they're any good), whereas a designer is more concerned with how things look and maybe usability. The developer is the one who actually has to refactor HTML mockups from designers into templates, so (s)he is the one that should be concerned about bloated non-reusable HTML.

Good to hear that your design people know the benefits of CSS though.

Re:designer not developer

[Dynedain]

As a web designer and developer who works alongside several designers, I can assure you that understanding CSS is not a designer's role, but a developer's role. Once you are involved in coding (whether it's a Turing-complete language or simply a markup language) you are a developer. Now, I point my designer coworkers to various tools that will auto generate CSS, but purely for making it easier for me to interpret their intent (instead of relying on things like Photoshop values for text paragraph formatting which do not match CSS), and also so that they know what fonts and settings are viewable by the site's end users.

Here's a rule of thumb:

If you are defining things like this, you're in the designer role:

Font: Gill Sans
Size: 12.5pt
Leading: 20pt
Tracking: 30
Color: Pantone 420C

Whereas if you are defining things like this, you're in the developer role:

h3 {
        font-family: "Gill Sans", verdana, arial, helvettica, sans;
        font-size: 1.25em;
        line-height: 1.33em;
        letter-spacing: 0;
        color: #CCCCCC;
}

Is CSS a Failure? Use wysiwyg web editors?

[oldCoder]

If you need a 536 page book to "Master" such a trivial part of web development as page and text formatting then CSS is a failure. Are there any wysiwyg "Html editors" that produce portable CSS? If so, then the book is obsolete.

As any Word(tm) user knows, page layout and text formatting should be done Visually. I don't code in assembler any more. And I shouldn't have to write text-formatting codes. Troff was obsolete years ago! CSS is just Troff on steroids.

CSS is such a pain in the butt we should all go back to using tables. I really think it's easier.

Re:Is CSS a Failure? Use wysiwyg web editors?

[pwizard2]

I'm not sure if it's true anymore since I hand-code but back in the day the main problem with WYSIWYG editors is is that they tended to generate really bad code that was difficult to go back and edit manually. Some of the worst ones generated code that was deprecated in addition to this.

Even Adobe Imageready (as of CS2) uses a obsolete and backwards apprach to creating rollovers from image slices. This can be done with CSS, but even the latest version of Imageready uses a badly depecated table & javascript method that IE6 with SP2 will disable by default. It is for this reason that I don't use Imageready for rollovers anymore.

Re:Is CSS a Failure? Use wysiwyg web editors?

[Coffee Warlord]

CSS is such a pain in the butt we should all go back to using tables. I really think it's easier. Go back? I never stopped. I use CSS for text/form styles, and that's about it. Good old
fashioned HTML tables are where it's at. I'm perfectly happy sticking with what works.

CSS is pretty much the one thing developer-wise that really gives me that 'dinosaur' feeling.
Just don't see the need for those massive CSS files that try and lay out an entire site for
you. I'm not sure whether I'm just getting old and curmudgeony, or there really isn't a good
reason for laying out stuff in CSS.

Hell, might be both. :)

Re:Is CSS a Failure? Use wysiwyg web editors?

[itsdapead]

As any Word(tm) user knows, page layout and text formatting should be done Visually.

What any Word(tm) user with any experience knows, is page layout and text formatting should be done in anything other than fricking Word, except you have to send in a fricking Word file and exporting Word from any other applications almost works. At least OpenOffice is annoying and buggy for free.

Bearing in mind the web was invented by a bunch of physicists its a wonder that it uses HTML and not LaTeX Now, that would be fun: a default page design reflecting the acme of the typographers art (LaTeX output is really beautiful) and a vertical learning curve if you wanted to change that style.

Re:Is CSS a Failure? Use wysiwyg web editors?

[IAmGarethAdams]

Two points:

• Stuffing a whole site's styling into one CSS file is bad form, if vastly different styles are used on different pages then the differing bits should be in separate CSS files and linked to only from the relevant pages. Of course, this also give the freedom for common CSS to be included on every page.
• CSS files, being less frequently updated than web pages, can be cached and don't need to be redownloaded every page visit, unlike the equivalent table code

So, 'massive CSS files' isn't a valid argument against CSS

Re:Is CSS a Failure? Use wysiwyg web editors?

[MisterSquid]

CSS is such a pain in the butt we should all go back to using tables. I really think it's easier.

As I was learning CSS, I used to think this, too. In some ways it's true: using tables to get your layout done is easy because the form is apparent from the table itself. CSS obscures that to some extent with floats and margins.

But some things are possible in CSS that just cannot be done in HTML tables. For example, I can say something like "Unvisited ypertext links contained in a "navigation" div should be underlined and white text on black background. Everywhere else, unvisited hypertext links should be underlined blue text on a white background." That is, I can use selectors to target appearance (and form) based on class definitions. This is powerful stuff.

When I want to add a new div class, I can adjust for readability and emphasis across the entire web site by adjusting the CSS. Try it some time. You'll never use HTML to style your text again.

Re:Is CSS a Failure? Use wysiwyg web editors?

[TheGreek]

But some things are possible in CSS that just cannot be done in HTML tables. For example, I can say something like "Unvisited ypertext links contained in a "navigation" div should be underlined and white text on black background. Everywhere else, unvisited hypertext links should be underlined blue text on a white background." That is, I can use selectors to target appearance (and form) based on class definitions. This is powerful stuff.

You're confusing "style" with "layout," sir. Here's an example that uses CSS for style but tables for the actual layout definition:

<table class="content-layout">
  <tr>
      <td class="navigation"><a href="whatever.html">Whatever</a></td>
      <td class="content-pane">Content</td>
  </tr>
</table>

CSS is a very powerful and very effective tool for managing styles. It is, however, abominable at complex grid layouts.

Re:Is CSS a Failure? Use wysiwyg web editors?

[saltydogdesign]

Firefox and Web Dev toolbar = visual page layout and text formatting.

IMO, people who bitch about CSS haven't used it long enought to get it. It's not that terrible, and once you get in the swing of it, you'll realize it's vastly more powerful than the clunky old table.

Re:Is CSS a Failure? Use wysiwyg web editors?

[0x0000]

If you need a 536 page book to "Master" such a trivial part of web development as page and text formatting then CSS is a failure. Are there any wysiwyg "Html editors" that produce portable CSS? If so, then the book is obsolete.

Layout is not trivial. Clearly you have no concept of a) what you're talking about here, nor b) the power inherent in CSS.

There is no such thing as "WYSIWYG HTML". The "What You See..." part is CSS. HTML is not now, nor was it ever, intended to have anything to do with what you see - what you see is layout, and layout is the province of the stylesheet language - I.E. CSS. You might be able to make a good argument for a Visual CSS-aware Editor - in fact, I encourage you to... M$ should hvae done it with Word several versions ago - Open Office should have done it, Visio should have done it, Google PageMaker should have done it, Cold Fusion should have done it, the list of people who should have done it quite long - the list of who has done it is empty - probably for the same reason there are so many crappy, non-validating websites on the .com domain - because people like you just can't be bothered to get it right when you percieve there's a quick buck to be made doing it wrong over and over... That attitude you're flinging around gives the entire web design and development community a bad name, whether you know it or not...

Furthermore, There is more to the WWW than just "graphical browsers". How are your bastardized layouts using the TABLE element going to handle "layout" for e.g. a screen reader?

If you're only doing trivial things, you might get away with tables [provided you limit all your users to a small subset of client software], but if you think tables are even remotely useful for layout compared to e.g. CSS2 you are just sadly un-informed, and probably shouldn't be writing HTML, let alone building websites. In fact, the way you're carrying on about something that's been a standard for some time now, I would have to question whether or not you should try to involve yourself in any of the informatio disciplines - they pretty much all require adherence to some sort of standard, if if it's just the spelling or punctuation required to write English.

The "WYSIWYG HTML editors" which you postulate should exist - or rather, such pathetic attempts as have been made at such an animal invariably use TABLES for layout. All of them generate non-validating HTML, few of them even attempt CSS, and the ones that do generate broken CSS and/or broken HTML. In a word, they are crap [for non-trivial pages - let alone sites]. It seems that all the coders that produce such editors have an attitude very similar to yours - that is: totally lacking in understanding of what CSS is and can do, and equally lacking in any degree imagination that would take them [trivially] beyond the capabilities of the TABLE element as used for layout.

From where I sit, web developers who don't know and use CSS are just wannabes and diletantes, dude. Even the folks you might expect to support "Good Web Design" - e.g. OpenOffice or Google - can't produce credible [validating] HTML, let alone a useful stylesheet. Most of them *cough*Google*cough* are still using the FONT element, fer pity's sake, and some of them *ahem*google/picasa*cough* ship broken CSS in [it seems] a half-hearted attempt to force users back to a table-oriented layout...

Bottom line is,

1. CSS is the standard for web layout and presentation - deal with it
2. There are no WYSIWYG "HTML" editors - can't be, in fact, by definition, since HTML is markup - it would have to be a WYSIWYG CSS+xxML editor, since without CSS there is no way to control "What You See"....
3. If you want to create useful web sites, quit whining about how hard it is and learn the tools of the trade [CSS, XHTML, PHP, etc] - or are you still trying to write operating systems in BASIC?

Re:Is CSS a Failure? Use wysiwyg web editors?

[juiceCake]

If you need a 536 page book to "Master" such a trivial part of web development as page and text formatting then CSS is a failure. Are there any wysiwyg "Html editors" that produce portable CSS? If so, then the book is obsolete.

O'Reilly's latest HTML book is 670 pages. I guess that means HTML is a failure...

Re:Is CSS a Failure? Use wysiwyg web editors?

[MisterSquid]

You're confusing "style" with "layout," sir.

No I'm not. You're confusing my comment with one that does. When I'm talking about selectors within div classes I'm talking about style. I understand tables are useful for certain things, and my point is that the OP is suggesting everyone stick with tables. I gave an example, confined to style, where CSS was the clear choice.

Re:Is CSS a Failure? Use wysiwyg web editors?

[TheGreek]

You're confusing "style" with "layout," sir.

No I'm not. You're confusing my comment with one that does.

Oh, but you are, and it does. The comment to which you replied makes its scope very clear:

As any Word(tm) user knows, page layout and text formatting should be done Visually.

Page layout and text formatting. Sounds more like "layout" than it does "style."

I understand tables are useful for certain things, and my point is that the OP is suggesting everyone stick with tables. I gave an example, confined to style, where CSS was the clear choice.

CSS is the clear choice for styling text because tables don't style text. Only a moron without a clear understanding of HTML and CSS would suggest that they do.

CSS is great for styling text. It's utter shit for laying it out, though, mostly because of the hoops you have to jump through to get it to work with "every browser."

Tables and CSS can work together.

Re:Is CSS a Failure? Use wysiwyg web editors?

[MisterSquid]

You're quoting very selectively and distorting the original context. In particular, the OP makes reference to Troff. From the OP:

As any Word(tm) user knows, page layout and text formatting should be done Visually. I don't code in assembler any more. And I shouldn't have to write text-formatting codes. Troff was obsolete years ago! CSS is just Troff on steroids.

Troff, my garrulous interlocutor, is for text-formatting.

You are correct that tables don't style text, but the point the OP is making is about text-formatting aka style. This is what my original and subsequent posts address.

And, yes, HTML tables and CSS can and should work together. I have authored web pages that say as much.

Re:Is CSS a Failure? Use wysiwyg web editors?

[MisterSquid]

Mea culpa. The OP is talking about layout, not "formatting" which I mistakenly took to be "styling."

I have confused the argument from the word "go."

TheGreek: 1, mistersquid: 0

Re:Is CSS a Failure? Use wysiwyg web editors?

[oldCoder]

If the 670-page book is about nothing but HTML then either HTML is a design failure or the book is a writing failure. HTML is clearly a market success.

Re:Is CSS a Failure? Use wysiwyg web editors?

[juiceCake]

It sure is. The point is, the number of pages don't dictate whether something is a failure or success, which was the premise of this particular part of the thread.

ummm

[DuroSoft]

am I the only one that thought this was another countrstrike guide having read the title. LOL

Re:designer not developer

[Intron]

Easy: A designer is the one that hands a developer a 30 MB background image, 16 1MB panels and 100 33K widgets and asks why it takes so long for the page to load.

Re:designer not developer

[styrotech]

Yes, I wish CSS had support for if statements.


Hell, I'd be happy with just named constants for colors and numbers (and maybe even for whole or partial selector expressions?).

And now that we're dreaming here I'd be extra happy with math expressions for numbers especially if they could reference properties from other elements. That is starting to get a little like duplicating the DOM scripting stuff though.

ProgrammingBooks.org

[draed]

I hate to shill my own stuff, but I recently created a site for ranking programming books based on category(language, api, etc) that I think most developers will find very useful. Basically programmers rank their top 5 books for each category. It's very simple, and hopefully useful. It's in a pain finding quality programming books. The only real resource is browsing/searching through amazon, which can be a real pain.

http://www.programmingbooks.org/

For example, here are the top ranked CSS books: http://www.programmingbooks.org/CSS (not many users have ranked css books)

Re:designer not developer

[BLACKtactx]

Being a developer and a designer, I think that an understanding of both facets of the website/blog/whatever process is important to know. I think with the advent of CSS, the boundaries have certainly blured,and as other posts have said, a developer stops at image manipulation, a designer stops at coding. It is probably beneficial for a designer to know the limitations of html and css, in order to not give the developer one hell of a headache. It is also beneficial (although less so) for a developer to have an inkling of good design flow. Hopefully at the end of it all you will end up with a site that is good looking and maneageable. If these two seemingly disparate job descriptions cant harmonize, then you end up with a dog slow site that looks wonderful, but is completely unusable, or you end up with a great functional site that nobody stays at longer than 1 second due to retinal burn. I think to be the most employable, you must know css and html. Most job descriptions I have seen unless for larger teams dont make any distinction, instead wanting a do it all guy or gal.

Re:designer not developer

[rainman_bc]

But even just talking about CSS, is doing CSS really just design?

Especially with all the crappy designers out there who use Dreamweaver and really haven't a clue about CSS and could care less.

We're all stuck with .style1 {font: size 8pt; } .style2 {font: size 9pt; }
.
.
. .style39029 { font: size 10pt; }

Ohhhh JOY Yet Another Mystery Novel (YAMN)

[FlyingGuy]

Yeah you heard it here 1st. A new acronym, YAMN. CSS is becomming even more of a joke then it already is. And the worst part is that is a cruel joke.

As many have said in this string of posts, without the use of tables, it is no longer a job for the general web creator to create a three column lay out, without being a complete CSS guru and even for them it gives them headaches.

In my estimation, what the designers of CSS have managed to do is crush the life out of the promise that once was the a usable, if slightly clumsy, way to present information.

As an example. Using un-ordered lists to create menus. Its a complete and total hack, and I mean to use the word hack in the most derogitory manner possible. Instead of comming up with a menu framework that was designed from the ground up to be menus they used this stupid hack and think they are so cool. News for you, your not cool, your not smart nor are you clever.

There are elements of CSS that are quite functional and workable, but for the most part its just a cludge and a bad one at that. Lets take for example something that could make all of our lives easier, the basic ability to have include files. All you CSS lovers hate frames and you hate tables. Well with frames I can make ONE file contain the entire drop down menu section. I create it in one file and ONLY one file. I edit it in ONE file and ONE file only. So while you geniouses are comming up with HTML, DHTML, XHTML, CSS1, CSS2, etc. ad nausium, you cant seem to fit that simple part in there. Every freeking page has to have the complete menuing system in it and if anything has to be changed in it, like CONTENT someone has to go and edit 1 to n freeking html files, sorry, but for that you guys just plain SUCK.

Now I just know someone will think in regard to that last bit, that it should just be in a database! Well sure as shootin! Except why on fucking earth does a 10 page web site need to have a complete CRM system behind it? Why should it even have a database! Then you will say, but it is only 10 pages, you should write a VI or better yet an EMACS macro to handle that. Better yet anyone who would suggest that should get rectaly examined by the phalus of a donky. UL's twisted into menu's are not trivial and can be broken quite easily. Develop a MENU interface if you are determiend to turn something loosley associated with desktop publishing into a full on interactive bit of software.

The bottom line is this, if you want people to really embrace CSS then FIX IT. Get the venders to fix the browsers and if they wont fix it, then stop twisting CSS all over itself to accomodate them and just let it those browsers fail and the market will fix it.

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[Shados]

Indeed. Honestly, CSS started from a good idea. CSS 1 handled, well, styles, like fonts, colors, etc. Thats good, and CSS is good for that. It actualy makes sense for it, the syntax is peachy good.

Its when someone decided "Woooo, lets divide the page in 2, the logical structure and the layout!" that it got to become hell (aka: CSS2. For this post, I'll talk as if CSS2 was implemented at 100% in all browsers, to avoid some bozo saying "its microsoft's fault if you hate CSS blah blah blah).

Since CSS came about several years ago, back in the days, it probably made sense. Today, it doesn't.

A fairly typical enterprise web application has (for example, pulling stuff out of my ass):

an RDBMS.
a layer of stored procedures
a data access layer
a data transformation layer
business objects
a business logic encapsulation layer
a business service layer
a web service or remoting layer to distribute the app
a controler layer for the UI
the actual UI.

A lot of these gets split in more categories (validation, security, etc). Now, some bozos want to start splitting it up even more. Semantic markup, styling, and if you push it, transformation (XSLT), and more. It makes sense in a web site, or a simple business front ends, like mmost transactional ecommerce sites, that have like, 5 different pages that need to be maintained a lot. But when you have several hundreds pages with vastly different purposes...it just starts being pointless. The CSS1 part still has its place, to make a "theme" for the entire site. But positioning? You need 1 stylesheet -per- page, since each page is 90% different aside from the navigation. And most of the semantic part is generated from the layer right under the UI layer, so the structure vs display is -already- split. Its just redundant.

But since all the wackos that don't get that are extremely vocal, and have been pushing it like crazy, the browsers and the web in general are going that way. So for the being, we're stuck with it. Even worse, I recently got hired by a top fortune 500 company, and amazingly enough, I'm the only one who semi-advanced (relatively speaking) knowledge of web interface technologies, so I'm stuck dealing with all of it, because when trying to explain to the other programmers whats the difference between position: relative and position: absolute, I get blank stares. Oh well. At least thats job security...

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[juiceCake]

As many have said in this string of posts, without the use of tables, it is no longer a job for the general web creator to create a three column lay out, without being a complete CSS guru and even for them it gives them headaches.

It's very easy and requires less code than using a table.

In my estimation, what the designers of CSS have managed to do is crush the life out of the promise that once was the a usable, if slightly clumsy, way to present information.

In my estimation, they've given the web new life and promise, and increased interchangeability, not to mention making changes.

As an example. Using un-ordered lists to create menus. Its a complete and total hack, and I mean to use the word hack in the most derogitory manner possible. Instead of comming up with a menu framework that was designed from the ground up to be menus they used this stupid hack and think they are so cool. News for you, your not cool, your not smart nor are you clever.

How is it a hack? It makes semantic sense. You have a list of menu items. As for being cool, who cares about that nonsense.

There are elements of CSS that are quite functional and workable, but for the most part its just a cludge and a bad one at that. Lets take for example something that could make all of our lives easier, the basic ability to have include files. All you CSS lovers hate frames and you hate tables. Well with frames I can make ONE file contain the entire drop down menu section. I create it in one file and ONLY one file. I edit it in ONE file and ONE file only. So while you geniouses are comming up with HTML, DHTML, XHTML, CSS1, CSS2, etc. ad nausium, you cant seem to fit that simple part in there. Every freeking page has to have the complete menuing system in it and if anything has to be changed in it, like CONTENT someone has to go and edit 1 to n freeking html files, sorry, but for that you guys just plain SUCK.

I use include files all the time. CSS in no way prevents you from using them. Furthermore, the style sheets are very much like include files in that you go to one single sheet and make changes and the changes are reflected site wide. Every page in a CSS programmed site does not have to have the menu in every page, you just use an include to avoid that. It's interesting that you're calling people geniuses in a derogatory manner when you don't know what you're talking about.

Now I just know someone will think in regard to that last bit, that it should just be in a database! Well sure as shootin! Except why on fucking earth does a 10 page web site need to have a complete CRM system behind it? Why should it even have a database! Then you will say, but it is only 10 pages, you should write a VI or better yet an EMACS macro to handle that. Better yet anyone who would suggest that should get rectaly examined by the phalus of a donky. UL's twisted into menu's are not trivial and can be broken quite easily. Develop a MENU interface if you are determiend to turn something loosley associated with desktop publishing into a full on interactive bit of software.

No you don't know what someone will think in regard to the last bit, unless of course they don't know what they're talking about whatsoever, like yourself. Databases are great for data heavy, frequently changing sites that can be changed by non-developers, but simple lesson in some basic editing is fine for a small site. Just have them edit the include files that you, for some reason, think are news to everyone.

The bottom line is this, if you want people to really embrace CSS then FIX IT. Get the venders to fix the browsers and if they wont fix it, then stop twisting CSS all over itself to accomodate them and just let it those browsers fail and the market will fix it.

Many people are embracing it. They embrace it so much that they actually know what they're talking about. Fixes have been a priority for most vendors as well. There is some twisting in regard to IE, but until recently, that particular browser didn't move at all for years in terms of development.

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[Simetrical]

As an example. Using un-ordered lists to create menus. Its a complete and total hack, and I mean to use the word hack in the most derogitory manner possible. Instead of comming up with a menu framework that was designed from the ground up to be menus they used this stupid hack and think they are so cool. News for you, your not cool, your not smart nor are you clever.

What would you prefer? A table? Surely no better. But lists have advantages: for instance, some mobile devices will cleverly collapse lists by default, so that they don't take up valuable screen real estate. Screen readers may audibly delineate lists in some way. And so on. If you don't care about people not using the browsers you checked things out with, hey, by all means stick with tables.

If you're suggesting that a tag or somesuch be introduced, again, that's not CSS. It's the fault of HTML. The last draft of XHTML 2.0 that I looked at had a navigation list tag in it, for what it's worth.

And if the problem is just that you think any complicated style rule is a "hack", well, frankly I think it's more legitimate to say that table-based layout is a hack, since it's not what the original versions of HTML meant for that to be used for at all.

Lets take for example something that could make all of our lives easier, the basic ability to have include files.

You utterly misunderstand the entire purpose of CSS. It is meant to be for styling. Not for content inclusion or anything similar. For that, you could use XSL, maybe. Or you could use a CMS. Or, yes, you can use frames. CSS is deliberately designed to not slow down page rendering much, so something that requires you to wait for a server response is totally unacceptable for it (even reflows of already-rendered content are unacceptable).

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[Anonymous Coward]

Usually I'm content just to read other people's comments and letting the Slashdot market-force correct misconceptions, but you, sir, have forced my hand. I know there's already an good reply by another poster, but here's my take.

As many have said in this string of posts, without the use of tables, it is no longer a job for the general web creator to create a three column lay out, without being a complete CSS guru and even for them it gives them headaches.

Umm.. no. Among the many ways one can do this, one of the simplest one will take all of.. four divs, 1 parent and 3 contained siblings. If you want more precise controls, then of course, you have to delve deeper into the levels of complexity - but how is this different from so many sites using meshed colspans and rowspans just ot get elements positioned just the way you want it?

In my estimation, what the designers of CSS have managed to do is crush the life out of the promise that once was the a usable, if slightly clumsy, way to present information.

Yes, yes.. as much I hold your esteemed estimation in the highest regard, I must respectfully point out that CSS allowed us to break free of having to litter our pages with a myriad of <font>, <b>, and <i> tags, not to mention repeatedly setting the same properties to all elements of the same class by hand. Oh, and you want to change the background color of every single one of 20 pages? Good luck to you sir!

And that was just some examples of the uses of CSS; semantic groupings of logical 'classes' of elements, and separation from content, which makes it easier to apply the same style to many different pages with different content. it's not even taking into account the finer grain of control one gains over your element - how would you postion your company logo exactly at co-ord (10, 15) without CSS or VB/Javascript? How would you specify links to turn bold on mouseover? Oh, I'm sure you'd prefer the good ol' days of the <blink> tags and HTML-only formatting, but people these days a somewhat more demanding taste..

As an example. Using un-ordered lists to create menus. Its a complete and total hack, and I mean to use the word hack in the most derogitory manner possible. Instead of comming up with a menu framework that was designed from the ground up to be menus they used this stupid hack and think they are so cool. News for you, your not cool, your not smart nor are you clever.

Ignoring that rather high-schoolesque remark at the end.. What *is* a menu, if not a list of choices? What do you think it's stored as for most applications? Heck, how else do you think it's stored in a Javascript menu (hint: arrays are a kind of ..)? What CSS does is to take that unformatted list, and makes it look slick and polished for the user. What would you prefer, tables for menus?

As for the comment about a new framework for menus.. may be workable I guess. But still, what's the point of coming up with so many specialized tags? Yes, it will have to be a HTML tag - unless you meant taking that UL and making it display like a menu, which of course, by your definition, would be the 'most deragatory manner of hacks'.

There are elements of CSS that are quite functional and workable, but for the most part its just a cludge and a bad one at that. Lets take for example something that could make all of our lives easier, the basic ability to have include files.

I'm sorry.. you hadn't heard of @import? Oh, you meant content including? Pray tell, how/why is CSS supposed to handle content? Sometimes I wonder if you know the difference between CSS & HTML, and which you're ranting against..

All you CSS lovers hate frames and you hate tables.

Um.. no. Frames are fine actually. They're a bad way to do things, b

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[Isofarro]

There are elements of CSS that are quite functional and workable, but for the most part its just a cludge and a bad one at that. Lets take for example something that could make all of our lives easier, the basic ability to have include files. All you CSS lovers hate frames and you hate tables. Well with frames I can make ONE file contain the entire drop down menu section. I create it in one file and ONLY one file. I edit it in ONE file and ONE file only.

CSS isn't a content language, its a styling language. A styling language that relies on the underlying semantics of the markup language you are using.

Your problem has been solved over a decade ago:

• SSI: What is SSI?
• HTML preprocessing: What is an HTML preprocessor?

Of course, using SSI means using a webserver and configuring it properly. Even decent shared hosting gets that right. Might not work on Geocities though, but HTML preprocessing will.

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[TheGreek]

Ok show me the Include tag in html?

Hey, there, cowboy. It's not 1996 anymore.

The ol' World Wide Web has moved on from static lists of your favorite websites that you put up on your 5MB of University webspace.

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[saltydogdesign]

I don't know what site you are working on in which each page is 90% different, unless perhaps you are applying absolute positioning to each paragraph. In my experience, it's not nearly as complicated as you make it out to be -- one default stylesheet, which encompasses probably 80-90% of what is needed, and spot stylesheets where needed. Typically that means a spot stylesheet for major site buckets, not that big a deal.

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[An Onerous Coward]

... when trying to explain to the other programmers whats the difference between position: relative and position: absolute, I get blank stares.

Well, the concept isn't that difficult to put across, and your communication skills are probably fine.

You might want to make sure your fly is zipped.

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[peepleperson]

5MB of University webspace 5MB? 640KB was enough.... *ducks*

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[Shados]

Hahaha, sorry, I was trying to find a simple example. But while the difference between the two is simple, its the little "CSS quirks" as I like to call them, that gets the blank stares, not the concept itself. The way, for example, that the position: whatever attribute's behavior varies -wildly- depending on the parent container... or things like, according to the specs, a floated element needs a width attribute, but isn't all that precise as to what happens if you don't specify one, etc. Ever (at least when you were new to CSS), looked for a few hours for a weird behavior (that was not one of IE's bugs!) that seemed to defy logic, until you looked the specs up, just to find a paragraph of "If the parent is this way, the behavior is that way, otherwise its this wildly different result, and if you do XYZ, then its up to the browser's implementation, so don't do it"). That alienates rich client developers moving to the web realms, something fast...

Re:Ohhhh JOY Yet Another Mystery Novel (YAMN)

[Shados]

No, the pages are fairly similar in themes (colors, backgrounds, etc). They different vastly in -layouts-. I'm talking about a typical business management transactional web site. You can get all the field widths, font formattings, everything relating to navigation, titles, headers, borders, what have you in 1-2 CSS files and thats fine. The issue comes with the forms for example.

One page you'll have a menu of elements ala Windows Control Panel, bunch of floated stuff. The next you'll have a master detail order entry. The next will be a bunch of radio buttons. The other a ton of cascading dropdowns. The next will have drag and dropped divs. The next...you get the idea? You have hundreds of screens. A lot can be put in the same package (a master detail is a master detail is a master detail...usualy), so you can share a lot... But (almost) each screen will have one or two screen specific functionality, as simple as they are, and it adds up. You don't want your users to load up the entire app's styles if they're only going to ever be using 1-2 screens. So the only solution so far that I've seen, is to either: style inline (rofl, better off using font tags and table layouts than using CSS inline...), or have a sheet per page... Awkward, but not much one can do beyond relaying the extra to the preprocessor/backend language, and then you might as well not be using CSS at all... So I've been doing it that way, 1 CSS per page, plus a main set shared by everything... It works, but it feels stupid.

Re:For those who don't know about referral spammin

[larry bagina]

point 3: the referral doesn't affect the price.

If I buy the book through that link, I'll save $6.30. How is that bad? The fact that someone else makes a some money in the process doesn't adversely affect me (in fact it save me money).

Re:designer not developer

[zdislaw]

A designer who has only a rudimentary understanding of what can and can't be done using XHTML/CSS is only a rudimentary Web designer.

Better thing to conclude

[Aewyn]

I haven't read the book, but given the fact that creating a simple three column layout that works on every browser and looks good too is far from trivial, one can conclude two things:

• Something's wrong with CSS

A better conclusion:

• Something's wrong with the CSS support in at least one browser

Specifically, if IE supported display: table-cell et.al., such a layout should indeed be quite trivial. But support for this is apparently still missing, despite the fact that the relevant spec is more than 5 years old.

Re:Better thing to conclude

[irc.goatse.cx troll]

Isn't that kind of cheating though? "table layouts are bad, but as long as we just make this act like a table layout we'll be fine"

Not saying I wouldn't end up using it if I could, but it just seems hard to knock table layouts when the ideal solution is making css render something as if its a table.

Re:Better thing to conclude

[Aewyn]

I don't think so. One of the problems with the old layouts is that everything tends to be marked up as tables, usually lots of them deeply nested. With CSS it's possible to use tabular layouts for only relevant parts of the design (if there are any), and other, more suitable techniques for the rest.

Also, expressing layout in CSS instead of in the HTML itself means that content and style is separated. Only data that's actually tabular, semantically speaking, needs to be marked up within elements. This approach can be more device-independent, consume less bandwidth (site-wide stylesheets that rarely change can be cached separately), be easier to maintain etc.

(Seems CSS3 will include special properties for multi-column layout as well, looks even easier to use)

Re:designer not developer

[juiceCake]

Using Dreamweaver is not the problem. It's the designers, entirely. Many designers/developers, etc. use Dreamweaver and know all about CSS.

Re:Good Book. Bad Index.

[Selanit]

I bought both the Definitive Guide and also the Pocket Reference. They're both by Meyer - the Pocket Reference packs all the vital info into 128 pages. And it really IS a pocket reference, in that it literally fits in my back pocket.

The index in the pocket reference is good. It's got everything I need. But if it didn't, I could give them feedback: there's a line at the bottom saying "We'd like to hear your suggestions for improving our indexes. Send email to index@oreilly.com."

I think I'll send them an email saying that the correct plural of "index" is "indices." Mwa ha ha ha.

My standard.

[Anonymous Coward]

"IE7 is no better. Still no border-radius?"

Oh whaaaa! MS doesn't support -moz-border-radius, or -o-border-radius. So much for supporting standards.

Re:My standard.

[1110110001]

They could call it -ie-border-radius if they don't like implementing a working draft. But it's already defined: http://www.w3.org/TR/2005/WD-css3-background-20050 216/#the-border-radius It's very similar to -moz-opacity, which is now in the CR: http://www.w3.org/TR/2003/CR-css3-color-20030514/# transparency

Re:designer not developer

[Simetrical]

I realize that CSS is not a programming language. More's the pity; if it were a little more like a language then a lot of things that are very hard to do in CSS and require dynamic styles (or at least assignation of styles) to do properly would be very easy. For example, I should be able to say that an element is n% minus the width of another element... But since I can't I have to figure out how many units (typ. pixels) are in n%, then figure out how many units wide the other element is, and then set the width of the element I was trying to size accordingly. And if the element I'm trying to fit in next to is sized in ems instead of px, I have to recalculate this data and resize elements every time the font size is changed.

The current Working Draft of the CSS3 Values and Units module allows for a calc() function that permits this behavior. Generally, yes, many things would be easier if an embedded programming language would be allowed, but this would potentially come at a significant speed cost. Part of the idea behind CSS is that it should not greatly slow down rendering as compared to simpler layout schemes.

Re:designer not developer

[Simetrical]

If this is a valid CSS3 selector, I think it will do what you want, but I'm not totally clear on where function-style syntax is allowed: body:not([lang|=attr(lang)) span[lang] {...}. Of course, it won't work for languages declared using anything but the lang attribute, but it might be a start.

Re:Eric Meyer, the HTML-TABLE killer!!

[delinear]

It's funny that you should blame Meyer for suggesting that the technology be used the way it was intended to be used, rather than blaming MS for creating a browser with poor CSS support which forces developers to, as you say, spend time debugging code across browsers. Incidentally, try adding a border, margin and padding to a fixed-width table and see how well that displays cross-browser...

Re:designer not developer

[drinkypoo]

Generally, yes, many things would be easier if an embedded programming language would be allowed, but this would potentially come at a significant speed cost. Part of the idea behind CSS is that it should not greatly slow down rendering as compared to simpler layout schemes.

I'd frankly be happy with some pretty damned simple expressions. I just want to be able to refer to elements by ID (and offset or otherwise manipulate them) so that I can base certain values on values in other elements. Is that so wrong? :)

Re:For those who don't know about referral spammin

[An Onerous Coward]

I think the issue (such that it is) falls under the category of "conflict of interest." If you're writing a book report, and giving it a glowing review, and providing a link that will give you money if people buy the book, it becomes more difficult to accept the glowingness of the review on its own terms.

It's not a huge deal to me, but it may be to some people.