has unveiled Textpattern 1.0. You need web space and a working mysql database to play.
Many people
have weighed in on the question of CSS now that the issue has become a “live” one in the weblog world. A representative opinion on one “side” of the thing (if sides here makes sense, which I don’t actually think it does) is that of Matt Bridges in CounterProductive. He wrote, “When a designer uses CSS to mimic what can be done with tables, separating content into different boxes that are placed at specific parts of the screen, they tie that content to that layout. This completely defeats the purpose of separation of style from content.”
It’s a perfectly reasonable statement, and having worked on some CSS layouts I do see the drawbacks alongside the advantages. The problem is, however, that most people seem to have the foundational principles wrong. And their error leads in ugly directions.
CSS is about style. But there’s something much more important than that. Implementing CSS also returns structure to HTML. And that is where the value is – it’s not about separating content from style – that’s what a CMS is for. Rather, it’s to return the third variable – structure – to its rightful place in the mix. So that not only do you have the flexibility to do anything you want with the content (in the CMS), and to redesign that site as you like, but there’s also a fully degradeable version at the heart of the human-readable, “published” version that any device can read, as long as it can interpret HTML in some rudimentary way.
The question on the table
: Are tables really evil? Well, no they’re not. But they were never intended to be used to format web pages, and so now that there’s a better solution (CSS), they should no longer be used that way. Tables are still completely viable in HTML – but for displaying tabular data.
Why? Why, really, should anyone change? The best answer is this: for the same reason Userland developed Radio. Radio solves (as do other systems) a big problem: separating content from style. Trouble is, there are three variables, not just two.
Content – we know about that. Style – we know about that too. But there’s also structure to consider. Using CSS allows us to separate structure from style. This is as powerful, in its own way, as separating content from style, and just as important.
By using CSS to format my pages (though I do have one table still kicking around, unfortunately), I get to present items that any device can understand. If some bit of text is a very important heading on the page, I don’t obscure the fact by coding it with font tags and hiding it in a table that’s purely there to place it in a prominent position on the page. I call it what it is: h1. Simple, clean.
Most importantly, though, suddenly it no longer matters what device is trying to “display” or render my page. Anything at all will see that and display that bit of text as the most important thing on that page.
Why is that important? Well, because as Dave Winer says, the web should be a great writing environment – which implies that it should equally be a great reading environment. When I’m writing, I’m only concerned about me – my ability to write well and have it appear. To make it a great reading environment – and thus support the other side of the coin – I can’t just care about me, I have to care about everyone else as well. And the fewer assumptions I make about them the better. Who am I to insist that they use a certain device to look at my page? They read, their choice. Why should I make them track down an alternate version which may or may not work on their particular device?
If you want the web to be a great writing environment, you also want it to be a great reading environment. And that means using CSS to provide the style, HTML (or XHTML) deployed in templates to provide the structure, and a CMS to feed the content. It’s quite simple, actually.
Updates here have been
sporadic due to a great deal of busy-ness, but also because I’ve been working on a new design and playing around with Moveable Type, the new micro-CMS on the market.
The new design is going to be pretty nice, I think (if I do say so myself), but I’m having trouble rendering it using no-tables techniques. My current thinking is that the world should progress in that direction ultimately, and for extremely simple pages it is much more efficient to work with than tables are. Trouble is, there are just as many fudges and workarounds required as there were using tables, which pretty much makes the whole endeavour beside the point. So I’m going to have to make a decision – and right now, I’m leaning towards using tables. The point of all-CSS design is to dispense with workarounds and browser silliness (at least one of the points is to do so). If I can’t do that, I don’t see the point in making the switch.
Ummm, it’s about both
. The Talking Moose waded out of the mud and into the fire with his piece yesterday. It’s the most ridiculous thing the Moose, who has otherwise been a very interesting read, has ever published.
The poor Moose clearly doesn’t understand what web designers, as opposed to code monkeys or integrators, do for a living. He seems to think they need or want to code every page or something inane like that. On personal sites that may be true, but that’s just for fun.
You can’t do content management properly – or even do it at all – without a damn good designer figuring out how to make it look, and with a damn good coder to make that design work with the content management system, and without a damn good architect to make sure that it fits together well through time.
I’m just old school enough to think that all of those roles – designer, coder, and architect – are best done by a single person. But none of those interests are antithetical to using a content management system to actually make it all happen on a day-to-day basis. In fact, a CMS can’t be implemented efficiently unless those folks do good work first – otherwise, the benefit of the CMS is lost in a miasma of snippets and included code and exception-fixing.
Of course the irony is that the Talking Moose site itself is a good example of this fact. Bryan Bell couldn’t have casually changed the design of the Moose had his code (made up of HTML and CSS) not been clean and useful to begin with. Likewise, had Dave and the gang at Userland not built a weblog architecture whose function enabled the weblog form (with the calendar-based navigation etc.), Bell’s work would have been useless. And the “design” (defined strictly) would be a secondary concern had both of those things not been done well for the task at hand.
It’s absolutely about design and the kind of work people like Zeldman do and it’s all about integrating content management systems as closely as possible to the writers and other “content people” who are doing the publishing. There’s no fight here, though the Moose seems to have wanted to stir one up.
