I’ve been working with Scott Allan Wallick on a WordPress theme he calls Minimalist Sandbox. One of the things we’re trying to do is create a rich semantic markup pattern that will make it easier to customize the blog with CSS alone.
For example, take the <body> tag. We know whether is_home or is_post or is_page by the time we render this tag, so why not drop some of this context into the body’s class? The distinction between “home” and “post” and “page” is simple and powerful. It utterly destroys the old widecolumn/narrowcolumn classes. A full-blown class list such as “wordpress author archive author-andy” also gives each author the ability to style their archives differently with just a bit of CSS.
We can do similar things to the post div class list: “post publish author-andy category-asides category-funny” gives you tremendous power to shape your blog’s presentation with CSS. You could have a different style for certain categories or authors, attach a headshot to each of an author’s posts, use :before selectors to congratulate visitors on their wise choice of browsers…
There are all manner of tricks you can play when you have the right information in the right place. If you think of any other information that could enhance the semantic value of a theme’s markup, drop a note right here.
Ever since I wrote the first draft of the Widgets plugin, I've had a fetish for structuring data as object hierarchies in PHP. There is so much you can do with such tiny snippets of code, why wouldn't you want to represent things that way? Some minds call it "too complicated" while others, like mine, consider it the peak of simplicity. Continue reading PHP Object Hierarchies
I've written AJAX apps and even an AJAX theme for WordPress (not that it was great or anything–it wasn't) and I decided Widgets would be better off without it. So Widgets uses good old HTML forms.
That doesn't mean some brilliant widget developer can't put a slick AJAX interface into a widget or its configuration module.
And finally, where did anybody get the idea WordPress 2.x will drop support for 1.5 themes? It won't. We're expanding the theme system and making it more powerful but we're maintaining compatibility with WordPress 1.5 themes.
That doesn't mean all 1.5 themes will always work. Some advanced themes "break the rules" by accessing the database directly or otherwise bypassing API. Those themes will almost certainly break. That's the price you pay for developing a theme beyond the capabilities of the API and not submitting a request for API improvements. (the bugtracker)
James Edwards a.k.a. Brothercake‘s Docking boxes (dbx) is already included in WordPress; it powers the draggable boxes in the writing interface. With dbx, you can take semantic, structural markup and make it work well and look sharp prior to adding scripted behaviors, then use
id attributes and some external scripts to upgrade it into a beautiful and highly usable interface. What I find most impressive about this script is that the interface is 100% accessible via keyboard. If you don’t appreciate the full value of keyboard accessibility, go and break your wrists snowboarding and try to use your browser. If your insurance or your stomach won’t allow such drastic action, at least unplug your mouse until you appreciate it. The downside to dbx, and the only reason I couldn’t use it for this project, is that it doesn’t permit dragging items between different columnar lists.