Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
GUI Books Media Programming Software Book Reviews IT Technology

The CSS Anthology 169

Posted by timothy from the good-and-useful dept.
Bruce Lawson writes "I've read a lot of CSS books, but this one is the one I wished that I'd read when I was learning, and I suspect that other slashdotters may concur. It is firmly pitched at the coder rather than the designer, takes you from CSS virgin to upper intermediate level, with good attention to the process of (re)designing with CSS, legal issues such as Accessibility (section 508), and assumes that you're not scared of mark-up." Lawson offers this disclosure: "I should immediately disclose that I've worked for two different companies that have published the author, Rachel Andrew, but I have no connection with the publishers, or this book." Read on for the rest of his review.
The CSS Anthology: 101 Essential Tips, Tricks & Hacks
author Rachel Andrew
pages 380
publisher SitePoint
rating 8
reviewer Bruce Lawson
ISBN 0957921888
summary Structured Q&A guide for CSS beginners

Author's credentials

Andrew is a long-term member of the Web Standards Project (WaSP) and programmer, technical project manager, technical team leader/senior developer and webmaster, according to her own bio.

Who's the book for?

The book's subtitle is somewhat misleading. There probably are 101 tips'n'tricks (I didn't count) but it's not the random miscellany that it implies. The information is structured so that a n00b could become proficient by reading the book from start to finish (I tested this out on a colleague). The tips'n'tricks structure does allow you to find what you're looking for in a hurry. The table of contents is easily scanned, and there is an excellent index.

The book doesn't offer advice on how to sex up the beauty of your site. That's fine for me; my current work involves replicating someone else's designs using xhtml and CSS, and as a coder I'm pathologically unable to design the type of showcases that you see at the CSS Zen Garden. A graphic designer might therefore find this book hard work; it jumps straight into a discussion of syntax, and there's occasional geek-directed statements (CSS supports multi-line C-style comments). Similarly, if you're completely new to html, this book probably isn't for you; there's lots of references to pre-CSS ways of working which could potentially be mystifying. Unusually for CSS books, there's a refreshing lack of polemic telling you why you should use style-sheets. If I read another history of the browser wars in a technical book, I shall scream.

So the book's constituency would seem to be those who know how to present information via html, and wish to take advantage of the smaller filesizes, greater flexibility and logical separation of the presentation layer from the mark-up that the (x)html/ CSS combination offers. The logical purity is my personal reason for moving to Web Standards; the trauma of writing text processing applications with VAX Fortran in the late '80s left me with the propensity to weep when I see html as sorely abused I mangled dear old Fortran.

Are you sitting comfortably? Then I'll begin.

Anthology kicks off in the conventional way for CSS books - controlling fonts and colours, styling hyperlinks, headings and the like. Each chunk is structured as a problem (How do I remove the indented left margin from a list?), a solution and sample code, and generally a discussion of related applications of the code, compatibility issues, accessibility notes etc. This is a pretty compact method of explication, and the basics of styling, syntax, pseudo-class order and the like are romped through in 40 pages, but not glossed over. The key to this is that Anthology assumes you know what you want to do, and shows you how to do it.

Chapter 4 (Navigation) is where the real meat begins - making navigation menus that are solely html unordered lists (because a menu is logically a list of links) and styling with CSS, adding rollover effects, styling navigation as buttons, changing the styling to a horizontal navbar, or even Amazon-style tabs without changing the mark-up. I suspect that, although these are techniques that can be found in most CSS books, the brevity and simplicity of the explanation will be revelatory to many. Chapter 5 (Tabular Data) may come as a surprise to those who mistakenly believe that web standards disallows the use of html tables, as it shows how to style tabular data - the examples are a spreadsheet and a calendar. Chapter 6 repeats the trick with that most mundane aspect of web development, the form.

Chapter 7 (Browser and Device Support) is about real-world CSS development. Unlike most books which instruct you to test in loads of browsers and leave it at that, this chapter lists all the main permutations of OS and browser (including tips on installing multiple versions of IE/ Win), and begins discussion of the tried and tested hacks to hide styles from Netscape 4, IE etc. All of this information is available on the web -- but for a newbie who isn't yet aware that it's possible to hide styles from certain browsers, it's a great way to introduce them to the murky practices of real-world CSS development. What's also refreshing in a computer book for n00bs is a discussion of how to seek help on lists and forums, with a guide to etiquette.

Chapter 8 (CSS Positioning and Layout) is where the stuff that stumps many a table-based designer begins. Along with fonts and colours etc, CSS can lay out the stuff on your page. I'm unsure about the success of this chapter; the Q&A structure is great if you're looking to build one of the sites that are explained (and the list is pretty comprehensive), but I came to the chapter hoping to cure a couple of bugs I'd found in a project I'd previously semi-successfully laid out with absolute positioning (A.P.).

Generally, I layout using floats as I also write the html, so it's easy to ensure that the markup spits out <div>s (sections) in the left-to-right, top-to-bottom order that I want to lay them out in. Suddenly, I had two projects that required A.P. for the first time, as it was not cost-effective to change the way that the client's CMS spat out the markup, so AP was required to position sections on the page regardless of where they appeared in the markup.

Anthology served me fine until I tested the page in IE and the layout was off. Nothing in the book gave me any pointers, and in the end I gave up Googling and just used a hack which exploits an IE parser bug to serve different co-ordinates to IE, after finding the hack co-ordinates through trial and error:

#APthing {position:absolute; top:34px; left: 758px; width:108px; height:88px;}
* html #APthing {position:absolute; top:19px; left: 785px;} /*for IE */

OK, so there may be a simple mistake I'm making -- but then, as far as absolute positioning goes, I'm the kind of newbie at whom this book is aimed, and I imagine that others will make the same mistake that I did. If the book had explained where I was going wrong, or given me the above hack, I'd've spent less time with Google and more time with Guinness.

Chapter 9 (Experimentation, Browser Specific CSS and Future Techniques) is successful, except for one small gripe. I'm glad that the author, although a member of the Web Standards Project, isn't an uber-purist. (I'm of the opinion that a little invalid code, if it's the only way to get the job done, isn't a hanging offense). So she shows how to implement IE-only proprietary CSS that can make colourful scrollbars, should you wish to do this. There's also a Mozilla-only CSS trick to allow curved edges to CSS boxes, which I implemented on my homepage that very evening.

However (here's the gripe), the most useful technique shown is one which allows fully-CSS flyout menus that don't rely on JavaScript. The author notes that it won't work for most people, as IE incorrectly restricts the hover pseudo-class to <a> tags only, while the CSS requires hovering over <li> elements.

Well, Yes and No. There's a well-documented and elegant hack which allows a proprietary Microsoft behaviour to be attached to the CSS that attaches a small JScript that corrects the IE bug, and thus allows this extremely useful CSS-only flyout menu to work in IE. I've used the technique myself when required to mimic the look and feel of a client's site while making it DDA/ADA accessible, and it works perfectly. To me, the omission of the IE hack from Anthology is an unfortunate oversight.

Summary

There's a couple of flaws in the book, though I suspect that in order to explain them, I've over-emphasised them. All in all, it's a solid, professional no-B.S. way for someone with a code-oriented mind to get them up to speed, satisfactorily and quickly; a motivated reader could be churning out standards-compliant, bandwidth-friendly sites after a few hour's experimentation. Ordering the book from the publisher's website was a good experience and, unusually, they have a money-back guarantee. As I said, I wish that I'd had access to Anthology when I was learning.

You can purchase The CSS Anthology: 101 Essential Tips, Tricks & Hacks from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

The CSS Anthology More

The CSS Anthology

Comments Filter:

  • Ok, let's take up a collection (Score:5, Funny)

    by wowbagger ( 69688 ) on Friday January 28, 2005 @06:47PM (#11509196) Homepage Journal
    Ok, let's take up a collection for Rob et. al. to get this book....
  • layout 4 life.

  • Learn online for free (Score:2, Informative)

    by Anonymous Coward
    The added bonus of the online tutorials is that you can see the code in action and edit it yourself as you go. Not sure who would plonk down good money when so many thorough tutorials are online.
    • feel free to point us to a few really, really in depth tutorials online, as I've yet to find one.
    • Not sure who would plonk down good money when so many thorough tutorials are online.

      I would. I keep going through monitors like crazy. IT says I'm not supposed to underline things with ballpoint on the screens themselves. Anyone have some soft #1 pencils they can send me?
    • Not sure who would plonk down good money when so many thorough tutorials are online.

      When you need to get things done FAST, and learn while not in front of your computer monitor, or maybe even have a quickreference handy, you need to buy books. Hey, what if suddenly your internet connection drops?

      I'm a customer of Sitepoint (the company that published the book), and I purchased the "build your own... website using PHP and MySQL". I keep it always handy on my job desk.

      Also, having a manual handy (either printed or downloaded, such as the PHP reference) saves you lots of trouble. I've talked with many people who just use the online PHP manual, and they keep asking me stupid questions they could have answered themselves had they downloaded the reference in CHM format.

      Never forget that time is money, and learning online "for free" might cost you lots of hours that you could have well spent designing a website and getting paid.

      • Re:Free? What about the time factor? (Score:1, Informative)

        by Anonymous Coward
        Books have their uses, but some of your arguments aren't really good:

        When you need to get things done FAST, and learn while not in front of your computer monitor...

        Um, this is CSS we're talking about, there's no use for CSS when you're away from your computer. The only time a book is better is in a meeting, when someone asks if such-and-such is possible with CSS...

        Hey, what if suddenly your internet connection drops?

        As already mentioned, download useful websites to your local computer.

        Never forget
      • How do you make the inference that all online learning materials are "lame" or "time wasting"???

        How do you make the inference that books are faster? Can you search a book with Ctrl+F? Care to take a bet that my Ctrl+F is faster than your index?

  • I like it.... (Score:5, Interesting)

    by ZiZ ( 564727 ) * on Friday January 28, 2005 @06:54PM (#11509265) Homepage
    It is one of the few CSS resources I've found that assume that you know what you're doing except where CSS is concerned, and doesn't try to teach you inane things like how to make a link to another document. I've got a copy that's rapidly becoming worn and well-used.

  • Good review, but... (Score:5, Insightful)

    by fiannaFailMan ( 702447 ) on Friday January 28, 2005 @06:55PM (#11509273) Journal
    as a coder I'm pathologically unable to design the type of showcases that you see at the CSS Zen Garden
    I wish people would get out of this mindset that you must be either a coder or an artist and never the twain shall meet. I work quite comfortably on both sides of that fence and I have met plenty of renaissance people in this industry who are just as comfortable with code as they are with a graphic design tool like Photoshop. It's that kind of thinking that leads to the most creative solutions IMHO. Back in the days of Leonardo DaVinci there was no Berlin Wall seperating technical and creative people, it's a relatively recent addition to our culture and a bit of an unhelpful one.

    • Re:Good review, but... (Score:4, Insightful)

      by fuw ( 823023 ) on Friday January 28, 2005 @07:25PM (#11509479) Homepage
      I don't know about that. Myself being more skilled in the programming area, I find I have a very difficult time creating a site that I would consider "professional looking". I mean, I love CSS and have jumped head first into creating CSS-based layouts several years ago. My problem however, is not having the "design eye" that gives folks the ability to create such beautiful designs that you often see in CSS Zen Garden.

      Sure, I *want* to create a well designed site, but until I get that knowledge (school) it just ain't going to happen (not for me, anyway).

      > I work quite comfortably on both sides of that fence

      It's easy to say that about yourself, sure I even would try to claim that one. But when I look at sites I have created and compare them to sites done by a *real* graphic designer (web designer), there *is* a huge difference.

      I'd consider myself a professional programmer and an amatuer designer at best.
      • I don't know about that. Myself being more skilled in the programming area.....
        I probably should have explained myself a bit better. The point of my original post was that there are people out there who make good designers and good coders at the same time, regardless of what you personally as an individual are good or bad at. It is possible.
    • I have met plenty of renaissance people in this industry who are just as comfortable with code as they are with a graphic design tool like Photoshop. It's that kind of thinking that leads to the most creative solutions IMHO.

      And, most of the time, user interface issues should not be solved with the most CREATIVE solutions, but rather with the most PEDESTRIAN solutions. Users shouldn't find any surprises in the interface of your site or application -- it should look and feel just like all the other sites a

      • user interface issues should not be solved with the most CREATIVE solutions, but rather with the most PEDESTRIAN solutions. Users shouldn't find any surprises in the interface of your site or application -- it should look and feel just like all the other sites and applications they're already familiar with.

        I'm confused. How on earth do you get "bad interface design" from "creative solutions? I never even mentioned interfaces, I was talking in general terms about design. In any case, a rennaissance ma

      • ...user interface issues should not be solved with the most CREATIVE solutions, but rather with the most PEDESTRIAN solutions.

        Not really. The majority of UIs out there are plain awful, so the most pedestrian solution is usually a very bad one. Because each application presents different information, different types of information, different levels of detail, differently-sized data sets and different kinds of end users, each UI should be creatively designed to accomodate all of this variability. If you are

    • I wish people would get out of this mindset that you must be either a coder or an artist and never the twain shall meet.
      [...]
      Back in the days of Leonardo DaVinci there was no Berlin Wall seperating technical and creative people...

      I accept "coder" and "technical" as synonyms for the purposes of this discussion, but not "artist" and "creative."

  • CSS is annoying (Score:3, Interesting)

    by Capt'n Hector ( 650760 ) on Friday January 28, 2005 @07:03PM (#11509329)
    Kinda OT, but I wanted to get this off my chest: Is there (shouldn't there be) a way to replace this:

    a.blue {
    color: blue;
    }

    span.blue {
    color: blue;
    }

    div#back {
    color: blue;
    }

    With...

    color: blue {a.blue, span.blue, div#back}

    It fits more with the philosophy that colors and other styles should be in once place and one place only. CSS follows that OK right now, that is, we can put all those things in the same document, but wouldn't it be great if the document itself adhered to the same principle?

    That problem seems to me one of the biggest in CSS. It makes things cluttered, take up 10 times as much space as they otherwise might, and makes for an illogical thought process. The designer doesn't think: I'll go through each element in the page and make them blue, but rather: I want this this and this to be blue. Anyway, just a thought.

    • Re:CSS is annoying (Score:3, Informative)

      by Anonymous Coward
      Yes, it's called grouping. You have your syntax backwards, though. It should be like this:

      a.blue, span.blue, div#back {color: blue;}

      Of course, you don't really need a.blue and span.blue. A simple .blue would work.

    • Re:CSS is annoying (Score:5, Informative)

      by Vaevictis666 ( 680137 ) on Friday January 28, 2005 @07:12PM (#11509374)
      You've got two options:

      .blue {
      color: blue;
      }

      and have it apply to anything with a class="blue", or

      a.blue, span.blue, div#back {
      color: blue;
      }

      to explicitly declare them. The commas being key in this one.
    • How about

      a.blue, span.blue, div#back { color: blue; }

      which works just fine? I'm fairly new to CSS, but it seems to me it's missing CPP-like definitions to allow propagating colors and such into more complicated structures.

      • propagating colors

        What does that mean? Does the "Cascading" part of Cascading Style Sheets not cover that?

        (Seriously, I'm not sure what you're asking)
        • I'd like to be able to do something like
          #define BGCOLOR red;
          somewhere in a CSS and then be able to use
          color: BGCOLOR;
          at various places in the CSS file(s) rather than gathering everything together in one place like the parent example. Sometimes it can be a pain to find everything and if you have styles for an element other than "color:" it doesn't save space to write them all together.
          • I think that either you don't understand what CSS is about and how it works or maybe you are just making it harder than it is by thinking of things in a programming mindset. You're essentially asking for constants in a CSS file, am I right? Where you are trying to set the color to red in your hypothetical #define statement... you simply do that at the color: statement (well, technically it would be background:).

            The intention of CSS is to seperate document presentation from document structure. While doing t
    • Why not just do:
      a.blue, span.blue, div#back { color: blue; }
      That does the same thing and takes up less space.

    • a.blue, span.blue, div#back { color: blue; }

    • wouldn't
      a.blue, span.blue, div#back {color: blue}
      do the trick? I started learning CSS 3 days ago... wish I could afford that book. I've found westciv's site a good place for beginners. http://www.westciv.com/style_master/house/tutorial s/index.html/ [westciv.com]

    • Re:CSS is annoying (Score:5, Insightful)

      by justMichael ( 606509 ) on Friday January 28, 2005 @07:17PM (#11509418) Homepage
      The problem with using a color name in your class definitions is about 2 minutes before the site is complete they decide all the blue stuff should be green and now you have blue that's really green.

      Name them for what they are, not what they look like. Somewhere down the road you'll be glad you did. ;)

      • Re:CSS is annoying (Score:4, Funny)

        by Scarblac ( 122480 ) <slashdot@gerlich.nl> on Friday January 28, 2005 @07:35PM (#11509549) Homepage

        On a similar note, a friend of mine worked at a large telco, where they were told that they had to #define all their constants (in C)... so they (others, not my friend) had code that said #define THIRTEEN 13. The number had to change later, of course...

        The more things change, the more things stay the same :-)

        • Yeah, but #define TRUE 0; #define FALSE 1; makes C far more readable when you have that awkward situation.
          • #define TRUE 0; #define FALSE 1;

            You do realize that the punishment for inverting the truth values is dismemberment, right? Check out the following fragment:

            if (TRUE) {
            /* This happens! */
            /* uhh, except for broken values of TRUE */
            } else {
            /* This does not happen! */
            /* ...see caveat above */
            }

            Inverting those values instantly puts most C programmers on the wrong foot and makes your code fundamentally incompatible with any other code out there. Especially when that other code has the good sense of defini

      • Name them for what they are, not what they look like.

        This is good advice sometimes, but not all the time. I've designed lots of tables where the creative department says, "Use the gray box there," or "Use the red table there." Since I was writing a lot of reports, was I less wise to choose to name the class, "grayBox" and have all the reports use it rather than name each one of 14 reports by its proper name? As it turned out, no, it wasn't.

        So I think the answer here is to use your best judgement. Som
    • What's wrong with using the following?:
      a.blue, span.blue, div#back {
      color: blue;
      }
      That fits more with the approach of applying formatting to elements anyway. You could then follow that with further refinements like this:
      a.blue {
      font-weight: bold;
      }
      to emphasise links without effecting "span.blue" and "div#back".
    • a.blue, span.blue, div#back {
      color: blue;
      }
    • According to this book [oreilly.com] you can already do that, albeit in slightly different form. Try this:

      a.blue, span.blue, div#back {color: blue;}

      It's on page 3.

    • Re:CSS is annoying (Score:3, Interesting)

      by teneighty ( 671401 )

      I disagree.

      What CSS *really* needs is variables. For example:

      $border_color: #ccc;

      div.foo
      {
      border: 1px solid $border_color;
      }

      div.bar
      {
      border: 2px solid $border_color;
      }

      Having variables like this would cut down on a lot of the maintenance headaches that CSS can cause.

      • *ahem* NO.

        If you want variables, use a language designed to work with variables to dynamically generate CSS. You have plenty of choices: PHP, ASP, Perl, Parrot, etc. ad nauseum.

        CSS *should* be just a formatting language as formatting is what it does, and all of what it does. It's sad that we couldn't just have one end-all formatting language (HTML could have been better..) and that we had to extend it with other languages to make it more flexible, but now we've got something that works. Dynamic langu
        • If you want variables, use a language designed to work with variables to dynamically generate CSS. You have plenty of choices: PHP, ASP, Perl, Parrot, etc. ad nauseum.

          Why introduce a whole new language into the mix if all you want to do is set some constants that can be used in your CSS.

          Things like

          darkcolor = black;
          lightcolor = green;

          so you can do

          .message { background-color: darkcolor; }
          .text { color: lightcolor; }

          obviously that is trivial, but there are a number of occasions I have come across

          • I DID like FONT. In fact, to this day, most pages I code are 100% HTML4 with CSS positioning because I like FONT so much. What I really hated was TABLE and how you couldn't just specify where you wanted the cells, you'd have to nest them to get complex borders, and all of the above costed valuable bandwidth. CSS got rid of that problem.

            I, as a former web designer, believe that abstraction is a good policy, but only where it needs to be a policy. If I know I have a page that I want the colors to change
      • What CSS *really* needs is variables

        You can put PHP into your CSS and have Apache send all CSS files through the PHP parser. Put this in an .htaccess file:

        <files somefile.css>
        AddType application/x-httpd-php .css
        </files>

        And your CSS like this:

        <? $border_color = #ccc; ?>
        div.foo { border: 1px solid <?= $border_color ?>; }
        div.bar { border: 2px solid <?= $border_color ?>; }

        But then it ends up not really being CSS then, dunnit?

      • Comment removed based on user account deletion

    • yes there is a way, just backwards:CSS is annoying (Score:1, Interesting)

      by Anonymous Coward
      a.blue, span.blue, div#back {color:blue;}

      you can assign a set of attributes to multiple IDs and classes.

      also remember that the "cluttered look" and extra space is not really such a bad thing. as long as the style sheet is external, "readability" and ease of use and editing is more important.

      many people can make CSS do cool stuff, but few are using it properly - too many IDs, setting IDs when a class would suffice, using inline styles repeatedly, hacks and whacks with margins and negative padding to
    • You can make a list of selectors use the same style, e.g.:
      h1, a, hr {
      color:blue
      }
      I'm not sure what your example means, though. Do you have a class or div called blue? That seems like a misleading choice of variable names. Sort of like creating a typedef of float called Int.
    • With...

      color: blue {a.blue, span.blue, div#back}

      You got it backwards.

      a.blue,span.blue,div#back { color:blue }

      Also, you can specify classes more than once in a stylesheet. I use this to separate my stylesheets in two: Operational (margins, positioning width, etc), and Presentational (color, border styles).

      For example:

      STYLESHEET A

      #whatever, #somethingelse { border:1px solid; width:35%; }

      STYLESHEET B

      #whatever { border-color:#f00;border-style:ridge; }

      #somethingelse { border-color:#0f0;border-st
    • As folks have pointed out, you can set a class for blue text or you can use the comma-separated list to apply the color.

      What people haven't mentioned (I didn't see anyway) is the fact that you can apply multiple classes to a single element. So you can have your "blue" class for blue colored text (although that is a very bad class name...think about if you change the color to green). So you can do... .info{
      color:blue;
      } .att{
      font-weight:bold;
      }
      a{
      text-decoration:none;
      }
      div#back{
      border:1px so
    • Is it so hard to say
      .blue, #back {color:blue}
      Seems pretty straightforward to me.
    • Read up on selectors (short guide, quick read) [htmlhelp.com]. What you're doing could be rewritten as "a.blue, span.blue, div#back { color: blue; }" as one commenter said, but more importantly, you should be naming things semantically, as another commenter hinted at. Which is to say, "blue" is a terrible class name, while "important" or "author" or "definition" or whatever are good ones, because they mean something. Your stylesheets will be a lot easier to understand if they are filled with gems like ".definition { colo
      • Which is to say, "blue" is a terrible class name, while "important" or "author" or "definition" or whatever are good ones,

        I don't buy it. In my last job, I heard a lot of, "Use the gray box there" (as opposed to the red, green, or gold boxes which were used elsewhere). The box that surrounded the area was never indicatedt o be "important," or regarding an "author" or "defintion." They wanted it to be gray.

        So what's wrong with

        in this case? I caught a lot of the, "Always use semantic class names or t

        • I don't buy it. In my last job, I heard a lot of, "Use the gray box there" (as opposed to the red, green, or gold boxes which were used elsewhere). The box that surrounded the area was never indicatedt o be "important," or regarding an "author" or "defintion." They wanted it to be gray.

          It helps if the semantic approach is used from the beginning. If you're in a maintenance position where site components are already defined by their color rather than their meaning, then there's not much you can do about it

          • It helps if the semantic approach is used from the beginning.

            Exactly my point. I think that the decision to use the semantic approach from the beginning is a *religious* decision, not a *technical* decision.

            is gold new stuff? Does red indicate breaking news?

            Those types of questions didn't apply in this case. In some cases, the red looked better than the gold. It's just the color of the box and doesn't necessarily have to imply anything else than what just happens to look good with the other colors

            • I think that the decision to use the semantic approach from the beginning is a *religious* decision, not a *technical* decision.

              Perhaps ... but I've been in the position of having to re-approach old markup numerous times, and it's pretty much always been a lifesaver to have consistent, meaningful style rules. Actually, one of the best bits of advice I've yet seen on CSS is to take it one step further, and have separate stylesheets that control font, color, and layout. I've found this to be significantly

              • Okay, but what about the rest? Font, line spacing, border style, margins, padding? Surely these weren't also decided on an ad-hoc basis? If they were, I don't envy you the maintenance of this site in the future.

                I think you're taking it far too seriously. It seems that those who advocate the religion of not naming anything according to how it looks take on faith that every bit of every class will change nine million times every single week, so everything must be named abstractly to the 9 millionth degree.
    • I use
      .red {
      color: red;
      }
      Then, I can define my other classes, and when it comes to the markup
      <span class="otherclass otherclass red">blahblah</span>
      works just fine

  • CSS? (Score:3, Funny)

    by had3l ( 814482 ) on Friday January 28, 2005 @07:11PM (#11509367)
    Since when you need a book to play Counter Strike: Source?

  • CSS W3C Standard (Score:3, Informative)

    by st3v ( 805783 ) on Friday January 28, 2005 @07:13PM (#11509380)
    Actually for the experienced person I would recommend learning from the actual "Standard" of CSS at W3C.

    CSS 2.1 Specification [w3.org]

    If you want to see the upcoming CSS 3 standard, or learn more about CSS, you can go here:

    http://www.w3.org/Style/CSS/ [w3.org]

  • CSS virgin (Score:5, Funny)

    by Anonymous Coward on Friday January 28, 2005 @07:13PM (#11509383)

    CSS virgin

    Would that be someone who:

    1. doesn't understand CSS at all?
    2. reads/understands CSS, but can't write it?
    3. is proficient in reading and writing CSS, but is a virgin (i.e. 70 % of Slashdotters)?

  • CSS books? (Score:3, Funny)

    by Anonymous Coward on Friday January 28, 2005 @07:17PM (#11509419)
    First CSS encrypted DVDs, now CSS encrypted books? What's this world coming to? Looks like I won't be able to co^h^hread my books now. ;)

  • Ooooh, that scary markup (Score:4, Funny)

    by Jesus 2.0 ( 701858 ) on Friday January 28, 2005 @07:33PM (#11509529)
    It is "firmly pitched at the coder", but it has to explicitly state that it "assumes that you're not scared of mark-up"?

    If you're "scared" of mere markup, I would hate to see your actual coding.
    • If you're "scared" of mere markup, I would hate to see your actual coding.

      Calling CSS "markup" is disingenuous at best. I think the reason why said "markup" is frightening to programmers is because it is necessarily replete with obscure logic and pretends as hard as it fucking can that it doesn't have any logic within it and there is NO CLEAN WAY TO DEBUG IT.

      CSS is as friendly to programmers as a circular saw is to a man's penis.

  • Why I hate CSS (Score:3, Interesting)

    by david.given ( 6740 ) <dg@cowlark.com> on Friday January 28, 2005 @09:02PM (#11510229) Homepage Journal
    Basically, I find that the biggest problem with CSS is that it's like most of the other of the W3Cs standards: a really good idea implemented in a really half-assed way. (XML --- plus: namespaces, ASCII, structured data, extensibility. Minus: repetitive, bloaty, unseekable, attributes vs real nodes. XSLT --- plus: general purpose XML transformation language. Minus: it's written in XML; it's not a real programming language; it's stupidly limited in a lot of ways (variables that won't vary?). XPATH --- don't get me started. etc.)

    I'll leave aside whether it's a good idea to have a dynamic web page made up of three *different* scripting systems in one document, and just go on to mention two of the things that bug me most:

    Firstly, it does not seem to be possible (unless I just haven't found it yet, please feel free to correct me) to say that I want style FOO to be the same as style BAR except with these changes. i.e., true hierarchical styles. Any word processor worthy of the name supports this. It allows you to make sure that each important style property is defined in exactly one, central place.

    Secondly, CSS' styling system is very, very limited. How do you say, I want this container to be big enough to fit this string into? You can't. This means that any kind of layout where you have sized objects with text in them --- such as columns, or a header --- has to be specified in fixed values. You can't say, I want a graphic followed by a line of text followed by something that fills all the rest of the space. (You've got ems and ens and points but frankly, they're not useful.)

    I do think that CSS is currently the best thing around for formatting HTML; I've also used it with moderate success for formatting raw XML. It just makes me cringe when I think how good it could be, and how lousy it actually is... I keep having this urge to write my own formatting engine in Javascript, and that's never good.

    • Maybe you should read a book / the spec (Score:4, Informative)

      by brunes69 ( 86786 ) <[slashdot] [at] [keirstead.org]> on Friday January 28, 2005 @11:37PM (#11511129)

      Firstly, it does not seem to be possible (unless I just haven't found it yet, please feel free to correct me) to say that I want style FOO to be the same as style BAR except with these changes.

      What?? It is called Cascading Style Sheets for exactly that reason, it cascades!

      .foo{ background-color: red; color:green; }
      .bar{ color:blue; }

      <div class="foo bar">This has red bg color with blue fg color.</div>

      Secondly, CSS' styling system is very, very limited. How do you say, I want this container to be big enough to fit this string into? You can't.

      Big enough to fit what string? A container can fit any string with a proper overflow property.

      This means that any kind of layout where you have sized objects with text in them --- such as columns, or a header --- has to be specified in fixed values.

      This is simply not true. It is fairly simple to generate tabular layouts using pure CSS (that is what display:table-row and whatnot are for!)

      You can't say, I want a graphic followed by a line of text followed by something that fills all the rest of the space.

      Try this:

      <div style="display:table-row;">
      <div style="display:table-cell"><img src="http://images.slashdot.org/title.gif"/></div>
      <div style="display:table-cell;">Line of text</div>
      <div style="width:100%;display:table-cell;background-co lor:blue;">Fill line</div>
      </div>

      Seriously man.. CSS has lots of limitations (some of which will be addressed in V3, some of which aren't), but nothing like what you are spewing. I really suggest you read up some on the spec before you start bashing it so hashly.

      • What?? It is called Cascading Style Sheets for exactly that reason, it cascades!

        .foo{ background-color: red; color:green; }
        .bar{ color:blue; }

        <div class="foo bar">This has red bg color with blue fg color.</div>

        You sir, are my favourite person right now - I've been looking for this for years (even remember trying 'class="foo,bar" at some point; so close)! Now can someone tell me why not a single CSS tutorial/reference out there mentions this?

        I'd still like to be able to do this in the

      • something along the lines of

        .foo { background-color: red; color: green; }
        .bar { inherits: .foo; color: blue}
        and that applying <div class="bar"> would then set the bgcolor to red and the fgcolor to blue. In your example you still have to remember that .bar is based on .foo in every single place you use it. Much less useful.
      • Can you explain why I should use CSS table syntax rather than HTML tables? I'm trying to move over to using CSS for my layout, but finding that sometimes tables seem to be the only way to get the layout I want.
        • The best reason is if you ever want to change the layout of your site in the future.

          If done correctly and with foresight you can design complete a CSS layout which can be completely modified at a later date without a single change to your (X)HTML code. This isn't trivial, as it is hard to know for certain what changes you may want in the future.

          The typicaly scheme which I use on my rather simply laid out website (monsterden.net [monsterden.net]) is basically to divide the code up into chunks using divs, and assign IDs or
        • For HTML? No, I can't give a good reason really (other than that it is "more compliant", sort of.

          For XML? Well, Table tags don't work there, do they? :P

          That's the point, and half the power of CSS.. you can write a simple style sheet, and apply it to an XML DOC that you got from Excel or OpenOffice or whatever, and have it appear pretty.
      • <div class="foo bar">

        I didn't know about that; useful, although not quite what I'm looking for. Ta.

        (The thing I object to here is that it requires the HTML content to have detailed knowledge of the mechanism of the markup, which is evil --- there's no need for the content to have to state that that particular div is a foo and a bar. It should just be able to state that it's a bar. The relationship to foo should be in the style sheet.)

        Big enough to fit what string? A container can fit any string

        • "With CSS, I have to hard-code the logo's width, and I can't tell what that is, because it depends on the fonts being used."

          Your logo is "cowlark.com" in text. Thats 11 elements(characters). You can just set the size as 11em, and the browser figured out how much 1em is based on the size of the font.
          • Your logo is "cowlark.com" in text. Thats 11 elements(characters). You can just set the size as 11em, and the browser figured out how much 1em is based on the size of the font.

            Actually, an em is the height of the font, from the lowest descender to the highest ascender. (It used to be the width of the letter 'M' in that font, hence the name --- you'll never guess what an en is.)

            This means that 11em is going to be roughly the width of:

            MMMMMMMMMMM

            Which is much longer than my logo, in a proportional fon

    • I'll second the other responder.... CSS has plenty of control... in fact I wish that Quark and InDesign would support CSS for object positioning... then I could define placement as well as typestyle...

      Most of the problems probably come from rendering issues not spec issues....

      Try working with SVG for a while and be happy for basic CSS+HTML

  • There's a little script [sourceforge.net] I found that I use on my web page [maihem.org], though I know it doesn't all quite work, but then Windows users can all go install Firefox.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close