CSS Layouts: More trouble than their worth.

CSS is Wonky

There is nothing more frustrating than to see a gap in a CSS layout and
not know where it comes from. This is a fundamental problem with CSS.
Ideally the way you express a problem (e.g. "there's a 3 pixel gap
there: make it go away"), is related to the way you solve it. But with
CSS it becomes a whole thing (e.g. "well, the bottom div has a
clear:both on it but there's a line break between it and the previous
div which IE is (correctly) interpreting as whitespace, so I have
to...."). In a way, this is the story of a programmer's life: taking a
problem described in the most natural way, and making the correct
change to make it go away. But with programs, you can always fall back
to bits. With CSS you have to fall back all the way outside of CSS
(into a paint program) to fix things.

No-one denies that CSS is great for styling a document: setting fonts, background colors, and even working with margins, padding, and things like that. The problem is when you try to use CSS for page layout, things go a bit wonky. A lot of the problem is browser incompatibility; but I think CSS has some intrinsic "issues", both in it's syntax and in the way it's (not) debugged.

CSS Wonky Syntax

Consider what you have to do to center a div: you use #mydiv {margin: 0 auto;}. I find this counter-intuitive. What's wrong with #mydiv {align: center}? You could also separate "center" into "center-horizontal" and "center-vertical" if you really want to be pedantic. You will run into this problem literally in the first 2 minutes you try to use CSS for anything real.

It's also too bad CSS doesn't have any higher level constructs. Often when defining a layout you'll have a group of related selector/property pairs (for example, defining the properties of "#nav" and then the properties of "#nav a") but, except for comments, you have no way to group these selectors together. In fact, I think it would be cool to support nested selectors. Something like "#nav { background:blue a{border:none}}. This means that anchors in the nav context get no border. But that syntax doesn't work. This lack of grouping makes CSS messy.

CSS "NIH Syndrome" Wonkiness

CSS is trying to solve a problem that has been solved like a million times before. The problem is: how do you map from some plaintext to a pretty raster image? It's been solved by TeX, Postscript, RDF, and lots of others. CSS isn't even as good as these it can never have pixel level control over the display. In that sense it's a true partner to HTML which has always delegated pixel level control to raster formats.

CSS Debugging Wonkiness


For a programmer, one real problem is that we can't debug CSS like we
would debug anything other program. When something subtle goes wrong, I want to step through the layout program's steps to
find out what's going on. Yes, this might require that I glean some insight into how the layout engine works. Wow, what a concept! AFAIK there are no browsers that support
stepping through the browser layout process. I think that alone would
make people happier than they are today, where they are forced to treat
the layout engine as a black box to be felt out by experiment. So, in
many ways my frustrations with CSS mirror my frustrations with Swing,
but CSS is infinitely worse: I can always debug my Swing layouts, I
don't have that option with CSS.

(Of course, it took forever just to get a decent set of tools that could inspect the static state of a DOM (Firebug). I'm not holding my breath for a DOM renderer debugger that doesn't require you to have the source for the browser under test!)

What can fulfill the CSS Promise?


To me, CSS promises something good: a concise, textual way to describe how my documents should look while keeping the original document small and machine-readable. That is a wonderful promise, but it's not what CSS gives you. CSS gives you a world of hurt. The only reason people endure the pain of CSS layouts is because a) they have to or they'll lose their job or b) they think that because it's a standard it must be followed. I don't know about you, but I've tried pretty hard and I can't describe how my documents should look with CSS. I just can't. I can describe how they should approximately look on one browser pretty well. The amount of effort one reasonably intelligent person must expend to even get this far is too much.

When looks matter, use a raster. Photoshop is a really good way to specify pretty pictures: use it! Use tables for layout! Be happy!

Or replace the program that maps from HTML to raster image; replace CSS. For example, create a full page Flash "browser" that reads the HTML it's embedded in and renders it according to some rules. In this way, machines would still have access to the data, but now rendering is done in a full-blown programmer controlled environment. History and bookmarks would work - the swf "browser" would just have to load again on every page. It could even be "built in" to the browser via an add on. The host rendering engine (gecko, webkit, etc) would be there just for backward compatability, and perhaps to render short sections of old-school HTML.

Canvas/SVG could be used as a Flash equivalent when it matures.



No comments: