CSS is BS

So today I not/iced that someone at the office has been printing out the calendar pages and taking notes on them. I never use paper, but I've long since gotten used to the fact that other people do; but this was just incredibly bothersome because it's extra wasteful: there's that menu on the left, and the text all comes out as gray on white, and is pretty unreadable.

I know that if you've drunk the CSS kool-aid, it's possible to make things print sanely: change colors, leave certain items off the page, etc. So I started poking around with using CSS on the DNA pages. <LJ-CUT TEXT="It did not go well.">

I thought I'd start off with something simple: instead of using tables to do my headings, like

   Contacting Us   

I should be able to just do

<H1>Contacting Us</H1>

and have it look the same once an appropriate style sheet was in place, right? "Here is how we render H1."

Wrong. As far as I can tell, that can't be done with CSS. The closest you can get is this:

Contacting Us

with the box going all the way to the edges of the page. As far as I can tell, there's no way to tell the size of the box to be based on the size of the text. You can tell it to be exactly 30% of the page width -- but that's not the same. The only way to do it is to wrap the H1 inside a TABLE!

Contacting Us

So I can replace my table-based layout with... table-based layout?

I have learned (or in some cases reconfirmed) a few other things about CSS, too:

  • Web designers, and especially blogging web designers, are self-important fuckheads. This might be tolerable if they were right, but by and large they're also dumbasses.
  • Everybody who fancies themself a CSS expert uses pixel-based layout for everything. Their shining examples of elegance always include boxes that are exactly 400 pixels wide, and that specify font sizes in pixels (not even points!) This is better than auto-flowing auto-sizing table layout... why?

  • Most of the time, these examples look like ass on my screen, presumably because I'm not running Windows and don't have the same fonts that they do. Or maybe because they're all using 50-inch monitors and sit with their noses on the glass, the only way those miniscule fonts could actually look readable to someone.

  • They never measure in "em" units, so that their boxes might have at least some relation to the size of the text inside them.

  • This may or may not be because "em" doesn't work consistently across various browsers.

  • Oh, "em", a term from the world of physical typesetting, is supposed to be the width of a capital letter M, and used only for horizontal measure; the vertical measures are ascent, descent, leading, and sometimes "ex" (height of a lower case "x".) CSS defines "em" as being the height of an M instead (making it synonymous with "ascent"), which makes it generally about twice as big as you'd expect if you know anything about this stuff. Nice. That's like redefining "centimeter" because it seemed more convenient at the time. (Except sillier, since "em" is an older unit of measure than centimeter is.)

Really what I'd like to do is just leave my pages as-is, but insert something that says, "oh, if you're printing, change all the colors like so, and leave the menu out." But I'm not sure that's possible without going whole-hog into the CSS madness, or at least starting to tumble down that slippery slope.

And a slippery slope it is. Here's a great example: once you start doing anything with CSS font sizes, you can't ever use the FONT tag again.

Have you noticed that when you post to LiveJournal and do <FONT SIZE="-1">, the font actually gets bigger? Feel the love as the Mozilla people mark my bug report Resolved Invalid. This is because the FONT tag, when used to request a font "one tick smaller than the current size" has no knowlege of what the current CSS font size is -- and they claim this is the right and sensible thing! Like, HTML thinks the font size is "3" and then it sets it to "2", instead of noting that the font size is "14px" and then setting it to "12px". You get screwed if, as is often the case with LiveJournal, your "2" font is still bigger than whatever the font specified in the style sheet is.

Let me say that again, because I still can't really fathom it: they think that the current behavior, of asking for a smaller font and getting a bigger font, is the correct behavior.

This kind of crap, among other reasons, is why web sites should never, ever specify the font family or size of their default text. Just use the default, always. Web browsers let users pick their default font families and sizes for a reason. Are you listening, brad?



Update: scroll down...

Tags: , , , ,

62 Responses:

  1. mattlazycat says:

    This kind of crap, among other reasons, is why web sites should never, ever specify the font family or size of their default text. Just use the default, always. Web browsers let users pick their default font families and sizes for a reason. Are you listening, brad?

    Amen. Especially since Internet Explorer 6's "text size" menu options don't work if you specify absolute font sizes with CSS. This also is "correct" behaviour. It is also cock. Tiny shrivelled lazy-stupid-programmer cock. This is what happens when you design by committee. There's always a posse of sharpnosed little nerds at the back who treat software design-to-spec like they were running a D&D game.

    I do everything in CSS now, but it has some major drawbacks, especially with positioning. My life hasn't become magically easier now that I don't have to wrestle with tables. There's no way in CSS, for example to have two columns be the same height, unless that height is the height of the browser window. And vertical align doesn't work. The H1 problem you had is also insanely boneheaded. You might be able to get around it by setting "auto" as the left and right margin width, but then IE5 doesn't do auto margins, and it looks like cock again. (Then again, to be fair, making all headers the same width is probably better, design-wise, but that's not the point is it? The point is that CSS won't let you do what you want.)

    The huge sense of self importance you detect in most CSS/XHTML evangelists stems from their utter elation at finally pummelling their design expectations and wrestling with buggy CSS implementations until they finally compromise in some Israel/Palestine sense of the word. They become one of the few, and enjoy rubbing our noses in it. "Well I did it, so you must be able to! Unless you're stupid, that is.. you're not stupid, are you?"

    What they forget is that either as designers, they're awful and unambitious, or as people, they suffer from short term memory loss and have forgotten both the hours of fucking around with a style-sheet that they just suffered through, and that the end result is nothing like their original aim. To them, tinkering with a style-sheet is like fucking around in /etc/ for days at a time... for fun.

    • jwz says:

      I thought you might be amused by what your use of the &ldquo; entity turned into once Mozilla 1.3 got its hands on it:

      Are we living in the future yet?

      • mattlazycat says:

        Mmn, cock.

        In Mozilla 1.3 mail (which is what I'm writing this in now), it looks like this:

        (Cock)

        So not only does it screw up, but it screws up differently according to the document type. Yay progress.

        If that's the future, I'm hoping for another groundhog day. Either that or I'll beat up a trekkie and steal his time-space anomaly.

  2. adcott says:

    This comment probably confirms your self-important fuckhead theory, but what you are attempting is actually possible (well, it worked in Opera7 and IE6 when I tested it)

    <style type="text/css">
    h1 {
    text-align: center;
    font-size: 1em;
    }
    h1 span {
    color: #0F0;
    font-size: large;
    background: #040;
    padding: 6px;
    border: solid 1px #0E0;
    }
    </style>

    <h1><span>Contacting Us</span></h1>

    Contacting Us

    and for this...

    Really what I'd like to do is just leave my pages as-is, but insert something that says, "oh, if you're printing, change all the colors like so, and leave the menu out." But I'm not sure that's possible without going whole-hog into the CSS madness, or at least starting to tumble down that slippery slope.

    I'm not sure if this constitutes as madness or not:

    <style type="text/css">
    @media print {
    * {
    background: transparent !important;
    color: #000 !important;
    }
    #menu {
    display: none !important;
    }
    }
    </style>
    • rpkrajewski says:

      Assuming it works, that is.

      I think some of CSS can't be learned on demand; you actually have to a read an overview and internalize the model, which includes basic but almost invisible features such as !important and the display attribute.

      • beerfrick says:

        Maybe that's so they can sell CSS books :)

        • rpkrajewski says:

          Indeed. Since CSS is old enough for many books on it to be somewhat but not fatally of out date, you can usually find a good one on it from the bargain bin. The problem with concentrating on learning tricks (how do I get flames behind a few words ?) or even reading the spec from W3C is that you'll think you know what you're doing without learning the fundamentals. I mean, I've a veteran of text processing languages (TeX, Scribe, R/roff, I even helped with the macro package for GNU texinfo) and there are things are CSS which are novel compared to them.

    • altamira16 says:

      I stumble through CSS, and you have done several things that I did not know were possible.

      I did not know that you could do

      h1 span{
      blah
      }

      I thought you had to use each tag seperately.
      I also did not know you could use the
      @ symbol anywhere in CSS.

      • injector says:

        Wow, you are missing out on a lot. Selectors in CSS is where most of the power comes from.

        The two most important:

        foo bar = bar anywhere inside a foo, no matter how nested

        foo > bar = bar just inside a foo

    • That works, but the <span> tag is really ugly (also, totally content-free). There is a better way:


      h1 {
      display: table;
      margin-left: auto;
      margin-right: auto;


      color: #0F0;
      font-size: large;
      background: #040;
      padding: 6px;
      border: solid 1px #0E0;
      }

      The display: table causes the block to wrap itself to the text (shockingly, like a table). The auto margins cause the table to be centered.

      • adcott says:

        I'm not a fan of display:table;, (although it will still validate) it seems structurally wrong to not have child elements with display:table-row; and display:table-cell;.

        • I don't really see the CSS table layout properties as structural in any sense (they're just rendering hints—“draw this like a table; now draw this like the row of a table…”), so display:table and its offspring don't bother me in the least. This is especially true since the alternative is to scatter meaningless <span>s and whatnot around. CSS is supposed to alleviate clutter, not just replace <table>s with <span>s.

          • adcott says:

            You're absolutely right, display:table is just like saying "draw this like a table." or more specifically "draw this like a conaining block for a grid-like display of data." but that's not really what's wanted in the first place. What is wanted is a centered peice of text with a border and background. The fact that it was the norm to center tables in HTML is no reason to mimic it all out in CSS.
            <span>, by definition, is a null element, yes it adds 13 bytes to the download and the markup looks a wee bit messier. But, in this case it's just there so it isn't necessary to start telling browsers that something is a grid of data when infact it's just a quicker way of getting it to display the way ye olde bodged HTML would do it.

            I agree with you that CSS was designed to alleviate tag soup, but to me it was also designed so pages were coded appropriately for the content displayed. A page wouldn't need for tables to inserted left, right and center just to get borders etc. Whilst your method does take this out of the markup it sticks it back into the stylesheet and we're right back where we started, just with a smaller download.

            • jwz says:

              Whilst your method does take this out of the markup it sticks it back into the stylesheet and we're right back where we started, just with a smaller download.

              Uh, but I thought that was supposed to be the whole point? Moving presentation games into the style sheet and using only semantic markup in the body?

              (Of course I know that's not really the point of CSS, really the point is that the "designers" wanted to do pixel-accurate layout. But they always tell you that it was about semantic purity and accessibility, just like wars are never about oil, and the pro-hemp lobby cares deeply about the economics of the textile industry.)

              • adcott says:

                Well yeah, that is the point... but in doing it is there really a need to mimic HTML tables when you can get the effect initially desired with a method that makes sense?
                It's just my opinion that css attributes like display:table should be used to display a table, not just as a shorter way to shrink wrap boxes around text and center it, all in the same selector.

              • But they always tell you that it was about semantic purity and accessibility, just like wars are never about oil, and the pro-hemp lobby cares deeply about the economics of the textile industry.

                B-but… Eric Meyer said…!

                Now you're probably going to tell me that there is no Easter Bunny, and Donald Rumsfeld doesn't care about all those children

              • montoya says:

                Who gives a damn what the secret motives are of the people pushing CSS? The question is, does it work well for moving presentation to the stylesheet. I say that a) it does, and b) this is a good thing.

                CSS isn't perfect, but it's a sight better than what came before.

      • jwz says:

        But <lj user="makali"> said that auto-margins don't work in IE5?

        Which is a whole other bag of worms -- I'm reasonably certain that I can just sit down and write TABLE stuff blind, test it once in Mozilla and have it Just Work in every browser from NS3 onward. I have no intention of building a stable of other browsers to test on. If that kind of indignity is necessary, then I'm clearly doing things the wrong way. If you have to resort to that, then the tech you're using is too bleeding edge: I'm completely uninterested in being part of the W3C's "learning experience."

        A few months ago I made the mistake of converting my bookmarks page to CSS, instead of using a frameset. It seemed like a good idea at the time. But of course I had to resort to absolute sizing (though at least I used em instead of px) and I'm told that it doesn't work in MSIE anyway: apparently it puts the body to the right and below the menu. Whee.

        • But <lj user="makali"/> said that auto-margins don't work in IE5?

          Oh, yeah. Right. Lovely.

          I should point out that they're only broken in IE5 for Windows. So the only people affected are those running an old browser made by a company you hate on an operating system made by that same hated company.

          Which isn't the point, of course.

          If you are concerned about IE5 users, you might note that pragmatically speaking, this:

          <h1><span>April 2003</span></h1>

          …is probably a win over this:


          <div ALIGN=CENTER>
          <table CELLPADDING=1 CELLSPACING=0 BORDER=0>
          <tr>
          <td BGCOLOR="#00EE00">
          <table CELLPADDING=3 CELLSPACING=0 BORDER=0 WIDTH="100%">
          <tr>
          <td NOWRAP ALIGN=CENTER BGCOLOR="#004400">
          <table CELLPADDING=0 CELLSPACING=0 BORDER=0>
          <tr>
          <td WIDTH=20></td>
          <td><font SIZE="+1"><b>April 2003</b></font></td>
          <td WIDTH=20></td>
          </tr>
          </table></td>
          </tr>
          </table>
          </td>
          </tr>
          </table>
          </div>

          …especially if the former can be made to save trees.

          • jwz says:

            A win in what sense? In the sense of "working properly in fewer browsers"?

            • Yes. That sense exactly. Some people have inferior browsers and, well, we don't want their sort hanging about.

              (I was thinking in terms of having rather more readable, scrapable HTML that prints out how you tell it to. But if it only works on your monitor, and—generously—my monitor, the fact that the code is now prettier isn't overly helpful.) (On the other hand, I think it actually does work in pretty much every browser. Some of them will just display minimally-styled content, but the content is what matters anyway, right?)

        • illiterat says:

          A few months ago I made the mistake of converting my bookmarks page to CSS, ...
          and I'm told that it doesn't work in MSIE anyway

          And is it just me, or does keyboard navigation not work anymore? (like focus is accidently bound to menu on the left, and can't be changed).

          Personaly I like using some CSS so that I can alter the style of objects of class X by just changing the style for that class, but I don't pretend there's no markup in the page ... it's just done once instead of inline'd for each use. And I only ever use the "relative" type of position (and even that very minimaly).

      • jwz says:

        Incidentally, I never would have known about "display: table" had you not mentioned it, because the CSS reference I've been using thus far is this one, which does not list table on its explanation of display. This suggests to me that "display: table" is even more bleeding-edge than the rest of this crap?

        • phyxeld says:

          I've never heard of display:table either, and I do a fair ammount of CSS stuff. I'm almost certain it's nonstandard.

          Your h1 takes up the whole width of the page because it's display:block;
          You could change it to inline, or put a span inside the h1 and style that instead (as shown in a comment above).
          You might also try leaving it blocked and using margin: 0px auto 0px 0px; (or some other auto margin thing).

          Table layouts are bad, but the font tag? Please! The font tag has been obsolete for years! One day, everyone will stop using it entirely, and we'll laugh at the last people who still did. Get with the program, dude. This kind of kool aid tastes really good, once you figure out the box model. I'd suggest reading alistapart.com archives; they have some great articles that will help get you up to speed. Also, google for the "NYPL style guide".

          CSS is the way and the light. You'll learn to love it one day, I'm certain.

          *sigh* this is my first ever logged in LJ comment, and I'm spending it trolling jwz about CSS...

          • jwz says:

            See, I thought you were just trolling, but it's so fucking hard to tell! Actually, I'm still not sure, since when it comes to CSS, irony is obsolete.

            BTW, "a list apart" is one of the sites I had in mind when I wrote about jackasses who use pixel-positioning for everything: in his demo form halfway down the page here, just after the "FORM(s) and Function" heading, it looks like this on my screen:

            From reading the code, he clearly did not intend any of those boxes to be overlapping (the form elements are intended to be inside the enclosing rectangle), but he coded it so that any variance in displayed font size causes everything to go completely to hell.

            I'm supposed to take advice from people who make rookie blunders like that and hold them up as examples? Puh-fucking-lease.

            • phyxeld says:

              See, I thought you were just trolling, but it's so fucking hard to tell! Actually, I'm still not sure, since when it comes to CSS, irony is obsolete.

              The funny thing is I'm not even sure. On the one hand, I realize you've got some valid complaints about CSS. But really, I think most of the problems stem from current differences in implementation, just they always have in the wonderful world of web dev. And really, ultimately, I think CSS is going to make for a (somewhat new + improved) much better tomorrow. The old way definitely sucked, and the new way can be made to work better. So, in all seriousness, I hope you learn to love it.

              Just don't go reading anything about xhtml 2.0 or xforms, or you'll likely vomit all over the keyboard...

              • jwz says:

                The funny thing is I'm not even sure. On the one hand, I realize you've got some valid complaints about CSS. But really, I think most of the problems stem from current differences in implementation, just they always have in the wonderful world of web dev.

                Well yeah, and in 1995 there were similar "differences in implementation" when trying to do things the tables-way. And thankfully, time passed and now everybody implements tables exactly the same, for the most part, and you don't have to worry about it. I can write a tables-based page, and it will work absolutely everywhere.

                This is clearly not the case with CSS. Perhaps it will be by, say, 2008. Seems to me that that's when I should start depending on it.

                And really, ultimately, I think CSS is going to make for a (somewhat new + improved) much better tomorrow. The old way definitely sucked, and the new way can be made to work better. So, in all seriousness, I hope you learn to love it.

                I honestly don't see how CSS sucks less. It's just different. It's not simpler, it's not more expressive, it's not more concise, it's not more portable, and it also appears to not do better separation of semantics/presentation.

                Oh right, it lets you do pixel-based layout. Um, yay?

                • ioerror says:

                  It works better for disabled people and software that can choke on tables.

                  If used correctly, you can use lynx, links or IE. It doesn't matter which one.
                  Sure you may have an over laying form input, but that isn't css, it's the implementation.

                  Sure some people botch the layout of css but css isn't just for tables.

                  If you really need to use tables, why not?

                  But for the most part, css works well.

                • montoya says:

                  CSS absolutely can do better semantics/presentation separation. But, like any real-world technology, it's not a magic bullet; it has limits, and there are things it doesn't do well. (Trying to replicate flexible table layouts without using tables is one of them.) The key to successfully using CSS is to keep your design within the limits of what CSS can do well (which should be perfectly fine with you, since you're not one of those pixel-perfect designers, right?).

                  It's frustrating that arbitrary designs aren't cleanly achievable in CSS; but then, they weren't cleanly achievable in FONT 'n' TABLE markup, either -- and if CSS can't cleanly do everything that tables could do, there's a lot of things CSS can do cleanly that old-style methods couldn't do at all.

    • injector says:

      How about if you just changed the "display" of h1, to "inline"?


      h1 {
      text-align: center;
      color: #0F0;
      font-size: large;
      background: #040;
      padding: 6px;
      border: solid 1px #0E0;
      display: inline;
      }

      Contacting Us

      • It isn't centered. The text-align property applies to text inside the heading block. If you center the text in the block containing the heading, the heading will become centered as well. As will all your body text, in the very likely event that “the block containing the heading” is “body”. That probably isn't what you had in mind.

        Setting the left and right margins to “auto” doesn't work either, as the “auto” margin setting isn't particularly meaningful for inline blocks.

        • ralesk says:

          Though, for all your viewing pleasure, one could put this H1 inside a <DIV Align="center"> kind of thing... Just to make things really complicated and such.

    • jwz says:


      Really what I'd like to do is just leave my pages as-is, but insert something that says, "oh, if you're printing, change all the colors like so, and leave the menu out." But I'm not sure that's possible without going whole-hog into the CSS madness, or at least starting to tumble down that slippery slope.

      I'm not sure if this constitutes as madness or not:

      <style type="text/css">
      @media print {

      See, that's the slippery slope I was talking about. I can't just add that to my pages, because <BODY BGCOLOR="..."> has precedence over style-sheet backgrounds, even with !important. So I'd at least have to replace all my body tags with CSS fu. And, though I'm not sure, I fully expect that once I've gone that far, I'll have to go farther, and farther, and farther... I'll discover new things about TABLE and FONT that start malfunctioning once you've got CSS in your life, and I'll have to convert more and more just to catch up with yesterday.

      Which would be fine, if CSS actually worked as well as what I used in 1995, but I don't really see evidence that it does.

      (And dammit, <lj user="brad">, why is your HTML cleaner stripping out my <NOBR> tags?)

      • adcott says:

        ...because <BODY BGCOLOR="..."> has precedence over style-sheet backgrounds, even with !important.

        Actually, it seems that even without !important stylesheets will override the attributes in the body tag: test.

        • jwz says:

          Hmm, right you are. When I tried this, I thought I saw the opposite behavior. Guess I was wrong. In fact, this seems to work, according to Print Preview in Mozilla 1.3:

            <head>
            <style type=text/css>
            @media print {
            body { color: blue; background: yellow; }
            }
            </style>
            </head>
            <body text=green bgcolor=black>
            screen should be green-on-black.<br>
            print should be blue-on-yellow.
            </body>

          (Though Print Preview actually shows blue-on-white instead of blue-on-yellow, which is somewhat expected.)

  3. brianenigma says:

    I have found that you can reach a happy medium between exclusively using CSS and not using it at all. Of course, I am not "a web designer," but a programmer who occassionally has to (or wants to) make a web site. Nothing I have done has, or needs, pixel-perfect positioning. Why do all these so-called web developers need to position a floating table 30 pixels to the left and z-ordered under their crazy JavaScript animated menu bars that never work outside of IE? Nice looking pages can still be designed without that stuff, often have less HTML bloat, and are easier to come back to and edit/maintain (without Frontpage/Dreamweaver/MS-Word, or any other so-called HTML editor).

    Generally, I stick strictly to colors in my style definitions: font colors and table background colors. A good alternative to the FONT tag with +/- sizes is to use a percentage. The SPAN tag with a "font-size" style of 80% or 125% tends to work pretty well. Of course, that takes a few more bytes than the FONT tag (even if you define it up in a stylesheet), but the proportionality means it works even if the user has their browser's default font jacked up to 48pt.

    ...just my $0.02. Again, I am no web designer, I just play one on the internet.

    • jwz says:

      Why do all these so-called web developers need to position a floating table 30 pixels to the left and z-ordered under their crazy JavaScript animated menu bars that never work outside of IE?

      Yeah, and I knew I was in shark-infested waters when, after 20+ minutes of googling for "css examples" and the like, more than half of the pages I came across had their left-side menu-boxes positioned such that no matter how you resized the window, they always occluded some of the body text! Wow, what a great feature that you can make the first six characters of every line always be hidden.

      It's always a great big warning sign when such a large percentage of the people who are trying to explain how to do things so clearly don't have a clue themselves. This says "something is fundamentally wrong with the system." Possibly only that it's too complex; but in this case I suspect the breakage is more fundamental than that.

  4. teleject says:

    H2 are block level elements. You will need to wrap a span or an element around the actual text of the headline and then stylize that to get the effect you want. E.g.,

    <h2><a name="contactingo">Contacting Us</a></h2>

    In a weird sense of timing, I've recently posted a 50+ CSS Heading examples. Hopefully this will get some ideas on how CSS can be used to add style to your documents.

    If you need pointers on printing with CSS, let me know--and yes, my book on CSS has a chapter that deals with it.

    • jwz says:

      So, your examples seem to say that to do what I want to do, you believe I need to use both H1 and SPAN, one inside the other.

      It seems to me that if I have to do that, then what's the point? If I have to have magical tag-ordering in the body to make it display the way I want, then I'm still encoding presentation into the body text! If I can't say, simply, H1 with nothing else around it (doing all the magic in the style sheet itself) then I'm not doing semantic markup, I'm still doing presentational markup.

      And if I'm gonna do that, then why not just keep doing it with tables, which work in way, way, way more web browsers?

      • teleject says:

        You are essentially correct. If you do find yourself having to go back into the HTML to fix problems to create a certain style effect, then there's a problem. Either in how you marked it up to begin with or CSS itself. And CSS, as it is, has limitations--some of which will be addressed in CSS3, some aren't. Plus we are still waiting for some of the major browsers to get CSS1 and CSS2 nailed down completely.

        In the meantime, if you want to use CSS to create certain designs--we have to deal with workarounds. You can use the span or an anchor tag. Or you could even try to try setting a width on the heading in ems in order to allow for flexibility on the font-size issue, and then setting margin-left and margin-right to auto. It's your call.

        Personally, I think CSS offers many more advantages than disadvantages that I would prefer to not go into dealing with HTML tables, single pixel GIFs or FONT tags every again. That's not to say I won't, I'm quite good at 90s production methods. But I favor the use of a few DIVs and SPANs over a mess of HTML tables and FONT tags any day of the week.

      • css_junkie says:

        "So, your examples seem to say that to do what I want to do, you believe I need to use both H1 and SPAN, one inside the other."

        Does that make you shrink in horror? Why then do you
        feel comfortable with two table tags, two tr tags, and
        two td tags? Sounds pretty magical to me.

        And in exactly how many more browsers does the table work?
        99.1% as opposed to 99%? Woah. Pretty open and shut I guess.

        Virtually ALL the problems with css are caused by M$ failing
        miserably to adhere to even the most basic standards, and
        allowing myriad bugs in their browser to remain, version
        after version, with even a few NEW doozies in IE6. It's
        sickening to think about the way those two-faced jerks
        are killing a good idea.

        Anything to crush the competition. Just code for IE alone
        and all is well...

        BTW, I do use tables when appropriate or the page requires
        behavior that M$ makes impossible. Like it or not, we all
        must kiss Bill's royal arse.

  5. malokai says:

    This is why I don't trust anyone who's job was created after 1990.

  6. jwz says:

    I ended up doing the minimal thing, and added this to the HEAD of every page:

      <STYLE TYPE="text/css">
    <!--
    @media print {
    * { color: black !important;
    border-color: black !important;
    background: white !important; }
    .noprint { display: none !important; }
    }
    -->
    </STYLE>

    And in addition, for the various TD elements that I don't want to bother printing out, I added CLASS="noprint". This was easy, since (almost) all of my pages are generated by script (statically.) I did it this way instead of adding an external style-sheet URL because I figured it was more efficient to add another couple hundred bytes to each file than to add another connect() for each page.

    Everything else stayed the same: colors specified in the BODY tag, etc. Seems to work ok in the browsers various people have tried. NS4 doesn't understand display: none, but gets the colors right. Apparently Safari crashes in Print Preview, but hey, bummer.

    • forthdude says:

      Worked fine in Safari for me.

      safari 1.0 Beta 2 (v73)
      os x 10.2.5

    • The included style sheet can be retrieved once and then cached. Also, in the wonderful world of HTTP/1.1, we are supposed to have connection reuse and pipelining.

      • jwz says:

        Yeah, I know that's the theory. In the real world I'm sure there's a ton of multiple-connection If-Modified-Since latency.

        • If you have control over the web server, you can have it emit some cache control headers which will cut down on that. Yes, I know, you would think this stuff would just *work* by now.

          You could have the server preprocess each links to a dependency into a URL based on its checksum, and mark all of those as cacheable forever. So much for separation between content and transport, though.

          • jwz says:

            Yeah, I could do all that, or you know what I could do? I could just add those ~200 bytes to each file instead.

            • When I say "you", I am not saying *you*. :) Just contemplating how to solve the same problem scaled up to an include size and a traffic level where it matters.

  7. agrumer says:

    You're right about em being a unit from traditional typesetting, but wrong about what it means. An em is the size of an em quad -- a square of type material the size of the type to which it belongs, and generally used for indenting paragraphs. An em quad in a case of 12-point type was 12 points high and wide. Its name does derive from the fact that in many early type designs a capital M was approximately square, but if you look at actual fonts the em generally has nothing to do with the size of the capital M.

  8. aad says:

    I spent about a week trying to coerce CSS layout into replicating the trusty:

    <table>
    <tr><td colspan=2>site header</td></tr>
    <tr><td width=66%>content</td><td width=*>menu</td></tr>
    <tr><td>site footer</td></tr>
    </table>

    Even at the end it only worked "mostly" right in most browsers, and any given display glitch report was answered by browser authors/vendors/support with "we're standards compliant, everyone else has a bug".

    I gave up.

    The impression I came away with is that whoever created CSS layout knew that a lot of ass hole designers had done some pretty heinous things with HTML to get around its limitations, and the CSS creators decided to aavoid this problem by not consulting designers. This is obviously the wrong approach, but it's the only one I can fathom, because CSS layout makes it difficult to do all but about half of the really simple things people want to do. You read that right. The standards are so nebulous that every browser interprets them differently, and while things are converging, it's a dramatically worse "standards" situation than even tables were in six years ago. (And the "that's easy, just try [non obvious, not particularly well documented feature]" comments above and elsewhere on the web prove my point, not the opposite.)

    Meanwhile, a lot of designers have hopped on the CSS layout bandwagon, seeing that it solves a lot of problems they ran into before. What they don't see is that they've changed the sorts of design they produce. But it's obvious: most CSS layout based sites look different from most table based layout sites because CSS layout makes it too difficult to do the sorts of things most people do with table based layout. Meanwhile, the most zealous of converts rant about "standards" in a way which has nothing to do with anything. Tables are in the standard, but they're also interpreted pretty much the same by all browsers. CSS has a standard so big that on Thursdays the entire W3C staff simultaneously stands up and yells "hey, standardize this!", but that doesn't mean that any two browsers interpret this "standard" in a standard fashion.

    Zeldman has 5 pages on how to do a two column layout (without a footer), and another site refers to a three column layout as "the holy grail". Last I checked, the holy grail was a legendary and powerful artifact, a label not rightfully applied to a layout any idiot could learn to make with tables in 3 minutes of reading the docs. The three column layout isn't considered impressive because it should be, it's considered impressive because CSS layout makes it hard and the people who use it have the lowest of ambitions.

    CSS is a nice idea, but it needs to be extended to support simple layout, and the layout issues within in it need to be standardized before anyone will be able to use it for much.

    • anonymous says:

      well just stepped into this discussion, linked over from feedster.com.
      3 column css layout with footer http://www.ecommnet.co.uk, its easy when youi know how, its re-usable, it works with screenreaders and lynx, opera does some strange things with one or two of the pages, but overall the work we've done recently to make it, and a number of other customer's sites look this way has paid off. Form follws (but is separate to) content, content is king!

  9. Personally I use CSS and tables together... CSS to centralize appearance markup, and good old-fashioned tables for layout more complicated than simple flow with the occasional block-level element. I have found some simple-yet-useful layout effects only possible with CSS, but the results are often not sufficiently portable, even assuming NS4 is not a target.

    CSS isn't a complete system for mapping text to images. Whether I want my web browser to contain such a system is an interesting question... between Javascript and SVG I'm not sure I will have a choice soon. Certainly there have been moments where I was trying to do something in HTML and wishing for Display Postscript, but often that is a hint to the designer that they should let the content speak for itself and get out of the reader's way.

    About the pixel-based layout thing... surely you know that pixels are not pixels in CSS?

    • jwz says:

      surely you know that pixels are not pixels in CSS?

      OH. MY. GOD.

      So they've now guarenteed that "px" will have all the problems that "point" has historically had! Do they also have a requirement that images be auto-resized to the same scale?

      • Presumably they would have to, otherwise you couldn't mix images and text and know that the relative sizes would remain correct. Or maybe they imagine that varying the relative sizes depending on the medium is desirable. (Supply higher-quality images when printing?) Hopefully browser implementors will ignore such nonsense. (Although if the user could define the pixel/px ratio, that might actually be useful.)

        On the other hand, the display gamma differences between Mac and PC already make lots of things look like ass, I don't see why we can't toss in a scale difference too :)

  10. firelegend says:

    look what you started :)

    - brandy AKA firelegend (mediadiva.net)

  11. anonymous says:

    A possible solution is demonstrated in the following code:

    <!DOCTYPE html PUBLIC "-//W3C//DTD 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <title>Test</title>
    <style type="text/css">
    <!--
    h1 {
    text-align: center;
    }
    h1 span.txt {
    background: #040;
    border: solid 1px #0E0;
    color: #0F0;
    margin: 0px;
    padding: 6px;
    }
    -->
    </style>
    </head>
    <body>
    <h1>This is a heading</h1>
    <p>This is a paragraph. This is a paragraph. This is a paragraph. This is a paragraph.</p>
    <h1>This is a heading</h1>
    <p>This is a paragraph. This is a paragraph. This is a paragraph. This is a paragraph.</p>
    <script type="text/javascript" language="javascript">
    <!--
    var h1 = document.getElementsByTagName('h1');
    for (var i = h1.length-1; i >= 0; i--) {
    with (h1[i]) {
    innerHTML = '<span class="txt">' + innerHTML + '</span>';
    }
    }
    -->
    </script>
    </body>
    </html>

    I used a style sheet to format to format both the headings and the marked-up text. A bit of JavaScript at the end is also used to transform the non-marked-up text children of the headings into markup-up text. In the future, I plan on adding a text mark-up rule to the XSLT that I use to write web pages (so this quirk of CSS doesn't bother me again).

    -Jimmy Cerra
  12. anonymous says:

    I've never seen such a long winded conversation showing how resistent to change people can be. CSS seperates all the visual styling from your HTML, not to hurt you as a designer, but to help you. It makes it so you can focus on making sites easier to maintain, smaller in size, and usable for a larger number of people while maintaining a crisp professional look.

    Just spend some time (it's not like CSS is EXTREMELY complicated) and learn the rules.

    It sounds like you have a lot of time invested in your site and that it's done with traditional HTML (font tags, bgcolor attributes, etc). The time it takes for you to move your markup into this century will be repaid to you 10 times over when you're maintaining templates (I hope you're not hardcoding each of your pages) or redoing your design.

    Not everything in life is a conspiracy theory. It might be of more help to you to ask questions on how to solve problems you run into, rather than bash the technology that is offering you more flexibility. There are tons of people out there that have already taken the leap and can help you.

  13. darkcryst says:

    hey, I knwo this is an old post, but I followed a link here as was moved to comment.

    I think the problem with CSS isn't that it can't do what people want, its that people are reluctant to change their methods of coding to suit CSS.

    Also the annoying people that evangalise CSS are just as annoying as the people that claim its all BS. The truth is somewhre inbetween atm.

    CSS for the most part is implemented badly by designers. Using a correct doctype in your code eliminates 95% of all problems in browsers, yet some sites are still crap.

    CSS won't make a bad designer any better, but it will allow him to make a more flexable bad design that downloads quicker.

    Designers aren't coders, and coders aren't designers (generally speaking that is) so deigners rarely want to learn a new language - which is what CSS is. The examples you gave are really easy to achive across browsers. IT just requires more knowledge of CSS than you have.

    That isn't a slight to you, just fact.

    Another problem is that many people are idiots when it comes to upgradein their browser. They wouldn't complain if a 286 didn't run win98, but they will complain if a 6 year old browser doesn't work on all websites. CSS helps here by seperating the presentation from the content so - as long as the deisgner is a good one - even people that can't see styles will be able to read the content without a problem.

    Its about flexability and accessability in design and code. Two things that have been neglected, and now don't have to be. In fact legally might have to be concidered now.

    I hope you have more luck with CSS, try checking out this comprehesive and well organised resource if you'd like a good reference on what can and can't be done, as well as how.

  14. sheala23 says:

    "and that specify font sizes in pixels (not even points!) This is better than auto-flowing auto-sizing table layout... why? "

    It's because the Mac OS displays points differently, which makes the page render differently then what you'd expect. With specific pixel specification, you can have the same page completely cross platform. Yeah, it's pretty anal.