A tool for CSS as a language of visual effects

A tool for CSS as a language of visual effects: "

John Nack sees what modern-day HTML and CSS can do and notes:

HTML’s new graphical richness means great opportunities to generate efficient, visually expressive content.  ”What is missing today,” says Michael Slade, “is the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.”

Indeed, creating complex layouts with rich effects and intricate typography is very quickly becoming not only possible with HTML and CSS, but easier than the alternatives in many ways. Try mocking up an interesting layout in Photoshop. Now, decide to bump up the overall font size. Good luck! (this is not a knock against Photoshop; the app wasn’t built for this.)

Jeffrey Zeldman says nay:

PostScript doesn’t care whether an element is a paragraph, a headline, or a list item. It doesn’t care if a bit of content on one page cites another bit of content on a different page. PostScript is a visual plotting language. And HTML is anything but.

This is premised on a reasonable, but wrong, assumption. That assumption is that Nack is talking about creating web pages. I don’t believe he is.

Web pages are semantic, interconnected, hierarchical things. HTML isn’t necessarily that way. Because you know what else “doesn’t care whether an element is a paragraph, a headline, or a list item”? An HTML block (note that I don’t even say “document”) consisting of divs and spans styled with CSS - perhaps even *gasp* inline CSS. This is not the web Zeldman is interested in. It’s no web at all, in fact. But it’s a fast, extremely performant, widely available, and even fairly humanly readable way to describe layout and graphical styling. 

You all know the iPhone, right? Did you know that if you make an iPhone app, the only sane way to style any text in it is to place the text in a web view - a small web browser inside a view inside your app? It sounds crazy. This is not the way things are done on the Mac, where you style your UI controls using, for instance, RTF. For whatever reason, Apple’s engineers decided to essentially switch to HTML as the text formatting language in Cocoa touch apps. 

Or, look at any of Apple’s stores on the iPad - App Store, iTunes Store, iBookstore. Heck, look at the iTunes Store on your computer: it’s all made with HTML and CSS. Why? Because in the year 2010, if you’re going to be describing layouts, it’s not a bad call to describe them using very well adopted, rapidly developing technologies. And while these are somewhat flexible layouts, they’re not saddled with all the problems of designing for the web at large - inconsistent implementation across browsers and operating systems, varying user preferences, etc. The target is much clearer here. These layouts are flexible - about as flexible as a native Mac app. Ask a brilliant Cocoa engineer to write a nice webpage and watch their spirits break after hours of cursing at CSS. But give them CSS as a tool for describing the formatting of things they normally work on - text labels, table views - and it’s not so bad.

Writing semantic, well structured HTML is indeed an art. But: as far as I know, it’s not impossible to write beautiful PostScript either. Closer to my dayjob, I can confirm that some people’s Photoshop documents are a joy to work on - layers well grouped and understandably named, helpful layer comps and notes, useful guidelines. And then some other people’s Photoshop documents are a nightmarish pile of Layer 1s and Layer 85s stacked in one giant, dizzying Layer Jenga. In my experience, the quality of document organization is not related to the quality of the Photoshop work. Like the aforementioned HTML block of nameless DIVs, it may be difficult to understand and maintain, but it works.

I’m not advocating this approach. I’m just saying a middle ground is entirely possible - any sufficiently complex layout will begin to confuse even its authors after a while, no matter how much they try to make it semantic. At this point, it would be nice if HTML artists could stop mixing their own paints and focus on the end result instead. Let’s look at an example:

The above is a screenshot of a webpage I made a while ago. (It’s unfinished and all sorts of buggy at the moment.) It uses a total of zero images. You’ve seen this sort of thing done before, so I’m not bragging - just setting up the scene.

The de facto standard for mocking up things like this is Adobe Photoshop. Had I gone that route, it would’ve taken me several hours of putting layers to canvas. But, as Nack points out, “Spend a bunch of time perfecting your design in PS/AI, then throw it all away and start again!” So I did this all in HTML and CSS from the get-go. It wasn’t easy, and I have no idea how semantic or beautiful the code is - I blacked out while writing the fiftieth CSS gradient and putting container divs inside container divs and figuring out how to float the thing but not the other thing.

So while there are large parts of this I’d prefer to code by hand, there’s no pride or glory in tweaking number after number and reloading a page to make sure my drop shadow looks nice. Just as Photoshop wasn’t built to create box layouts, CSS wasn’t built to create visual effects in an immediate, intuitive - heck, visual way.

It would be nice if some tool helped out with that. It wouldn’t be “InDesign for CSS” any more than Illustrator is “SuperPaint for PostScript”. Maybe it wouldn’t generate fabulously semantic code - and wouldn’t need to. Maybe it wouldn’t help you build a webpage from scratch. But it could still be nice.

"