style resistance

Ye gods, Movable Type’s 3.2 style sheets are complicated. I’ve spent the last couple of days restyling my blog as part of a giant combo workover of everything that may eventually see the light of day — yes, I do have a development machine now, so I am not continually messing up the live blog. I have a design that I like now but its still built around the existing MT CSS and there’s like 800 lines of extraneous complex stuff in here that I don’t need. Plus: hardcoded widths and font sizes. ew.

I’m torn. On the one hand I could strip down the style sheets to about a quarter of what’s there and have much cleaner and simpler code that was easier to change and maintain, but then I’d end up forked from MT and I’d probably eventually have to come back and restart from the defaults again some time in the future (which is what I’m doing now after taking that step with my initial MT 2.x install).

On the other hand, the CSS people at MT actually know what they are doing. I know CSS reasonably well at this point, but I am not up on the multitude of cross-browser hacks and workarounds so I’m opening myself up to lots of bugs and issues and worry down the line. If I stuck with the existing style sheets I could have some confidence of not having to deal with that and, more importantly, I could just go on with my life.

I think I’ll have a couple cups of coffee and think about it. (it’ll take less time if I’m caffeinated).

Update: I know you’ve been anxiously awaiting my decision. I merged and cut everything down. Yes, its true: I am forked.

4 thoughts on “style resistance

  1. I don’t think the MT styles are coded all that well. They look nice, but they do hardcode widths in pixels, most of the classes are generic, and the base style isn’t all that readable. They mix using classes and ids to identify styles with little logic for the choices. The 3.0 style is certainly cleaner than the 2.x style, but it’s still a jumble. Forking shouldn’t be a problem, you already have your own non-MT layout that you want to maintain.

    Now…about your use of typekey (you can sign in, but the comment form seems to be the old 2.x comment form?

  2. I am thinking about playing with MT 3.2 this weekend. I don’t know squat about CSS except the minor tweaks. The install is supposed to be improved with 3.2, did you find this to be the case?

  3. >Now…about your use of typekey (you can sign in, but the comment form seems to be the old 2.x comment form?

    Oh, bah. That must have happened when I upgraded to 3.x from 2.x and tried to back fill all the old templates. I messed up along the way. With 3.2 I’m tossing out everything from the old install — including the layout — so it’ll flush all that old grunge.

  4. The MT 3.2 install is, theoretically, easier than 3.x. Upload the files, make a few minor edits to the config file and load up the mt.cgi URL. It figures out if you’re running it for the first time and does all the DB configuration, etc, itself.

    However, I think its tough for them to write an install that takes into account every single possible configuration of Apache/MySQL/blah blah blah. And some of them break. The problem is that when the MT one-button install breaks, it simply hangs with no error or indication of what went wrong. There’s just nothing there.

    In my case I had a vanilla linux box with a totally out of the box Apache and MySQL install. I followed the MT instructions…but there was one section where a step (moving the mt-static directory outside of cgi-bin) was “recommended.” It turned out that this step was required in my configuration. My install went kablooey.

    I spent a number of hours trying to track this down. There were lots of people in the MT forums who seemed to be having the identical problem, but there was no solution. I finally figured it out because there was an MT knowledge base article that mentioned it. The information in the KB article conflicted with the docs and was not easy to find on the MT web site.

    I wrote all this up on the MT forums. I also filed a bug against the documentation for excessive vagueness, but I was told that the documentation was correct. I wrote up a big long rant about how technically correct is not the end point for good documentation; if docs are incomplete and confusing for some significant portion of the audience then that can be worse than no docs at all in terms of support nightmares and damage to company reputation. But I deleted that rant unsent. I don’t think they’re interested.

    I was pretty irritated by the whole experience, actually. Not so much by the error itself — things happen — but by the lack of support, poor documentation, and then stonewalling by MT support when I figured it out and tried to actually help.

Comments are closed.