Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

CSS Pocket Reference

samzenpus posted more than 6 years ago | from the read-all-about-it dept.

Book Reviews 87

Michael J. Ross writes "For Web developers who appreciate the value of separating Web content from its presentation, Cascading Style Sheets (CSS) has proved a godsend, because it allows all of the styling of a Web site to be organized in CSS files separate from the site's semantic content, in HTML files (possibly dynamically generated). Yet to make this styling power possible, CSS must incorporate a long list of syntax elements, including hundreds of selectors, properties, and values. Thus it can be quite handy for the developer to have on hand a concise summary of CSS, such as the CSS Pocket Reference, authored by Eric A. Meyer." Read on for the rest of Michael's review.The book was published by O'Reilly Media on 5 October 2007, under the ISBNs 0596515057 and 978-0596515058. CSS itself has evolved along with other Web technologies, and this book is now in its third edition, having been updated to reflect the ongoing changes in CSS; the book now covers CSS2 and CSS2.1. On the book's Web page, O'Reilly offers an online table of contents, as well as ways for the visitor to view and submit errata (none as of this writing) and reviews for the book. Unlike most technical publishers, O'Reilly now makes available previews of their books' contents, in the form of a table of contents with links to the first few paragraphs of each section, including tables and illustrations.

Despite the growth in the number of elements in CSS, and the attention paid to each one of them by the author of CSS Pocket Reference, the book is still small enough to fit in a pocket, at only 168 pages. The book's material is organized into 18 unnumbered sections, preceded by some notes on the book's typographical conventions, and followed by an essential index. The bulk of the material is found in the Property Reference section. Other sections explain how to add styles to HTML and XHTML pages; CSS rule structure and style precedence, including inheritance and the cascade; element classification and display roles; visual layout; rules on floating and positioning; and table layout. Subsequent sections cover CSS value types and units, and selectors, including some of the newest additions to CSS, such as the adjacent sibling selector and the language attribute selector. Just before getting into the details on properties, Eric Meyer discusses pseudo-classes and pseudo-elements, which have made it possible for Web developers to create rather robust and attractive site navigation using CSS exclusively, without any need to resort to images and JavaScript for rollover effects and other navigation eye candy.

For each element of CSS that is covered in all of the sections mentioned above, the types of information presented to the reader can vary, depending upon the category of element. But they generally include the element's possible values, a default value, what elements it can apply to, whether it is inherited, its computed value, a brief description of the element, at least one example illustrating its usage, what browsers support it, and oftentimes a note on its usage. Consequently, this new edition of the book, like its predecessors, should prove more than adequate for most CSS reference needs.

As with any computer book, there are several ways in which this one could be improved. Any reader using the book to look up a particular element, has two possible ways of doing so: They could first consult the index, and, assuming the element is listed there, go straight to the page indicated. But most readers, knowing that the elements in each section are listed alphabetically, will probably open up the book near the front or the back, and begin flipping backward or forward, respectively, hoping to spot the element of interest as quickly as possible, given its alphabetical ordering. That individual will likely immediately spot an obvious problem with the book: The pages have no running titles (the words that indicate the first element discussed on that page, and typically listed at the very top of each page). Inclusion of such running titles in the next edition of the book, would make it much faster to use.

Another valuable addition would be some sort of table listing all of the CSS elements and their level of support within the most commonly used Web browsers and, in the case of Internet Explorer, the most commonly used versions of the browser. Also, on page 48 of the book, at the beginning of the Property Reference section, it has a subhead of "Visual Media," which suggests that there are other subheads within that section, for other media types; but I was unable to find any.

All of these problems concern the publisher's choice of material. My last criticism concerns the layout of that material in the print version of the book. Because this diminutive volume has narrow pages, and they are tightly glued together in the binding, it is imperative that the publisher of such a book provide plenty of white space in the inner margins (those closest to the binding), so the reader does not have to crack open the book too much in order to read the text closest to the binding. Repeatedly opening up the book far enough to read those inmost words, will over time weaken and eventually destroy the binding. In contrast, a small reference book like this has no need for much outer margin. Sadly, O'Reilly got it backwards with this volume, with relatively wide and useless outer margins, and inadequate inner margins.

Aside from the aforementioned flaws — all of which can be remedied in the future — CSS Pocket Reference is a compact and neatly organized gem of a book, packed with information of value to busy Web programmers.

Michael J. Ross is a Web developer, writer, and freelance editor.

You can purchase CSS Pocket Reference, 3rd Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


I like it (0)

Anonymous Coward | more than 6 years ago | (#21675213)

Find it handy. It has some typos. And unfortunately the binding broke, but it was worth it.

Re:I like it (5, Funny)

Intron (870560) | more than 6 years ago | (#21675895)

"It has some typos. And unfortunately the binding broke"

So the book is just like CSS in general.

Browsers? (3, Informative)

WinterSolstice (223271) | more than 6 years ago | (#21675289)

I note that he mentions there is a list of "browsers that support" any given tag, and some notes. If it actually has some of the quick workarounds for the different browsers, I'm so buying this book.

I hate setting up something, then spending hours looking up workarounds for some random tag or other on IE.

Re:Browsers? (3, Insightful)

ls -la (937805) | more than 6 years ago | (#21675429)

I've stopped bothering to spend more than 5 minutes figuring out any IE bug. Granted, my pages aren't widely used, mostly testing stuff out and internal school pages, but IE is more trouble than it's worth. All the public computers here have firefox, so no one can really complain anyway.

STOP THE PRESSES: I have to go for a shit!! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21675555)

I'll write a review when I get back, which will include girth, color and smell.

Re:STOP THE PRESSES: I have to go for a shit!! (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21676767)

Please include the volume of tucker max sperm up your poop chute.

Re:STOP THE PRESSES: I have to go for a shit!! (1, Funny)

Anonymous Coward | more than 6 years ago | (#21677993)

I'll write a review when I get back

Dude, it's been like three hours. Are you OK in there?

Re:Browsers? (2, Informative)

ComputerPhreak (1057874) | more than 6 years ago | (#21676351)

Back when Firefox wasn't really used a lot of web developers felt a lot like you:
I've stopped bothering to spend more than 5 minutes figuring out any Firefox bug. Granted, my pages aren't widely used, mostly testing stuff out and internal school pages, but Firefox is more trouble than it's worth. All the public computers here have IE, so no one can really complain anyway.

It's coding for one web browser that lead to the mess of pages that 'only work on IE'. Just because Firefox happens to be more adherent to the standards doesn't mean that it doesn't have its own quirks. You should develop to the standard, not to your favorite browser's implementation of it.

Re:Browsers? (5, Insightful)

an.echte.trilingue (1063180) | more than 6 years ago | (#21676657)

Yeah, except that it's not Firefox: it's writing to THE W3C STANDARD which Firefox and almost every other browser that exists (including Opera and khtml based browsers such as Konqueror and Safari) just happen to render correctly (with a couple of caveats).

IE, on the other hand, is a freaking nightmare. I find that IE7 works pretty well; in general I can fix its small bugs by changing the css in ways that don't break the standard or break rendering in other browsers, but IE6 is so horridly in compliant that even for a lot of really common css tasks that were around long before IE6 was released and that Microsoft helped to write are totally broken. Things like the :hover pseudo class and default element margins and padding are totally broke. Floats act funny. You cannot fix it without breaking compliance with the standard and other browsers, which means that you have to write a special css file for IE6. It's not even consistent within versions of IE: IE5.5 and 5.5 for Macs don't render the same code in the same way.

So, IE7 finally mostly works, but MS fucked the user interface up so bad that everybody wants to stick with IE6, which is still the world's most common browser over a year after IE7's release. Do you realize how bad that is? How many people haven't upgraded from Firefox 1.5 to Firefox 2?

I can only conclude that Microsoft does this kind of stuff on purpose. They have a standard for trident: their web development products always produce code that renders perfectly in all versions of IE. Rendering the w3c standard is not hard: a bunch of hobbyists and a small company in Norway have both separately proven that you can do it on relatively limited resources. The only reason they could possibly have for their horribly broken browser is that they have an interest in web standards being broken.

Ok. Rant over.

Re:Browsers? (2, Informative)

bcat24 (914105) | more than 6 years ago | (#21677387)

Mod parent up. These days, if I design a website, I get it working in a modern, standards-compliant browser first. (Personally, I use Firefox, but like the parent said, it's certainly not the only choice.) Then and only then will I start putting in workarounds for browser bugs. (IE 6, I'm looking at you.)

Re:Browsers? (1)

FLEB (312391) | more than 6 years ago | (#21677821)

Maybe it's just my skewed perspective, but I don't see how you can design with a non-standard browser in mind. Most of the documentation you'll find is written to the standard, or in the case of non-standard bugs, it's mentioned that alternate means are necessary to get around a problem. It's not like you'll find a CSS tutorial that teaches to the Whitespace Bug or the 3-Pixel Float Bug. I suppose you could make a "browser-specific" page by including things like ActiveX or XUL, but that's a conscious enough decision that you'd know the implications.

Re:Browsers? (1)

bwilliams80 (1006961) | more than 6 years ago | (#21680175)

i would bet my firefox brower the reason many browsers are IE6 is because of the Windows Genuine Advantage software that needs to pass before IE7 can install.

Re:Browsers? (2, Informative)

Walter Carver (973233) | more than 6 years ago | (#21682193)

Look up on "conditional comments" for IE. They allow you to add styles (and consequently override existing rules) that only IE can see. Also, test your pages in IE as you create them. It only takes a few minutes to fix an IE bug that just popped in, rather than try to fix the whole page.

Re:Browsers? (1)

moderatorrater (1095745) | more than 6 years ago | (#21677839)

That's a fine attitude to have if you don't care if people can see your pages. If you want people to be able to view your pages properly, however, then you have to depart from the standard. Maybe one day the standard will be applicable in the real world, but that day is not today.

Re:Browsers? (1)

techno-vampire (666512) | more than 6 years ago | (#21679851)

You should develop to the standard, not to your favorite browser's implementation of it.

Exactly. I'm registered at a pair of sites that send out surveys, and I get paid anywhere from $1 to $5 for each one I qualify for and complete. One of them sometimes sends out surveys that only work on IE. I don't even bother going to them because I hate having to open IE. (And what if I were on Linux, and didn't have it available? Would that mean my opinion didn't count?) I've mentioned this to the company's support critters, but, as they point out, they only redirect me to the client's site and can't force them to write code that works in all browsers.

Re:Browsers? (1)

biojayc (856286) | more than 6 years ago | (#21680269)

You can use wine to run ie6 pretty effectively. I've noticed that firefox in linux doesn't seem to render things the same as it does on windows though. Is there a reason for this? I'm specifically talking about when flash is involved. Is this just a flash bug in linux?

Re:Browsers? (1)

Mex (191941) | more than 6 years ago | (#21678107)

Even so, it would be a good idea to note why your pages undert IE might look broken. Otherwise, I've noticed people just blame your coding.

Re:Browsers? (4, Insightful)

CRCulver (715279) | more than 6 years ago | (#21675437)

It's not as if this is the first guide to designing for all browsers. CSS Mastery [amazon.com] by Budd et al., the CSS guide I've been using lately, gives plenty of info on tag support and collects a number of useful hacks, and it's been out for only two years. And remember, this Slashdot review is for a O'Reilly pocket reference. That whole series consists of little more than what one could find in free sources, and though I've bought a couple of volumes, they've been more to provide reading while I'm away from the computer (using a laptop at the cafeteria is messy) than for essential reference while I'm at work.

Re:Browsers? (0, Offtopic)

CastrTroy (595695) | more than 6 years ago | (#21675633)

One O'Reilly book I would recommend is Mastering Regular Expressions [amazon.com]. It contains a lot of insight into how regular expressions work, and how you can optimize your Regex's to get faster results. It also has language specific sections on .Net, PHP, Perl, and Java. I used it for learning regular expressions, and still find that it's a good reference even now that I am more skilled.

Mod parent off-topic (1)

CRCulver (715279) | more than 6 years ago | (#21675833)

Except that's not an entry in O'Reilly's "Pocket Reference" line. I was not speaking about O'Reilly's publications in general.

Re:Mod parent off-topic (1)

CastrTroy (595695) | more than 6 years ago | (#21676061)

Well, they do have a Pocket Reference [amazon.com]. I haven't seen it myself, so it's hard to gauge how good it is. However, from what I can gather, it seems like the last for chapters of the full version. Basically a syntax reference for .Net, PHP,Perl and Java. Which I've found extremely valuable.

Re:Browsers? (0, Redundant)

snl2587 (1177409) | more than 6 years ago | (#21675449)

...which is why I'm glad I develop for a university where over half of the student body uses Firefox, so I can develop for Firefox first and foremost and then make it look decent in IE. Granted, most things look identical, but some of the really cool stuff only works in Firefox.

Re:Browsers? (5, Funny)

Bazman (4849) | more than 6 years ago | (#21676135)

So, did you make this pie chart?

http://humor.beecy.net/geeks/web-design/web-design.gif [beecy.net]

Re:Browsers? (1)

cbart387 (1192883) | more than 6 years ago | (#21677747)

That pie chart hits too close to home. Frequently I'll have a siteslooking good (source code & from the browser) until I do cross-platform check. Then out comes the ugly hacks :/

Re:Browsers? (1)

IdahoEv (195056) | more than 6 years ago | (#21680673)

That's fucking brilliant, and so true. Except that I've seen "make it work in IE" take up to 80% of the time in some of my projects. No exaggeration.

These are usually the ones that want both W3C compliance AND compatibility back to IE 5.0. Particularly if the designers then hand me stuff that can't be easily implemented without partial transparency.

IE is a fucking nightmare. Seriously. It has retarded the development of the web by several years at minimum.

Re:Browsers? (1)

macurmudgeon (900466) | more than 6 years ago | (#21685437)

80% of the time adjusting for IE? Wow.

I know that it's popular to trash IE. We all do it, But its bugs are well documented and workarounds have been posted for the vast majority of them. It's a wonderful thought to want to build for browsers that have full version 2 CSS (and JavaScript) compliance, let's see that's, uh... Well someday a browser might support all of the existing recommendation. All browsers are deficient. IE is just more so.

Working with IE requires an attitude adjustment as much as technical skills. Knowing what you can do and coding for the shortest IE conditional style sheet(s) from the beginning should shorten development time to something reasonable. Also communicating amongst different departments might be encouraged. If designs that require full alpha transparency in IE 5 are coming to you often, a friendly little sit down earlier in the process would be helpful.

Re:Browsers? (1)

Stan Vassilev (939229) | more than 6 years ago | (#21677887)

I note that he mentions there is a list of "browsers that support" any given tag, and some notes. If it actually has some of the quick workarounds for the different browsers, I'm so buying this book.

What I can not figure out is, why use a printed book to tediously look up a bug into, when a good IDE or editor does the same for you automatically.

TopStyle or Dreamweaver will not just assist and autocomplete CSS properties for you, they'll check your HTML/CSS code on the fly against a list of selected browsers you want, and offer tips on common bugs your code may cause, as well as common solutions.

Also, this is the second time CSS "pocket reference" is reviewed on Slashdot (maybe the same one), and I wonder: who buys a *reference* manual as a printed book in the 21-st century. Maybe to have it handy on the road when you have no laptop around? Because, of course, the thing you'll be doing on the road, with no laptop, is debugging CSS.

I just stick to computer books for lengthy theoretic materials, that's read from start to finish. Such as, say, compiler design.

Re:Browsers? (1)

WinterSolstice (223271) | more than 6 years ago | (#21678501)

Well, for my part, I use mainly Vim and edit/tpu for creating pages. I do some work with Eclipse, but in general I'd say 90% of my pages are done by hand.

No, they're not huge amazing apps or pages.
Yes, they are important - things like SAP reports, system uptime reports, graphs, charts, metrics of all types. Stuff like that - mainly backoffice pages that I use to make management happy by giving them the data they want in easy ways.

So, for me, a pocket guide that I can toss next to my laptop for a few days while I'm writing one of these sites is helpful. I can find something in a few seconds, without having to question the veracity of the source (like with a general web query) or put up with tons of ads.

Re:Browsers? (1)

Brandee07 (964634) | more than 6 years ago | (#21685107)

I own a copy of this pocket guide (and they're not kidding, it fits in a pocket). It gives you a listing of what browsers fully supports what, what is outright broken, and what behaves strangely and how so- and if possible, how to fix it, for Opera, Safari, IE, Firefox, etc, and for specific versions of said browsers. It's absolutely indispensable.

Yes, you can look all of these things up online, but rarely are they in one place and neatly organized.

I liked this guide (5, Funny)

Anonymous Coward | more than 6 years ago | (#21675309)

But I couldn't find any info on nested tables.

Re:I liked this guide (2, Informative)

Bill Hayden (649193) | more than 6 years ago | (#21675737)

If you are labeling this informative instead of funny, then you are not a web designer and the joke has gone right over your head.

Re:I liked this guide (1)

Hamstaus (586402) | more than 6 years ago | (#21680265)

Moderators often mod 'informative' instead of 'funny' to award karma, as Slashdot took away karma rewards for the 'funny' mod a long time ago.

Re:I liked this guide (0)

Anonymous Coward | more than 6 years ago | (#21676783)

what about nbsp; nbsp; nbsp; one pixel transparent fillers?

Re:I liked this guide (1)

Ed Avis (5917) | more than 6 years ago | (#21676845)

Yes, this must be the number 1 CSS question: how do I lay out my page with two columns, or otherwise reproduce the same layout I can trivially get by using elements? The only answers I've seen have been complicated and frilly (like most CSS tutorials) but, being a CSS neophyte, I was hoping for an idiot-proof guide 'instead of _this_ do _this_'. Or is it just not possible to use CSS to get the same control over layout that you have with nested tables?

Re:I liked this guide (1)

TheRaven64 (641858) | more than 6 years ago | (#21677611)

Did you read the section on the CSS box model in the specification? It is very long, and full of examples. Nest your divs, and you can use this recursively on each one. Slashdot has used CSS with nested divs for a couple of years now for its layout...

Re:I liked this guide (1)

Ed Avis (5917) | more than 6 years ago | (#21681839)

That's my mistake - not reading the spec but visiting any number of half-baked E-Z TEACH YOURSELF CSS 4 DUMMIES websites. I'll print it out and go through it some weekend.

Re:I liked this guide (1)

mike2R (721965) | more than 6 years ago | (#21682081)

But once you've done that you have to test the hell out of it, and probably go back to those sites, to deal with the inevitable browser bugs your going to find.

I'd *like* to use pure CSS layouts, but at the end of the day tables work; consistently and quickly.

Tables? Pah! (0)

Anonymous Coward | more than 6 years ago | (#21678387)

<div class="top-left-corner"><div class="top-right-corner"><div class="bototm-left-corner"><div class="bottom-right-corner">
<div class="content"

Just imagine how great it will be when you seperate your presentation from your content!


Re:I liked this guide (1)

Tumbleweed (3706) | more than 6 years ago | (#21679515)

But I couldn't find any info on nested tables.

Why would you need to? They just WORK. *sigh*


stratjakt (596332) | more than 6 years ago | (#21675317)

CSS.. harumph


ByOhTek (1181381) | more than 6 years ago | (#21675357)

IE does just fine with CSS. It may not be everybody elses CSS, but I've gotten CSS to work on both IE and Firefox anway...

IE speaks a completely different CSS language than Firefox, they just happend to sound about 95% alike.


eebra82 (907996) | more than 6 years ago | (#21675515)

IE speaks a completely different CSS language than Firefox, they just happened to sound about 95% alike.
If as much as 5% of your code is viewed differently between the two browsers, you're up for some serious headaches. Whenever I'm writing CSS, I always end up with problems that usually shouldn't exist. And it's not so much that there's a difference between IE and FF in terms of how they interpret the code, but how poorly IE copes with it. When something's not working like you'd expect it to, it usually ends with some ugly workarounds or a largely rewritten portion of the code.


ByOhTek (1181381) | more than 6 years ago | (#21675597)

I've had plenty of cases where both IE and FireFox have rendered my stylesheets properly, and plenty of cases where one has failed for some reason or another.

I'm not saying the 5% isn't going to produce a big difference, but that 5% also isn't an all-encompasing end of the world either.


Anonymous Coward | more than 6 years ago | (#21675719)

Maybe not for tin-pot websites, but back in corporate land, you rarely get away with differences. Corporate image is extremely important to the money boys and girls. Fsck it up, and you'll be shown the door, or lose the business.


Anonymous Coward | more than 6 years ago | (#21676257)

In corporate land you'll be using IE, so you create the pages that work best with that.

Godsend (2, Insightful)

Ikoma Andy (41693) | more than 6 years ago | (#21675625)

I have heard CSS called many things, but never a godsend.

Re:Godsend (1)

niceone (992278) | more than 6 years ago | (#21675973)

I have heard CSS called many things, but never a godsend.

Heretic! Burn him! W3C is the holy trinity of W's - all of their specifications are godsends by definition.

Re:Godsend (1)

Tumbleweed (3706) | more than 6 years ago | (#21679631)

Heretic! Burn him! W3C is the holy trinity of W's - all of their specifications are godsends by definition.

Maybe so, but I suspect the god that sent them was Cthulu.

A good, free reference (5, Informative)

athloi (1075845) | more than 6 years ago | (#21675727)

http://technical-writing.dionysius.com/resources/CSS-2.0.pdf [dionysius.com]

Helped me through many a "what's that called again?" session.

Link updated because both original links were dead.

Re:A good, free reference (even more!) (1)

hardaker (32597) | more than 6 years ago | (#21677627)

That one is my favorite too (though I used to use a cssv1 version [digilife.be] that is very similar and the sources are obviously similar.

I also really like the diagram in this one but don't like how the rest of it is organized. Which is too bad because anyone that owns a domain name of ilovejackdaniels.com deserves more positive praise. [ilovejackdaniels.com]

Am I missing something? (4, Funny)

incripshin (580256) | more than 6 years ago | (#21675813)

I was looking at the O'Reilly page for this book. Under the review [oreilly.com] section, there are two reviews: 3/5 and 5/5. The page claims the average is 5/5. Let's see, (3/5 + 5/5)/2 = ((3+5)/5)/2 = (8/5)/2 = 8/10 = 5/5. Oh, their math is right. Never mind.

Re:Am I missing something? (1, Funny)

Anonymous Coward | more than 6 years ago | (#21676261)

They accidentally put their maths into quirks mode.

wow (5, Funny)

uepuejq (1095319) | more than 6 years ago | (#21675885)

this is especially useful for unconventional web developers who don't actually have access to the internet.

Re:wow (1)

TheRaven64 (641858) | more than 6 years ago | (#21677629)

It's quite rare for me not to have access to the Internet these days, but I do have a PDF version of the HTML and CSS specs downloaded which are occasionally useful.

Re:wow (1)

Dogtanian (588974) | more than 6 years ago | (#21687684)

this is especially useful for unconventional web developers who don't actually have access to the internet.
I agree with you in some ways, but there are still many cases where a well-written book with all the important information in one place beats wading through a bunch of websites.

When I was at university (five or so years back), I was pretty surprised that the library was still so useful. You'd have thought that the Internet would have taken away a lot of its utility, but although the net was great for filling the inevitable gaps, it was also quite patchy, and I wasted a *very* high proportion of my time simply trying to find information amongst countless search results. I spent time (e.g.) looking at pages that turned out not to be useful at all, those that had fragments of useful information, but not enough, because they were written from a different angle and/or for a different reason than what I needed, and.... and also, books are nice because they're generally written as a *coherent* and complementary whole. This is a major failing of simply searching many overlapping websites.

Anyway, books *are* useful. A PDF copy can be even better for certain uses; although they're not as good as HTML in a lot of respects, they're a nice (portable *and* searchable) alternative to the dead tree version of the book. Though if I'm going to read the whole thing, I still prefer paper.

And though I wouldn't read the "CSS Pocket Reference" from beginning to end, I own an earlier edition, and it's certainly worth having, even in these days of near-universal Internet access. You wouldn't expect that from a small reference volume, but it's true.

It might also be nice .... (1)

icepick72 (834363) | more than 6 years ago | (#21675893)

... to have a copy of a list of all ingredients in extistence in my back pocket in case I want to cook something.

Alone At Sea... (4, Interesting)

Nitroadict (1005509) | more than 6 years ago | (#21676255)

Before I go further, I use CSS everyday I design, especially since I'm still learning all of it's annoying idiosyncrasies, mainly because (and I'm not the only one) the CSS language itself is flawed (constraints & variables being some of which CSS lacks). The idea of what CSS created for, style sheets, is great & is a step forward, but the way we have to use style sheets with CSS sometimes makes me wonder what an abortion feels like.

I admit, some days it seems to get *easier* to deal with since I actively remember the times I more or less lost my shit because the stupid code wouldn't render correctly in different browsers, so I also remember (most of the time) what to avoid, but I really don't think the full potential of style sheets will be fufilled with CSS as the way it is. Even with CSS 3 (I'm not touching HTML5; I'm one of those "wacky" people who think we should stick with what we have until it's stable enough to warrant additions; a more eloquent way of putting it has already been said: http://www.molly.com/2007/06/14/defy-the-pedantic-semantic-html5-and-xhtml-11-must-stop-for-now/ [molly.com] ), I just don't see the difficulties of CSS, which warrant most of the CSS books being made, being resolved anytime soon.

I know I'm not the only one who begrudgingly uses CSS (I realize they are other technologies to use instead or to supplement CSS' shortcomings, I'm currently looking into that...), and I know I'm not the only who thinks something new should be made to address what CSS fails to do. I'm not talking about HTML5, nor CSS3, and defintley not FLASH (although, personally, I think if HTML & CSS were to somehow utilize a plug-in for browsers to render shit properly, standards would be able to compete with FLASH, but I'm just rambling there).

While googling out of frustration, I came across this:

PSL (Proteus Style Sheets): http://www.cs.uwm.edu/~multimedia/papers/jucs/jucs.html [uwm.edu]

Why Current Style Sheet Standards Have Failed to Improve Document Engineering: http://www.cs.uwm.edu/~multimedia/WWW8/webEng.html [uwm.edu]

I know every single Pure-CSS zealot is going to moan & groan at me for thinking differently than them, but honestly, PSL seems like a way better idea than simply adding on to an inheritantly broken style sheet language in which books & books need to be made to tell people what hoops to jump through to get it work. I don't know, I guess that sounds stupid to too many people; often I've let that prevent me from expressing my not unreasonable doubts.

Sometimes I feel like some poor bloke who time traveled back to the Titanic but can't prevent anything due to paradox. :\

Re:Alone At Sea... (1)

Chapter80 (926879) | more than 6 years ago | (#21676661)

When I look at CSS specs, I just laugh. In the 90's, Object Orientation was a known technology; how did we end up with such a horrible syntax in CSS? Seems like a simple object orientation with inheritance would have been appropriate, and so effective.

Re:Alone At Sea... (0)

Anonymous Coward | more than 6 years ago | (#21676853)

Please give me some examples of how you would re-do CSS to be "Object Oriented".

Re:Alone At Sea... (1)

Chapter80 (926879) | more than 6 years ago | (#21678333)

Please give me some examples of how you would re-do CSS to be "Object Oriented".
OK, here's a shot at it:

class Comment < CommentBox
@position = :relative
@margin = {.5.em, 0, 1.25.em, 0}
@padding = 0
@background = {#696969, url."//images.slashdot.org/commentbox-bg.png", :repeat-x, :left :top}

class HighlightedComment < Comment
@color = #FF0000
Hey it's Ruby! gee, that wasn't too hard.

My example is intended to show inheritance and object attributes (which is pretty much all CSS is). You don't have to worry so much about methods (although methods in CSS might facilitate some DHTML, at the risk of messing with the separation of view and logic). The current syntax of CSS is an abomination in my humble opinion. The designers threw out everything that was learned in the last 20 years about good programming language syntax, and left us with a mess.

Re:Alone At Sea... (1)

Nitroadict (1005509) | more than 6 years ago | (#21682419)

Ruby is actually one of the languages I've been trying to learn in hopes of eventually being able to take the grunt work out of HTML / CSS via HAML & SASS. Admittedly, I haven't gotten out of the "Learn To Program" book (Chris Pine; Facet of Ruby Series), mainly because of the daily grind, but dammit I wish we could write CSS the way you just did. The fact that you can use Ruby and/or other programming languages (Clever CSS, via python, looked interesting, but is probably a little beyond my novice level...) to alleviate some of CSS' problems gives me some hope, but it would be even more awesome if CSS were to be re-written with all the problems it has now in mind.

If it did, I'd imagine it would probably be a much easier way for non-programmers who have used HTML to be able to jump into the world of programming; at least, I imagine it would've been easier for me. I don't think anyone will be able to argue against CSS' syntax being an abomination, not even apologists or those who are fluent in the gibberish, and if we want the web to go forward, we should be able to eat some humble pie, go back, and re-build CSS or something else in it's stead that takes language syntax seriously.

Re:Alone At Sea... (1)

itsdapead (734413) | more than 6 years ago | (#21682845)

The idea of what CSS created for, style sheets, is great & is a step forward, but the way we have to use style sheets with CSS sometimes makes me wonder what an abortion feels like.

I'm glad I'm not the only one. CSS is OK as a replacement for the FONT tag, but beyond that it is a complete mess that fails to do what it says on the tin - since the HTML inevitably has to be modified to achieve any significant layout change (pick up a CSS cookbook and look at the examples - they're as much about where you put the div/class/id tags in the HTML as writing the CSS). In non-trivial cases all it really does is keep the layout and content in separate files - which is not the same as making them independent. You get the impression that the whole thing was invented in the abstract and cast in stone by a committee before anyone actually tried to use it to lay out a website.

Its too easy to blame the whole thing on Microsoft - the browser differences are a big part of the problem but they're not the whole of it. The MS interpretation of the box model was probably more sensible than the standard...

Re:Alone At Sea... (1)

Nitroadict (1005509) | more than 6 years ago | (#21683235)

Indeed, as of late, I'm finding the usual "not all browsers implement correctly", while a sympathetic & mostly true argument, tiresome and seemingly an excuse for CSS' being so difficult to work with. It wouldn't surprise me if, hypothetically, if IE were banished, and every user upgraded to either Opera, Firefox, Safari and or Swift (Swift is a new webkit browser being made to replace the just awful Safari release for windows, google it...), there would still be massive difficulties with CSS.

Of course, and I apologize for those who do not apply (it's usually the few idiots who can give a certain population a bad name), if you even go against this dogma (I found this especially true on Digg), people begin screaming at you calling you names like "MS Apologist!!#!!" and "you just don't get it".

No I do get it. I get that no matter how much kicking & screaming I do with CSS, it will always be a terribly flawed shell of a good idea gone bad, brought to us via committee who must've figured, "hey, it works in theory, that's good enough for us."

It also seems hypocritical of the standards advocates to bring use even more standards when the current ones (mainly where CSS is concerned) need re-working because CSS needs re-building. Wouldn't be more of a win for standards to focus on fixing with what we have? I'd think a lot of people would thank their lucky stars if CSS was re-built from scratch or something else was brought forward to replace it (not as an additional standard, but I suppose letting CSS stick around would help the transition, but then a lot of people would complain about lag time between switching from CSS to something CSS already does but it better than CSS in all ways).

Then there's the possibility that if this were to ever occur, the replacing of CSS with a re-built version or different style sheet language, that many people would groan about how it took them forever to learn how CSS works, and would ask "why bother?". That would be like everyone learning to like poison and getting addicted to how it works, despite a remedy coming along that would initally be painful to bear, but would be much better in long run for standards, usability, & stability.

Alas, I digress. While the situation seems hopeless, there are always possibilities I suppose.

Pocket Reference (0)

Anonymous Coward | more than 6 years ago | (#21677605)

I already have a CSS Pocket Reference. It's called an iPhone.

javascript? (0)

Anonymous Coward | more than 6 years ago | (#21677991)

would be cool to have this for javascript too

Layout + Content are not separate (0)

Anonymous Coward | more than 6 years ago | (#21678047)

Cascading Style Sheets (CSS) has proved a godsend, because it allows all of the styling of a Web site to be organized in CSS files separate from the site's semantic content

In my experience, CSS doesn't do a great job of keeping Layout and Content separate. For example, look at the tutorials for putting rounded borders around a box, most of them involve adding 3-8 divs around your box.

Re:Layout + Content are not separate (1)

elwin_windleaf (643442) | more than 6 years ago | (#21703572)

True, rounded anything is hard to achieve with the current CSS support we have in browsers. However, a lot of that is addressed with CSS3. Check out http://virtuelvis.com/download/218/border-radius.html [virtuelvis.com] to see a preview of some of the border-radius properties - most of which don't work in many browsers.

For now, I try to add any non-semantic HTML with Javascript, at least to keep it out of the way. It's a pretty ugly way to do things, but it's what we have to work with currently.

Where's the beef? (1)

greywire (78262) | more than 6 years ago | (#21678097)

I got this book right when it came out, to replace the well worn previous edition.

The back cover claims there is "a chart displaying detailed information about CSS support for every style element and its cross-browser compatibility."

I saw no chart in the book.

Maybe they tried to do the chart without tables and gave up..

How does this differ from the 2nd edition? (1)

m.e.l.l.e.n.t.i.n.e (305369) | more than 6 years ago | (#21678565)

The 2nd edition of this book already covered CSS2 and CSS2.1. It says so right on the cover [oreilly.com]. How about a pocket reference that covers CSS3 -- and a widely-used browser that supports it well.

Oops, spotted a typo (1)

Dorceon (928997) | more than 6 years ago | (#21679087)

...because it allows all of the styling of a Web site to be organized in CSS files separate from the site's semantic content, except for the number of rows in a TEXTAREA, which must still be set using the required ROWS attribute.
There, fixed that for you.

Re:Oops, spotted a typo (1)

elwin_windleaf (643442) | more than 6 years ago | (#21703396)

I had the same thought about the 'colspan' attribute, but after some quick Google'd research, I discovered why they made those particular attributes required.

Since CSS is supposed to be strictly presentational, those kinds of details need to be designated in the HTML. Colspan has to deal with the structure of a table, and the number of rows has to deal with the structure of the textarea.

Whether that's appropriate or not for textareas is beyond me, but the colspan thing made sense. Just wanted to shed some light on the thinking behind leaving those attributes in.

A Pocket Reference!!!!!! (3, Funny)

FlyingGuy (989135) | more than 6 years ago | (#21679431)

Is this a joke or what!? Does this pocket reference explain this kind of gibberish?

Someone please translate this into something that resembles logic, please?

ul.nav,.nav, ul{ /*Remove all spacings from the list items*/
        margin: 0;
        padding: 0;
        cursor: default;
        list-style-type: none;
        border: 0px solid #369;
                display: table ;

        display: table-cell;
        position: relative;
        padding: 2px 6px;

ul.nav li>ul{ /*Make the sub list items invisible*/
        display: none;
        position: absolute;
        max-width: 40ex;
        margin-left: -6px;
        margin-top: 2px;


ul.nav li:hover>ul{ /*When hovered, make them appear*/
        display : block;
} .nav ul li a{ /*Make the hyperlinks as a block element, sort of a hover effect*/
        display: block;
        padding: 2px 10px;

} /*** Menu colors (customizable) ***/

ul.nav, .nav, li, a{
        background-color: white;
        color: blue;

ul.nav li:hover, .nav ul li a:hover{
        background-color: yellow;
        color: blue;

ul.nav li:active, .nav ul li a:active{
        background-color: black;
        color: white;
} .nav a{
        text-decoration: none;

CSS is a miserable and irrational set of style tags that when used to do things like turn un-ordered lists in menu's becomes pretty much inscrutable and damn near unusable. Nested DIVS are a poor substitute for nested tables. If you want to say I am wrong, then show me how create that will hold data in perfect rows and columns, or how you can make two divs equally occupy 50% of the outer div's area.

Re:A Pocket Reference!!!!!! (3, Informative)

Selanit (192811) | more than 6 years ago | (#21681407)

It makes a menu in which sub-items are revealed when you move your mouse over them. And it's being done badly, for the following reasons:

1) It relies on all kinds of things which IE either doesn't support or supports badly, including: the child selector (that's the > bits), using the :hover pseudo-class on elements other than anchors, display: table, and display: table-cell. There's no way this sucker is ever going to work in IE. Not IE 7, and definitely not IE 6. Just look up IE's support for the various properties used here on WebDevout.net's CSS compatibility list [webdevout.net].

2) The code has needless redundancy built into it. Example: in that first rule set, they're using three selectors:

ul.nav <-- an unordered list of the "nav" class
.nav <-- any element at all of the "nav" class
ul <-- any unordered list
Stacking selectors by separating them using a comma can be useful, but this has been done badly. The first selector alone should have been sufficient for their purposes, or the second one alone. And the third one is simply atrocious, because it makes the rule apply to EVERY unordered list in the document unless it is explicitly overridden. If there is EVER an unordered list in the document which is NOT part of the menu, it's going to be totally fubared by the menu formatting instructions. Selectors which apply to every element in the entire document are dangerous that way unless you use them really carefully or make only tiny modifications. For example, I like changing the cursor over label elements so that people will know they do something if you click them, like this:

/* Make labels for form elements have a pointer. */
label { cursor: pointer; }
The modification is very simple, does not change the basic appearance or functionality of the element, and provides a useful bit of feedback to the user.

3) Inconsistent use of whitespace. Note that sometimes a rule will start immediately after another with no whitespace, like this:

ul.nav li:active, .nav ul li a:active{
        background-color: black;
        color: white;
} .nav a{ <--------------- here
        text-decoration: none;
The rule set for ".nav a" starts on the same line as the previous rule set finishes, which is ugly as sin. For improved comprehensibility, it should have at least two carriage returns after the previous rule set. And the author didn't even do it consistently.

I'll happily agree that this is an ugly bit of code. And no, the CSS pocket reference will not be especially helpful in untangling this snarl; it's a reference, for looking up properties and selectors. It shows you what individual bits do, but does not explain how the many bits may be combined. References are primarily useful when you're building your own code, and rather less so when interpreting somebody else's.

That said, I have to take issue with your conclusions.

1) "CSS is a miserable and irrational set of style tags"

First off, CSS doesn't use tags. It uses selectors to refer to tags. Second, CSS itself is not irrational. It is abstract, and takes a while to wrap your head around. It has some inadequacies and shortcomings, such as making multiple columns have an equal height or centering content vertically as well as horizontally, both of which are a serious pain in the ass. But you're throwing out the baby with the bathwater. CSS also gives you quite a lot of fairly fine-grained control over your pages. Moving the presentational stuff out of your HTML makes it considerably easier to read (assuming that you don't keep throwing extraneous DIVs into it instead of learning the inheritance rules and the box model), and has truly amazing benefits for the blind. A page whose layout and styling has been done via CSS is almost always a lot more accessible to screen reader users.

2) "that when used to do things like turn un-ordered lists in menu's becomes pretty much inscrutable and damn near unusable."

Perl is hard to use too. In particular, its regex stuff makes my head hurt. It is, in fact, pretty much inscrutable and damn near unusable. But it's also powerful, and extremely useful once you've taken the time to learn it.

3) "Nested DIVS are a poor substitute for nested tables."

You're right. Using nested DIVs really is a poor substitute for nested tables. But if you're USING nested DIVs at all, it's a strong indicator that you haven't really got the hang of CSS yet. You're trying to do the same thing you've always done, and it's not working well, because that's not how CSS is designed to be used.

4) "show me how create that will hold data in perfect rows and columns" (I think there's a word missing in there someplace)

If it's data, then go ahead and use an HTML table. That's what tables are FOR, silly.

5) "or how you can make two divs equally occupy 50% of the outer div's area."

Ahem. [utexas.edu]

Of course, the two methods I demonstrate there are imperfect. If one column is taller than the other, the second will not expand to match. As I indicated earlier, having two columns of an equal height is a limitation of CSS which has driven many people to distraction. There are all kinds of kludgy workarounds. Here's a survey of the various types of workarounds available. [ejeliot.com]

Basically, CSS isn't as bad as you're making it out to be. It definitely could be better, and has some unpleasant limitations, mostly having to do with layout. But half your problem is that you don't know enough about it yet. It's not simple, and it requires thinking about your designs in a different way than you're accustomed to. But it's worth learning.

No interest in a reference that isn't searchable. (1)

syousef (465911) | more than 6 years ago | (#21679551)

A programming book has to be the kind you can sit down and read cover to cover (or chapter by chapter), that teaches something new. I simply don't have time to spend "getting to know" a particular book or painstakingly tracking down reference information.

People STILL unclear of the concept. (1)

aqk (844307) | more than 6 years ago | (#21680035)

Say, there- I'm looking for ease of use...

Is this modern version of the legendary IBM 'green card' [planetmvs.com] written as text or is it in trendy hypertext? [wikipedia.org]
The latter would be preferable, especially if I'm on a PC and coding my HTML and CSS, etc... Of course, if it's hypertext, I'll hafta take it out of my shirt pocket to run the mouse across it, otherwise I might get unsightly mouse stains on my shirt.

But, all-in-all, sounds like a very useful product!

I bought this book a while back (1)

iffer (559606) | more than 6 years ago | (#21681915)

and I can say that I have never used it. Not once. Its just easier and much much quicker to type "css reference" into my search box and click on the first result.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account