Tuesday, November 13, 2007

Windows Error

I had used vncviewer to test things out on a shared windows box. I came back to my desk to find this beauty on the screen.

Sunday, November 11, 2007

IE6 Menu List Item Spacing Nightmare SOLVED (border-top)

So I was working on a new menu system for Dishola.com yesterday. Typically, I get everything looking great in Firefox, and then spot check in IE so that I can begin the torture.

And there it is, the well-documented IE6 LI spacing bug, staring me in the face.

Though, just recently I'd made up an example list item menu and it didn't have this problem, so I wondered WTF. I began researching and came across this gem of a solution (http://www.alistapart.com/articles/multicolumnlists) from A List Apart, and many other sites echoed this as the way to fix things. So I selected the text block and removed lines, and lo and behold, it works. But goddamn, why? And why was my simple example not exhibiting this behavior?

So I went, line by line, trying to figure out how to cause this bug. Trying to find the thing that would trigger the rendering problem. I was just sure it had to be some weird character my editor was inserting, or maybe when I saved the file, I was causing it unwittingly. But no, it all comes down to the fact that I was using border-top to try and get some nice bordering.

Here's the relevant CSS:
#navbar li ul li {
float: none;
border-top: 1px solid #ccc; /* BLIMEY, IT'S YOU - BASTARD! */

Simply changing that border-top to border-bottom, or removing it entirely, fixes the IE6 render issue. Not very intuitive eh? Try looking at this page in IE 6 and you'll see what I mean.

Good (no border-top)

Bad (w/ border-top)

Wednesday, November 7, 2007

Frameworks and Helpers

I've been recently refactoring and adding new features to Dishola.com and started off taking greater advantage of CakePHP's Form helper object. But here's the rub, and this applies to all framework objects, the more advantage you take of these things at the markup level, the less your presentation layer is separable from your controller logic. And of course, helper code generally has its own quirks for handling customizations that don't fit the mold, so now you're programming your presentation layer in another language other than markup. Sometimes you want a small bit of text after the label, sometimes after the input, so you tweak things in the helper code, but now you've got this spaghetti of stuff that's in some ways handy and also language-binding for your webapp.
I'm always pondering switching languages, or rather, the ability to. I don't want to be owned by my language or my framework. In theory, great full-stack framework webapps should be easily rewritten into one another without too much work at the controller(business logic) level. So why muck that up by leaning on your framework to help with your presentation? Sure it aids rapid development, but at the cost of making you your framework's bitch.