Generated Semantic Classes

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…

What’s more, this makes your semantic data accessible to javascript. You could use the classnames to place relevant ads in posts, collapse posts of a certain category according to the visitor’s cookies, attach category-targeted link submission buttons…

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.

PHP Object Hierarchies

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

Recent Misperceptions

Maybe they read it somewhere else. Maybe they thought AJAX and Javascript were synonymous. Maybe they are hell-bent for dev leather. Whatever the cause, people are saying you need to know AJAX to make widgets.

AJAX plays no part in WordPress widgets. We use Javascript to create the drag-and-drop environment, that's all. To qualify as AJAX, an app would use Asynchronous XMLHTTPRequests to exhange data with the server without reloading the page.

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)

Javascript Drag and Drop Toolkits

The new WordPress Widgets use a javascript toolkit to create the drag and drop interface. There are several excellent kits available that provide lovely drag and drop functionality to ease the job of writing rich web interfaces. I spent a good portion of last Thursday looking them over to find one to use in the Widgets. Here I write my conclusions about two of them in the hopes that someone will take the best parts of each one and construct the perfect drag and drop script.

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.

Thomas FuchsScriptaculous, which name would probably never have occurred had God not invented the .us top-level domain, is a lovely set of scripts indeed. The demos are nice but the promise of a documentation wiki was not met by any obvious linkage to said wiki. Configuration was therefore accomplished by mimicking the demos. When I wanted to customize the UI to show a message in any empty columns, I found the exact interfaces I needed after a quick look at the well-organized code. The limitation I found with the Scriptaculous drag and drop tool is that it is not natively accessible via keyboard. I’ll have to add my own list manipulation controls to make the interface work without a mouse or without javascript.

The perfect toolkit have dbx’s keyboard accessibility and ability to be used without javascript, all while providing the multi-column sorting and powerful API of Scriptaculous. Is somebody already working on this?