Ian Stewart at Themeshaper is asking the question, how should the default theme in WordPress change?. It is clear that Kubrick just aint gonna cut it any more, this is true as much for its ubiquity as it is for the style and features it contains; but what comes next?
Theming has moved on a great deal since Kubrick became the default, so what is it that a default theme needs in the 2.5 era?
The key problem with Kubrick is that, despite the configurable options, Kubrick always looks like Kubrick. That is requirement number one: You must be able to change it sufficiently for it not to look like the default theme.
The theme should come with a set number of pre-defined layouts using accepted CSS techniques. These themes don’t need to be amazing, just variable enough to allow individuality.
This shouldn’t be too difficult.
Minimal processing
Speed should be a priority. This is going to be the storefront for WordPress so it needs to be as fast as possible while achieving the aims. This means as little extra processing as possible.
I have no problem with extra content and layout processing, my own theme features it up the wazoo, but the default needs to make WordPress shine so the less that can go into functions.php the better, and the more files that can be changed once and cached till the next change the better.
Simple HTML
This is the theme that people will learn from. The HTML should be clean, straightforward, and semantic. The HTML should not rely on any processing as this will make it harder to follow.
If at all possible the html should be a container for the standard theme tags. This means not using PHP for classes or IDs unless it is absolutely necessary.
Fully configurable
There should be no changes necessary that cannot be accomplished through the admin panel. Inevitably there will be some that cannot be forseen or are edge cases, but in general, the aim should be that the underlying HTML and CSS is never touched.
We need widgetised sidebars that collapse if there are no widgets included, on both the left and right of the content. We need menus that appear only when there are links in appropriate bookmark / blogroll categories. We need colour changes, transparent gradient overlays, alterable header images and admin pages to change typefaces, colours, line-heights etc. All thing that are relatively easy to achieve, with a little work.
Ian has suggested The Sandbox. He has hopes of CSS only themes, I personally don’t agree; The Sandbox theme doesn’t meet my requirements.
The Idea of one underlying HTML structure to rule them all is not a bad idea, but I don’t think it is appropriate for the default theme. It isn’t something that I would ever use, or design for, because I see HTML as part of the art.
When it comes to HTML, less is more. I think a default theme should follow best practice, because we need to instill best practice in the next generation of themers who are only now starting to learn.
Ian’s suggestion, while interesting, seems to be a suggestion for a replacement theme system as much as a default theme. WordPress has a theme system, a good and flexible one, and I think it would be wise to avoid creating a two tiered theme system by default.
The default needs to be written specifically for that purpose. It should feature a finite set of requirements to do the job that the default needs to do. It should not try to compete for any other position and should not aim to be the theme to end all themes.
Things will be a little quiet here this week. I am working to get my theme finished off but also have some other, non-WordPress-related stuff to do so I probably won’t get time to post. To bide over the time here are a few questions I have been mulling over for a few days.
Time limited content
Over at Reader Appreciation Project a little while back I posted about weekend blogging. About the fact that I don’t but am disappointed when others do.
That sparked a discussion about how to educate readers to expect content on the weekends and time limited content is something that has since occurred to me as a way to do that.
Here’s the idea:
A post is published. Unlike regular posts the feed contains only a brief introduction and a statement that the post will be available to read for 24 hours.
If you click through and read it within those 24 hours you get to read the post, and you get a cookie which means that you can keep viewing it. So any conversations in the comments can keep going.
If you click through outside of 24 hours the post content is not available to you. You can register to get it when it is released, which could be in a week, (presumably the e-mail notification will also arrive on a Saturday), but you can’t view until then.
My question to readers here is: would this just piss you off? or would you get it and run with it? would it make you unsubscribe?
Plugin Architecture
The second question relates to my Fun with WordPress Plugins tool.
I have in mind a major overhaul for the next version, lots of UI changes, much more integration with filters and actions; however, there is one thing I have in mind for the actual back end code, but I am not sure if there is a demand for it.
I have it in mind to develop some objects for widgets, admin pages, and possible even actions and filters and keep these outside the main plugin class. The idea would be that these would function as a limited form of MVC, with each object including pages in specific foldersl; for example:
Your plugin creates a new admin page object, sets the parent, and registers it. It looks for a specified file within the html folder to get the content of the page, and within the code folder to get the processing instructions.
This invariably makes the plugin more complex, possibly even more complicated, but I like the idea of keeping the plugin itself as empty as possible.
My question on this is, what do you think? good? bad? do you have a better solution? Do you think there is a best practice for WordPress plugin architecture irrespective of its function?
I appreciate any comments you have on any points.
P.s. I am also on Twitter now.
This is the ninth post in my series, Themery : Blogged, where I blog about each step of a WordPress theme design.
This theme, as I explained in previous posts, is elastic, meaning that as you increase the text size, the rest of the site scales up accordingly. The problem with this is images, when images scale up on a webpage all kinds of evil ensues and so it can’t really be done. This is my solution.
I will start with some screenshots to demonstrate the end result, then explain what I have done. They aren’t small but I wanted to get across the scale of the problem.
This is the same page at the original font size, and several sizes larger. The bottom image is simply styled with a width in EMs, the image above uses my technique.
Now, before I explain what I have done I wanted to temper expectations a little. This isn’t the grand solution to all image sizing, you might even consider it a slightly hacky solution to the problem, but it does work.
The short version is simply that the top image is actually 5 images, each at intermediate steps, 150px, 180px, 225px. 300px. and finally 450px. Using a div and absolute positioning each image comes into view as the appropriately sized text is selected.
The CSS is split between the stylesheet and inline styles. If you know what sizes your images will be before hand there is no reason why it can’t all be in the stylesheet.
The stylsheet contains two rules:
div.multiimage
{
overflow:hidden;
position:relative;
}
div.multiimage div.subimage
{
margin-top:-1000em;
position:absolute;
}
And the html looks like this:
<!-- The Wrapper -->
<div class="multiimage" style="width:15em; height:10em;">
<!-- The original Image -->
<img src="http://localhost:8080/wp-content/uploads/2008/03/11.jpg" alt="Williams Formula 1 Car" />
<!-- Larger Image 1 -->
<div class="subimage" style="width:18em; height:18em; top:12000px; background-image:url(http://localhost:8080/wp-content/uploads/2008/03/21.jpg);"></div>
<!-- Larger Image 2 -->
<div class="subimage" style="width:22.5em; height:22.5em; top:15000px; background-image:url(http://localhost:8080/wp-content/uploads/2008/03/31.jpg);"></div>
<!-- Larger Image 3 -->
<div class="subimage" style="width:30em; height:30em; top:20000px; background-image:url(http://localhost:8080/wp-content/uploads/2008/03/4.jpg);"></div>
<!-- Larger Image 4 -->
<div class="subimage" style="width:45em; height:45em; top:30000px; background-image:url(http://localhost:8080/wp-content/uploads/2008/03/5.jpg);"></div>
</div>
As the text is resized the negative margin (-1000em) of the larger images increases until it reaches a measure equal to the absolute position top, which is 1000 times the size that the base font (the font that applies to the body) will be when we want that image displayed, but in pixels so that it doesn’t change when the font is resized.
In this example the base font size, or 1em, is equal to 10px. So for the first larger image is positioned 12000 pixels from the top. When the font is increased to 1.2 the negative margin then equals 1000 times, i.e. -12000 and the image is displayed.
I have used div tags with backgrounds instead of images so that screenreaders do not end up listing image after image, this after all purely visual.
Disclaimer: As Safari won’t run on my computer I don’t know how it deals with resizing. Firefox on Windows resizes text as:1 , 1.2 , 1.5 , 2 , 3 and it is this I have based this on. Both Opera and IE zoom instead of resizing and so the technique is never used. If someone does try it on a Mac please report back.
Writing can be difficult when you are talking about subjective topics, matters of style or taste, or even just good practice, so it is no surprise that from time to time someone takes what you have to say the wrong way.
What do you do then when you write something and realise when you read it back later on that you have just criticised something that a reader does, even though it wasn’t meant to apply to them?
Read the rest at http://www.raproject.com/articles/have-i-offended-you/