CSS Sucks (for layout)

I'm often amazed by people who defend CSS as an amazing technology for layout. I get where they're coming from - I mean it is a pretty reasonable way to handle styles (font stuff, mainly), and it has a laudable goal - namely to separate content from the layout. But as a technology for marking up layout? It's about the lousiest thing I can think of. It's painful. it's a chore.

CSS3.0 is starting to address some of these issues (border layout handling, for example, is something that we should have had since the start - and by start, I mean since Netscape 1.0), but it still needs to be backwards compatible with the older CSS functionality, which sucks.

But don't take my word for it. John Nagle doesn't like them either. (And yes, that's right, that's John Nagle. As in Nagle Algorithm). Here's a post I found from him on this blog:

You’re absolutely right.With Dreamweaver 3 and tables, it wasn’t necessary to look at HTML to lay out a page. With Dreamweaver 8 and CSS, the page designer must understand CSS, HTML, and probably Javascript. That’s was a big step backwards.

The CSS system is just too programmer-oriented. And I’m a programmer. (Programmer as in MSCS from Stanford, the Nagle algorithm in TCP, inventor of ragdoll technology, real-time robot vehicle control, not programmer as in “writes some Perl”. And my first web site went up in 1995.) It’s not that CSS is hard; it’s that CSS is bad.

CSS is, simply, a badly designed layout system. Even the rather simple system in Tk which lays out dialog boxes and windows is better. Tk is a nested-box system, but both “pack” (like CSS “float”) and “grid” (like tables) layouts are available in the same system. This is enough to handle most cases. Which “float” and “clear” are not. Page layout is forced to fall back on absolute positioning far too often.

The clever way to do layout would have been with a constraint system. Each box has four edges and four corners, and it would be possible to bind corners and edges to create any desired relationship between boxes. This is something one could express easily in a click and drag graphical tool. Want three columns the same height? Tie their adjacent bottom corners together.

Want to fill the page? Tie the outside corners to a page edge. Ten minutes to explain to an artist. Advanced use would involve priorities on constraints, so if something had to give in “fluid design” as the page size or type size changed, you could pick what gave first. (This could be extended to allow curved boundaries, even splines, but that might be overdoing it.)

The browser would have to have a constraint engine to resolve all the constraints, but there are known solutions to that problem.

Too many people drank the Kool-Aid on CSS. It’s just not that good a technology.

...

The worst problem with DIV-based layout is that the layout system is too weak. There’s no form of “grid” layout. There’s no way to relate a DIV to anything but its predecessor, its parent, or an absolute position. The system is just too dumb. That’s why people have to stand on their head just to get three columns to work.Tables actually are a better designed layout system. Table layouts allow table cells which span multiple rows and columns. If all tables could do were simple grids of cells, the CSS approach might make sense, but tables are more general than that. And they’re well supported in Dreamweaver.

The fundamental limitations of DIV-based layour are obscured by an excessive number of attributes and the occasional use of Javascript when the attributes aren’t enough. But underneath, the fundamental approach is just too weak.

If CSS had a grid capability, it wouldn’t be so bad. But it doesn’t.

So there you have it. CSS sucks.

I'm thinking about an alternative solution for some of the problems... If I get time I'll post it up.

Another Threadless submission... Foxxy Music

So here's another T-shirt design of mine... please visit Threadless and vote if you like it :)

Robots Have Feelings Too

I've decided to start doing a bunch of designs for Threadless.com and see where I can get with them. Here's my first one :)



Please visit the site (just click the picture) and vote if you like it :)

Update: Well, damnit. It looks like this one didn't make it through their pre-screening. Bugger.

Funniest drug warning ever

From the myalli.com website..

You may feel an urgent need to go to the bathroom. Until you have a sense of any treatment effects, it's probably a smart idea to wear dark pants, and bring a change of clothes with you to work

(MyAlli is a drug designed to help you lose weight by blocking enzymes that digest fat...)

Eat High Fructose Corn Syrup? Don't forget to take your fish oil...

A bit of a dry article this one (it's from the journal of the American Diabetes association), so let's sum it up...

If you're eating a diet high in fructose - particularly high fructose corn syrup - which means pretty much everyone in the United States...

... take your fish oil.

It'll reduce your triglyceride levels. It's about the best you can do unless you entirely want to avoid processed foods, until the food companies stop using High Fructose Corn Syrup in their products.

I can highly recommend reading the article if you can skim through the scientific jargon. Or understand it ;-)

(from wikipedia: in the human body, high levels of triglycerides in the bloodstream have been linked to atherosclerosis, and, by extension, the risk of heart disease and stroke)

Simon's Law of Software Development (and Evolution)

OK, I know, a bit egocentric to name a law after yourself, but here goes. It applies in all kinds of places, but it's really for the most part a Software Development law.

Architecture is persistent.

The moment you sit down and start writing code, you're laying down the architecture for your software. It doesn't matter what you write, it has infrastructure. All code is infrastructure, with other code that does something to the data. Most of the code you will ever write is spent navigating that infrastructure to gather data and perform operations on it, and then store that data out.

This gives us a number of interesting little results that you see in the real world all the time:

Once you write some code, the architecture you decided on sticks around.

Seriously. The more code you write, the more the architecture you specified becomes embedded in every piece of code you write. You can't help it - it's part of the code's DNA. Every choice you make will pervade everything your code does forevermore.

For example... You write a large piece of code which has a scripting system which is used for everything - header generation, you name it. Script based objects are garbage collected.

Now, later, you decide "Hey, wait a minute... this GC is slowing me down... the script language isn't completely fleshed out so it's hindering me, and it's not suitable for all of the tasks I envisioned at the start".

Tough cookies. At this point, a year later, you now have so much code written based on this architecture, that even if you find ways around it, your code will still taste of the existing architecture. You can refactor all you want, but until you deliberately start a second branch of code that is an isolated and sterile environment, that only talks to the original code through very hard specified APIs - kind of a software firewall - you'll have that architecture still. Even if you rip out every single line of code that uses the original architecture, unless you effectively develop the new code in a vacuum, your code will still have that architecture embedded deep inside it.

People who have worked on large projects involving 3rd party code which doesn't work as advertized should recognise this one.

If you don't specify an architecture, you get one anyway.

It might not be the architecture you want, but it's certainly an architecture. The problem is that the code will generate structure as it goes, and that structure is architecture. It'll persist just as much as the original architecture, and all you can hope for is that this hackery wasn't part of your main code path. (Which means you might, just might, be able to snip it out).

Never write code ad hoc. Always at least spend a moment thinking about the architecture of the code you're writing. If you're dealing with 3rd party code, try to analyze the architecture of their system before committing your own code to it - misunderstanding their design is bad, as you'll end up creating incompatible architecture around it, and doubling your work - you'll have wrapper code which does more than it needs to, and then that'll spawn its own kind of architecture.

If you're dealing with 3rd party code which hasn't got any architecture, and was developed ad hoc, you're kind of screwed. It'll be difficult to get the architecture to sit in your brain.

Most software development - from a human perspective - is the building of abstract models of how something works. The easier this is for someone, the more easily used that code will be. If your architecture is clean, easy to understand, logical and consistent, it'll sit well in someone else's brain because the number of details they need to remember goes down rapidly. They don't have to remember all of the function names in your code, or all of the nitty gritty details. All they need to remember is roughly what shape that code has (its model), and how that relates to other similar code they've seen, and other design patterns they've experienced.

Take WxWindows. It shares a number of architectural similarities with ATL Windowing code, WTL, MFC and .NET Windows Forms. (Personally, I don't like working with it as much as any of the aforementioned libraries because of a variety of reasons, but that's besides the point). This means that anyone with experience in Win32 UI development should be able to very quickly pick up WxWindows programming. The models are the same - the architecture is similar. Basically, it's a message passing system, with event hooks, and some resource handling for the creation of controls. The function names may be different, and some of the implementation details may change, but for the most part it's an easily understood model - because it's a similar model to other environments.

Things that can make code easier to understand for other engineers tend to also be things that give a solid architectural base:

• Design your code first. Make a laundry list of the different things you're going to need to make your app, and figure out how you want to handle everything on that list. It should be as exhaustive as possible. You can always add later, but you want to be able to find any fundamental architectural pieces that you need to implement so that the rest of your code will use it consistently. You don't want any surprises.
• Try to write code from the top down. When writing any class, decide how you - as a programmer - would want to write code against that class. Write that code first. Then write the class to fit. Stub out functions if you need to (but make sure you mark them so that you know you need to finish them up).
• Write comments at the function and class level. These describe the model you're using, and separate out implementation specific details (eg. how exactly you write a serialization function) from the structure of the application (ie. the fact that it actually performs serialization in a standardized fashion).
• Once you've decided on a pattern for handling a scenario in your code, stick with it. Don't alternate patterns. For example, if you return error codes in one place, return them everywhere. Don't switch to exceptions somewhere else. If you need to use them, wrap them in a try catch at the lowest level you can, and return an error code as a result.
• Read as much code as you can. Try to find out what works well, and what doesn't. More importantly, try to understand if there was a good reason behind the way that code was written, or if it was created ad hoc.

In summary?

Other programmers aren't stupid. They tend to be smart, driven, passionate... and under tight deadlines. And the nasty side effect of tight deadlines is that architecture drops by the wayside. Try to keep your architecture as clean as you can, no matter what the deadline. The extra time you spend now will pay itself back later when you need to maintain or extend that code. And other developers who have to work on it will thank you for it.

What's more, if you have a clean architecture, it'll fit in your brain better, and you'll spend less effort. What's better than that?

Overheard in New York

There's a site out there - Overheard in New York - which collects things people overhear in passing. You know, random conversation snippets. (It has a few sister sites too - Overheard in the Office, Overheard at the Beach... and there's another unrelated one called InPassing). It's amazing what you pick up if you just keep your ears open. Here's a few of my recent faves.

Five-year-old: Daddy, I don't wanna see Spider-Man 3.
Dad: Come on, why not?
Five-year-old: I hate the black Spider-Man.
Hobo: That child is racist!

Old man: My psychiatrist told me two important things: one, never trust foreigners; two, don't ever waste an erection, even if you're alone.--Restroom, York Theater

During trailer for horror movie where young girl peeks in door of creepy house and says, 'Hello?'...
Thugette: Why they be goin' into some abandoned-ass house like that?
Thug: 'Cause they white.

Lady: I had the worst experience at that restaurant.
Friend: What did you have?
Lady: Horrible diarrhea.
Friend: I meant, what did you order?

Frat boy: ... And I don't really know what happened! All of a sudden I was in an orgy... And you know what? It wasn't even all that good.

Kindly gent: What do you want to be when you grow up?
Little kid: Retarded!
Kindly gent: Retarded?
Little kid: My grandpa is retarded, and he gets to play and watch TV all day!
Kindly gent: [Stunned silence.]
Kid's mom, embarrassed: He means 'retired.'
Little kid: Retarded! Retarded! Retarded! I wanna be retarded! [Starts to cry.]

There's sort of a game you can make out of this too. It's called Tomato Funeral.