Managed to clear most of the table cruft out of 1.5, only the content component to go. That one will be non-trivial but possible, nonetheless. I’ve been wrestling with a view other ideas along the way.

The first is a question born out of frustration: Why do I have to do this? The Joomla developers built in a way to remove tables from some of the pieces, and then created an override capability so someone like me can do the rest without having to hack the core. OK, but since they clearly know this is desirable (this is derived from the fact that most of the pieces have a simple argument on the load call to eliminate the tables) why haven’t they gone whole hog with it, and provided that capability built-in, rather that force me to provide it myself?

The second is more personal: Since I’m having to override so much of Joomla’s output, anyway, how much do I want to stay with their classes (“contentpaneopen”, “contentpaneheader”, etc.) rather than restructure the output completely into something that makes more semantic sense? Lots of work, yes, but then I get output that I can feel better about signing my name to. I haven’t decided yet if the effort is worth the reward.

The way I see it, the issues are:

• Makes it harder to use other people’s theme’s / stylesheets. No issue for themes, since the overrides are part of my own theme. Likelihood of my wanting to use someone else’s stylesheet unmodified is close to nil, so no issue there, either.
• Have to modify every module to conform to my sheet, not the Joomla one. Again, limited impact. I have to modify a lot of the modules’ output anyway, just to get rid of other bits and pieces of code that offend me. Don’t need to do this for everything, only the bits I’m using.
• Have to create a new CSS framework. I do web development outside of Joomla as well, so I already have one that works for me. Might need to adapt it slightly, but that’s all.

So that leaves me with a trade-off: the effort of tracking down all those references in the code and converting them against some personal satisfaction. I’m not so sure it’s worth it to do that exhaustively. I know I’ll probably modify some of those tags simply because the Joomla developers didn’t (in my opinion) give the document structure elements the correct tag, syntactically. But tracking down all of them might be a bit much, given the payback is simply my own satisfaction. (Meaning, I can successfully implement the design with a class applied to a paragraph tag as easily as if it’s applied to a header tag, and the fact that I find the default class names cumbersome has little or no technical merit to it.)

The third idea is a renewed determination that Joomla’s dependence upon menu itemid’s is eeeeeviiillllll. I’m hearing noises that this dependence is loosening (Look Ma, no Itemid’s in the developer’s blog) but I haven’t seen any evidence of it. In a brief test, in fact, I’ve created what I think is the best argument to dispense with them. In my sandbox domain I created a default Joomla 1.5 install and put one menu on the left and another at the bottom of the page. (A reasonable approach that keeps navigation close at hand no matter where the visitor is on the page, and it’s quite common for complex sites.) The links to “home” on each menu are different, and they are both different from the one you get when you simply enter the sandbox domain in the browser’s address line. Further, if you want to have the menu choice reflecting the current page highlighted in any way, a different menu choice will be highlighted as “current” depending on how you got to the page.

Yes, I can see utility to this approach, but the default is the wrong way: Surely it’s more common to want the same URL for the same page than to want different ones? The default should always favor the more likely choice, in this case, the default should be for the same page to have the same URL. Since, however, itemid’s are woven so tightly into the fabric of Joomla, I don’t have any hope they’ll be gone anytime soon. If I end up dropping Joomla, you can bet itemid’s will be a significant part of the reason.