I'm finally getting comfortable with CSS. 

And not just to use it to style an individual site. I have to make CSS work in a templating language for the work I'm doing. 

I owe a tremendous debt of gratitude to two guys at Twitter for blazing the trail with the Bootstrap toolkit. It's a library of solved CSS problems. You have to puzzle them out, but it's not impossible, though it is difficult at times. But that's not their fault, because CSS can be dauntingly complex for newbies.  

Once you work your way through the complexity, and I know I have now because most of the things I try now work (wasn't always that way), a picture emerges of a tradeoff that was made that I'm not sure the designers who invented it knew about. 

Let me explain. 

They say the great thing about CSS is that it separates content from its appearance. I agree that this is great. I've been using a template language for my websites going back to before there was a web. This is one of the things Chris Gulker showed me about the work he was doing at the SF Examiner in the early 90s, to automate the prepress operation. The same ideas translated easily to the web. And they made things like blogging possible.  

However when you delay rendering to the browser, you end up splitting the content in two. That's fine if you're working on a single site, and not trying to create utilities that work in a lot of different contexts. For example, suppose you wanted to create a library that handled drawing and interacting with menus. If you weren't using CSS, you'd just return a package of HTML, it would be dropped into the page, and that's that. However, with CSS, you also have to arrange for the style information to show up, in an entirely different place. That's the complexity that CSS adds.  

That's why it's taken me most of a year to figure out how to make this work. In the end I did figure it out. It's still fragile and adds unnecessary complexity. And the fear I have is that all this will be reorganized yet again, and we have to go through this unnecessary exercise again. 

I also note that we had the things that Bootstrap solves, 25 years ago, and the solution then was better and easier. More powerful. More leverage for the programmer. More complexity hidden behind the APIs. When I read a piece by Paul Krugman wondering if economists of the 1970s knew more than those working today, I said the same question must be asked about software developers. It seems to me we had it all working better before we switched to the web. We probalby never should have tried to make the web a GUI. But there you have it. (And if Microsoft, Apple and Sun hadn't been such BigCo's it might have happened.) 

That's why Bootstrap makes a difference. It encapsulates in one place all the design assumptions. I don't want to have control over how the menus look. I learned that when I started making Mac software. It's a good thing if all menus work the same way. So if Bootstrap is a good thing, how much more can we simplify things by factoring out the look and feel and burying it even deeper and further away from the program logic? There's the answer. It belongs in the browser itself. There ought to be the idea of menus in the language that goes over the wire and is rendered in machine language by the browser. And all menus should work exactly the same way, whether you're in Twitter, WordPress, YouTube, Tumblr or on JetBlue's website or whitehouse.gov. This is not a new idea. This is the idea of the Macintosh in 1984.  

Another hit of the ping pong ball across the net to my buddy Joe (and maybe Nik Cubrilovic too, who picked up the ball on the Facebook story last weekend, and did great things with it). 

PS: Is there a blog for news of Bootstrap? I don't want to join a mail list, I am just a user. But I'd love to follow a feed. (I see they have a feed for commits, but what I want is something more like my worknotes.)