A New Era in CSS Centric Design? 233
byrnereese wonders: "The media never fails to point out how the age of Web Two-Point-Oh has helped to drive the adoption of Ajax into the Internet industry, but rarely does anyone point out that it has also help popularize CSS-centric design practices -- the Slashdot redesign being only one example. But now that we, as programmers, feel comfortable ditching the use of font tags, finally grok div's, understand absolute vs relative positioning, and can work around all of IE's CSS bugs, what is the next step for HTML and CSS? Several standards or conventions seem to be coming to forefront: one is building standards around the HTML structure itself so that wildly different designs can be achieved via style-sheets alone (e.g. CSS Zen Garden and The Style Contest), the other being the standardization of CSS classes (e.g. micro-formats) so that semantic meaning can be derived from the class name we use to label our content. Both show an interesting potential for how this technology is evolving. So here is the question for all the visionaries out there: where is this taking us? What's next for HTML? What's next for CSS?"
Comment removed (Score:5, Insightful)
Re:I'm sure the naysayers will be here shortly (Score:5, Informative)
No, it doesn't. Seeing as web programming is my job, I can tell yout that tables - horrible as they may be - make a better layout tool than CSS. I can't tell you how many times I have to tell graphic designers that one of the elements of their design (like equal length columns) is a major pain in the neck to implement in CSS. Of course, IE's horribly buggy CSS2 support doesn't help, but there are so many things in CSS that seem - well - stupid. CSS was designed around an idealistic view of the web - a web where pages were designed by web developers. In the real world, this is rarely the case - it is the graphic designers who lay out the page, and the web programmers get stuck trying to implement their design. CSS utterly fails in that regard.
Sure, you can make a design that works well using CSS - zen garden and countless other sites prove this. But there are so many things that were simple with tables that become unnecessarily complex with CSS.
Most developers simply give up and resort to absolute positioning or nesting
There are other elements of CSS that are utterly stupid. Why should padding be excluded from "width"? Or, for that matter, the border? Why is it so hard to make equal-height columns?
Is CSS better than what it replaced? In terms of element style - borders, fonts, colors, etc. - it's substantially better. But CSS sucks at layout.
Re:I'm sure the naysayers will be here shortly (Score:5, Insightful)
This is why tables were popularized in the first place. The lay-person who just wanted to throw up a personal web page had neither the time, nor the inclination to learn CSS, so they resorted to the easiest possible manner of positioning things the way they wanted: tables.
Creating layouts with CSS was never easy, which has always been exactly the problem.
But there are problems with table-based designs, first and foremost being user presentation, in the form of increased load times for the increased amount of text, AND because browsers can't render the table until the entire thing is downloaded. I have seen some website that don't come up for quite sometime because their entire 226kb layout is contained within a single outer table, so it doesn't show up on the screen until the whole page is downloaded.
The second major problem with table-based designs is accessibility: screen readers for the blind don't like tables very much. I don't know about the newest versions of programs like JAWS, but the ones a few years ago would read every table element, including empty ones that only contained spacer images. Not a very user-friendly experience.
Most developers simply give up and use tables because it's faster. This is ALWAYS the motivating factor in businesses where time is money - and consequently why so few commercial websites are built using CSS. It takes longer to learn. But once you learn it, things that are at first "unnecessarily complex" become easy, just as tables are easy now because everyone does it that way.
"Easy" in the end has less to do with syntax and language, and more to do with how widely the technology is used, because the more people use CSS, the better the documentation for it will be, and the more websites will show you how to do simple things like a 3 column, full height layout (which I know how to do; I have a basic template I always use when starting a new page for this layout, so I don't have to redo it every time).
Re:I'm sure the naysayers will be here shortly (Score:2)
Actually, table layouts were popularised because most web browsers didn't implement a style language at the time and table layo
Re:I'm sure the naysayers will be here shortly (Score:2)
What browsers have you been using? Every browser i've used renders tables before completing the page download.
Sorry dude, but if you're viewing html websites that are that fat, it's not because of html (unless the web designer
Re:I'm sure the naysayers will be here shortly (Score:2)
How in the world does the browser know what to draw until the [/table] tag has been reached? The reason you see some of the page render as it is downloading is because it's drawing intermediate tables that are already completed. I'm talking about a very few poorly designed websites (and yes, I agree that's because of the developer, not the HTML), because over the years people have learned NOT to jam 200kb of content into one table
Re:I'm sure the naysayers will be here shortly (Score:2)
No, it's because back then (when Netscape 3 came out), tables were the only way to do it. CSS wasn't implemented in any browsers for a while after that, and the early CSS implementations were pretty buggy.
Re:I'm sure the naysayers will be here shortly (Score:2)
Well, I can't disagree with you there. That part is insane and I hope in the next couple of years we see a proliferation of fully CSS compliant browsers. I mean, that's the whole point of standard in the first place. Even Firefox doesn't fully implement CSS correctly, and I'm not sure why.
Re:I'm sure the naysayers will be here shortly (Score:2)
Full support of CSS isn't necessary for the production of CSS designed websites. It just needs to be good enough - which is where we already are. Its the same as not needing to know every word in the English language in order to have a conversation.
Re:I'm sure the naysayers will be here shortly (Score:3, Insightful)
Try align="char". Or how about the whitespace-significant bug Internet Explorer has? Or how about THEAD/TFOOT? How many browsers do something with the axis attribute? How about the vertical-alignment "bug" that is actually correct behaviour but breaks up table layouts so that there's lots of little gaps? What about the abbr attribute? Do some browsers still treat optional closing tags as required (not sure about this one)?
Table layouts are buggy too, i
Why CSS xor Tables? (Score:3, Interesting)
Re: (Score:2)
Twisted logic (Score:2)
Re:Twisted logic (Score:2)
Re: (Score:2)
Re:Why CSS xor Tables? (Score:2)
Re:Why CSS xor Tables? (Score:2)
But how long have you been doing table layouts? And you expect to catch up to that level of experi
Re:Why CSS xor Tables? (Score:2)
But tables are way, way easier to learn than css layout is.
Where would you be if you had stuck with the first programming language you ever learnt instead of facing the learning curve and accepting that in the beginning, some things are going to be more difficult until you get a bit of experience in the new language?
It's called priorities. There are a whole bunch of more intere
Re:Why CSS xor Tables? (Score:3, Insightful)
I think I can speak for most people who have used CSS for a while by saying that once you actually know how to use CSS, table layouts are far harder, tedious, and time-consuming than semantic markup and some CSS. I'd recommend trying to redesign a table-based site (with no tabular content to boot; that's like using a spreadsheet program as an actual database). Oh wait, that might take a while as you have to change every fucking page and deprecate
Re:Why CSS xor Tables? (Score:3, Informative)
Templates (Score:2)
Re:Templates (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:5, Insightful)
Whether or not tables are a better (I think you mean easier) layout tool, they are not meant to be used for anything other than (gasp) tabular data. Using a table for anything else is bad semantics, page bloat, and, let's face it, primitive.
In the last three years, every site I've attempted to rebuild in CSS from tables I've been able to do with 90% accuracy. It's not only a different layout tool, it's a different layout model. You can't expect tables to CSS to be a 1:1 conversion, there will be compromises along the way.
I've been in the same situation with graphic designers. The problem is that they think the web works like paper, where the design is a monolithic entity that simply exists. They have little to no understanding of what HTML and CSS is, does, or how it works. The concept that their full screen 50 layer photoshop file will be chopped up, gutted of text, and reassembled later is entirely beyond them. Long time print designers make the absolute worst web designers, I've found.
Another part of the problem is browser support for CSS, especially the various values for the display property (especially table, table-row, table-cell, inline-block), and the position property. Position is mostly misunderstood, anyway: "relative" is not the default value, "static" is. See my sig for my thoughts on browser CSS support.
Too many people try to wrestle with CSS to make it do what they want. This is most often the fault of a poorly thought out document structure combined with a poor understanding of CSS. Let the document work for you, I always say.
CSS is vastly better than what was before: nested tables full of font tags. CSS is more flexible, concise, and clean. Is it perfect? Not in its current form, but maybe the next version.
Equal height columns are easy: height: 100%;. Too bad IE can't get this right unless you declare the height of the parent element. Hate the implementation, not the specification.
Re:I'm sure the naysayers will be here shortly (Score:2)
Out of curiosity: what browser does that work on? I fooled with it, and I couldn't get it to work without declaring the height of the body explicitly on either konqueror or firefox. I may not be doing it correctly either, I suppose. Do you have an example, perchance?
Re:I'm sure the naysayers will be here shortly (Score:2)
Dracos is (sort-of) wrong. From the specification [w3.org]:
The special case for the root element was undefined in previous specifications [w3.org], which is why Internet Explorer doesn't get it right.
So basically, Dracos' technique should work, but only i
Re:I'm sure the naysayers will be here shortly (Score:2)
<div style='height:auto;'>
<div style='margin-bottom:0px;'>
$text1
</div>
<div style='margin-bottom:0px;'>
$text2
</div>
<div style='margin-bottom:0px;'>
$text3
</div>
</div>
Re:I'm sure the naysayers will be here shortly (Score:2)
Explain to me how
is "bloat", trying to get CSS to do the same thing ends up with 4x the code.. THAT's bloat.
what's the actual advantage to the CSS layout? not enough gain to justify it's bloat/comp
Re:I'm sure the naysayers will be here shortly (Score:2)
Long before there were web designers churning out pages of advertising, there were content providers whose needs are significantly different. My experience as a web developer consists of over a decade of devising ways of presenting procedure manuals, FAQs, help pages, reports, and similar information on the web. My goal is to do this in a way that makes revisions and additions simple. Ideally, so simple that the content developers can do the maintenance and extensions on their own, without needing to study
Re:I'm sure the naysayers will be here shortly (Score:2)
Really? So you let them edit raw html? I once had to setup a website of a university department, where each researcher had to write a page about ongoing research. No way I could get them to do that, so I ended up letting them use frontpage (at least it's better than Word for this purpose), and then hand-editing it myself after filtering out the crap that Frontpage produces.
Re:I'm sure the naysayers will be here shortly (Score:2)
Using CSS, you can cut down the size of the markup pages to negligible, and a one-time download of a CSS file isn't bad either. Downloading a crapload of useless tables that don't even show tabular content (y'know, more than one column and one row, each column and row is related to each other somehow, a "table" of "data" if
Re:I'm sure the naysayers will be here shortly (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:2)
I use CSS for layouts on a daily basis, but just about anything you said here is wrong.
Tables are not bloat, a three cell table is not larger as HTML code than the outer set of 4-5 divs required to fake it qith faux columns, not to say the added weight of the extra images required for faux columns which is not the case with tables (especially if you want simply solid color columns).
About tables being "primitive", I guess you're too sophisticated to expa
Re:I'm sure the naysayers will be here shortly (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:2)
You are being completely unrealistic. If he can mog together a layout with a few tables, I'm sure management would prefer that to hiring additional p
Re:I'm sure the naysayers will be here shortly (Score:2)
Or just fire the graphics designer and hire a web designer. Who you fire/hire certinainly depends on the situation, of course, but a good web designer will ultimately come up with a better design than either a graphics designer or a programmer. Not only that, a good CSS based layout is MUCH more flexible than the table design. When manage
Re:I'm sure the naysayers will be here shortly (Score:2)
I'm a web developer too, and I think the exact opposite. Take a look in any bookshop lately. How many books are teaching table layouts these days? How many books are teaching CSS layouts these days? I think it's clear which layout method is preferred on an industry-wide basis these days, regardless of what individual developers like you or I think.
The main reason table
Re:I'm sure the naysayers will be here shortly (Score:2)
But that's the great thing: you don't need a damn book to learn how to use tables.
You'll get no arguments from me about the merits of CSS, but one thing I don't like about it is that it's a lot harder to pick up, especially for layout. Now sure, if you do web stuff for a living - big deal. You learn what you gott
Re:I'm sure the naysayers will be here shortly (Score:2)
That's funny, because if I remember correctly, a watershed moment for the uptake of table layouts was when the technique was included in one particular book. So yes, when the industry wasn't swamped with loads of developers who knew table layouts, you did indeed "need a damn book to learn how to use tables". There's nothing that makes CSS layouts intrinsically more difficult than table layouts, it's the fact that table layouts came first that mak
Re:I'm sure the naysayers will be here shortly (Score:2)
It told me there were three choices:
* A table-only based layout;
* A CSS+Table-based layout; and
* Pure CSS
It also said that pure CSS was more complex and handling browser varations were more difficult. It looked to me that if I wanted a table with three columns, all of them with background colors filled to the bottom, I would have to create a fixed-size layout, kno
Re:I'm sure the naysayers will be here shortly (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:2)
Doing your first site in 100% css is HARD. There is just no other way around it. You are going to spend days trying to figure even the most simple things out, and there are going to be temptations to revert back to the easy (not better) table layout. Some will succumb, and some will soldier on and succeed.
Table-based layouts are wrong. Tables were designed to show tabular data. By using them for layout, you are perverting t
Re:I'm sure the naysayers will be here shortly (Score:2, Informative)
Ohhh yeah. It took me two months to figure out my first 100% CSS website [charleshagenah.com] (it's kinda wonky in anything other than IE... bare with me, it's one of my first). I had so many restrictions: must fit verti
Re:I'm sure the naysayers will be here shortly (Score:2)
This isn't the case. The width attribute of tables and table cells can take a percentage width, which is all you really need for fluid layouts.
Re:I'm sure the naysayers will be here shortly (Score:3, Funny)
There's also no way you can approximate what the CSS float attribute does with only tables
You're right. It's impossible to reproduce all the float bugs with tables.
Re:I'm sure the naysayers will be here shortly (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:2)
It's fundamentally broken in that it's incredibly arcane. A sane standard would have examined what people actually did in web pages and other layouts and designed constructs that would accomodate those.
CSS gives you a bunch of tags and a "box model" that no one had ever heard of, that is incredibly hard to implement and that bears only a mathematical relationship to what the user wants to do.
If CSS let the user break the page into actual elements that humans deal with, like
Re: (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:3, Insightful)
Neither the blind nor tools for processing semantic markup deal with CSS (not @screen anyway) - they deal with the markup.
CSS should have had operators to group marked up data and style things relative to their place in the group. And it should have had the ability to set constraints on sizes (eg
Re:I'm sure the naysayers will be here shortly (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:2)
And of course you realize that XSLT is not in any way a replacement to CSS... When using XSLT to do web stuff you generate HTML with xslt, and style it with CSS.
At least a cool thing about CSS is that it can remove a lot of complexity in XSLT sheets since most of th
Re:I'm sure the naysayers will be here shortly (Score:3, Interesting)
CSS is awfully computationally heavy. Full CSS support would be a hell for handhelds and such. It defines how things sho
Re:I'm sure the naysayers will be here shortly (Score:2)
Where did you get @mobile from? Are you thinking of @media "handheld"?
Re:I'm sure the naysayers will be here shortly (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re:I'm sure the naysayers will be here shortly (Score:3, Informative)
Re:I'm sure the naysayers will be here shortly (Score:2)
Re:I'm sure the naysayers will be here shortly (Score:2)
You're forgetting that abusing the <table> element type for non-tabular data is a hack in itself. The real choice is between hacks that appear in the HTML for every page (table layouts) and hacks that appear in a single stylesheet (CSS layouts). When you pollute your HTML, you make it harder to do things like screen-scraping, use user-stylesheets, use Greasemonkey scripts, cache effectively, a
Re:I'm sure the naysayers will be here shortly (Score:3, Insightful)
Hopefully CSS3 will make this discussion moot in the near future.
Re:I'm sure the naysayers will be here shortly (Score:2)
The websites I did this for are no longer up, but it's not something I found terribly difficult. In fact, I learned to do almost everything better without Javascript, especially dynamic multi-level menus that are easy, semantically correct (e.g. using ul and li instead of tables and javascript), and stylishly appealing, using about 100
Re:I'm sure the naysayers will be here shortly (Score:4, Insightful)
Three-column layouts are easy.
Tell me that CSS is broken and I know you'll be trolling. We all know it's not CSS that's broken, but browsers. Browsers have bugs. Web developers have to work around them. This is nothing new. Table layouts themselves are one big bug workaround hack. You say you don't want browser-specific hacks in the CSS, but the CSS only has to be written once. I want to avoid hacks in the HTML, which is one of the reasons why I choose CSS layouts.
Re:I'm sure the naysayers will be here shortly (Score:2)
I mostly agree with you, table based design is stupid. But saying that you can resolve the issue by using display:table is just unrealistic. And even if you can find workarounds most of the time, they're just that, workarounds. And they often take way too much time...
And CSS 2 is broken, in some places. How do you pla
Re:I'm sure the naysayers will be here shortly (Score:2)
Wow, talk about missing the point. My point was not that you should use this for public websites. My point was that it's not CSS that is broken, but Internet Explorer.
The last child of the <body>
Re:I'm sure the naysayers will be here shortly (Score:2)
Why are you referring to those guys? They are pretty sleazy. Why not refer to the authorative source [w3.org] for whether something is valid CSS or not?
No, which was basically my point. CSS doesn't make it difficult, Internet Explorer makes it difficult.
display: table-cell has been around since 1998, and most brow
Whatever is next ... (Score:4, Funny)
Re:Whatever is next ... (Score:2)
There.. Fixed that for you..
rounded corners (Score:3, Funny)
Re:rounded corners (Score:2, Informative)
Simple answer (Score:4, Informative)
What's next?
XHTML2 [w3.org] and CSS3 [w3.org]
But XHTML2 can't be a reality until IE can parse XHTML, or IE loses a lot more market share. (no, it can't, it can parse pretend XHTML that's served as text/html, and you can't serve XHTML 1.1 or XHTML2 as text)
Re:Simple answer (Score:2, Insightful)
Re:Simple answer (Score:2)
ok.... (Score:2, Funny)
how about browser standardinzation 1.0 (Score:2)
Back when one had to code for multiple versions of IE with poor CSS support it was just easier to hack together a mix of HTML layout and some inline CSS embellishments.
IE7 still has some significant CSS issues, but we're getting much closer.
Imagine when IE8 and Firefox 2 both support CSS3 nearly identically!
Re:how about browser standardinzation 1.0 (Score:2)
CSS (Score:2)
2 to 3 more years of the same, then a shift (Score:2, Interesting)
First, let's get a couple things straight:
What's next won't even be achieveable for two to three years. The other browsers will continue to implement standards as they are drafte
Re:2 to 3 more years of the same, then a shift (Score:3, Informative)
What semantic changes happend between HTML 4.01 and XHTML 1.0?
I don't think there was one single such change.
Re:2 to 3 more years of the same, then a shift (Score:3, Insightful)
HTML 4.01 has not been deprecated in any way.
HTML 4.01 and XHTML 1.0 are virtually identical in terms of semantics. You do realise that things like <font> are present in XHTML 1.0, don't you?
CSS 2 won't be achievable for two to three years, let alone CSS 3. Internet Explorer 7.0 will still be missing key parts of CSS
Re:2 to 3 more years of the same, then a shift (Score:4, Informative)
That's funny. Because XHTML is a carbon copy of HTML 4.01 as a dialect of XML. All that got "cleaner" is that XHTML uses a subset of SGML (XML), where HTML is a SGML dialect.
The semantics of both are totally the same. You've been brainwashed.
XHTML2 has some competition, however, in the form of HTML5. While I can understand frustration at the glacial speed of the W3C at producing new documents, WHATWG seeks to damage most of the progress made since HTML 4.01.
W3C says "do as I say". They can't even implement what they recommend properly. They tried, with Amaya, and the project is now dead (not to mention it was always one buggy and slow piece of software).
WHATWG catters to the needs of the web developers and web users TODAY. They are formed by browser makers and web developers who have feet firmly planted on the ground as to what constitutes a semantic and functional web we can actually use.
W3C unwillingness to cooperate brought us the table hacks, and now the CSS hacks. We, web devs, always have to use "hacks" of some sort, not just because of bad browser implementation, but because if plain defunctional standards..
Then come zealots who claim W3C can't be wrong, refuse to join a discussion and declare WHATWG is a bunch of terrorists who want to blow up the internet.
Good thing is, while zealots are pretty vocal, the rest of the practical folks are quietly working on making a better Internet with WHAWG.
The canvas element and SVG bring new ways of displaying graphical stuff to be interacted with
The canvas element was invented by Safari and incorporated in WHATWG's HTML5. I though they work hard on wrecking the Internet?
the table layout trolls and Dreamweaver monkeys will be two tech generations behind
The current generation of Dreamweaver produces strict XHTML with CSS based layouts. I bet ranting at fukll power didn't leave you time to see how the world around you adapts to changes.
Absolute positioning makes things much worse (Score:2, Flamebait)
"A good carpenter doesn't blame his tools" (Score:4, Insightful)
Something I advise developers new to CSS is to avoid using absolute positioning until they clearly understand the side-effects of applying it and to generally treat it as a last resort in the CSS toolbox - kind of like 'if-all-else-fails try the sledgehammer'. With a well structured document as a foundation (headings, lists, et al) then a good understanding of floats, margins and clear can do most layout tricks for you, but if there's no other way but to use absolute positioning then use it with 'em' and 'percentage' units again to keep it scaling. Granted that this is difficult to do if developers use todays WYSIWYG authoring tools - almost by definition.
Not a giant step backwards by any means, developers of problematic sites just need to think a bit more about the best use of the tools in the CSS toolbox and a bit more about designs that scale. After-all, it's possible to create rigid layout problems with table-based design too.
Re:"A good carpenter doesn't blame his tools" (Score:2)
Re:"A good carpenter doesn't blame his tools" (Score:3, Interesting)
It's mainly evil if you use it to place the main layout blocks, but once you enter into those blocks it's often very useful to place sub elements by using absolute inside the parent element positionning (i mean by using #layoutblock { position: relative } #layoutblock #logo {position: absolute; top: 0.5em (or maybe even px); left: 0} )
What i mean is that maybe it should not only be seen as the last resort, but also as something
IE digs, Firefox, and Safari (Score:2)
I checked and validated my HTML and CSS code against the W3C validation tools
CSS help (Score:2)
div#left {width: 4em; height: 1.5em; float: left;}
div#right {width: auto; height: 1.5em;}
IE renders them next to each other and on the same line (as intended), but there's a ~4 pixel gap between these two boxes. I checked margins and borders, that's not the problem. To fix it, I placed these two into another div with the background, but that for some reason seems to screw up Ope
Re:CSS help (Score:2, Informative)
Here's a great article that explains all the width quirks and ways to fix it:
http://www.communitymx.com/content/article.cfm?pa
Re:CSS help (Score:2)
I'm trapped in /.'s CSS theme & I can't get ou (Score:2)
What can you do if you don't much like
Re:I'm trapped in /.'s CSS theme & I can't get (Score:2, Informative)
fully intended to (Score:2)
Something which bugs me about the W3C (Score:3, Interesting)
I think it would make things so much simpler for everybody, especially if they used firefox or another free (freedom) browser as a base. Maybe it would force others to fill the gaps.
In fact in my perfect world they'd just code a friggin good xhtml/css engine, make binding for x languages, and provide it for free to every browser maker or whatever... Seriously, I know it won't happen, but it would be such a step forward for the web in general.
Choice is good, competition is good, but not in this particular area. You'd still be able to chose between a lot a browser, but their rendering would be consistent.
Re: (Score:2)
Re: (Score:2)
Re:Just a question... (Score:2)
Some of your most important visitors are blind. Or do you think the Googlebot has eyes?
Re:Just a question... (Score:2)
I agree that CSS is harder than it should be, but it still gives a better end result than tables. In many cases, a design principle allowing for easy or efficient implementation by user-agents has caused CSS to have artificial limitations. And given the fact that browser vendors have produced some pretty dire implementations, you can hardly blame the CSS-WG for trying to make it easier f
Re:Just a question... (Score:2)
Its a nice sound bite - but, in practice, tables for layout aren't that much of an accessibility barrier. Screen readers today can ignore table markup - they've had to adapt to the bad markup practices and short comings of web designers and web developers. But there is a limit to what they can do, and its certainly
Re:Just a question... (Score:3, Insightful)
I use 4 different web browsers depending on where I am and what I am doing. Very few sites render on all 4 of them, mainly because people assume the client is running on a graphical desktop with a large dis
It's a feature!!! (Score:3, Interesting)
The other effect of proper Divs are AJAX related. That's what allows
MOD PARENT UP (Score:2)
And apparently I'm on some kind of mod point blacklist, I haven't had mod points in months.
Re:I love css (Score:2)
Troll??
Stick the CSS in a file and use it as your browser's custom CSS file. (hint: ad-free slashdot..) And actually, while we're here, let's refactor a bit: