misty eyed

with two themes in as many days, wp.com managed to grab a theme from a long-standing member of the wordpress theme community. i’m impressed, that’s getting to be a rare thing. i think i might have actually sent in feedback asking for mistylook. or at least thought about it really hard. (this would be before i bought my CSS upgrade).

Being designed by Sadish means that it has things like archives/links templates, and the oft-requested contact form. The original also supports asides and re-ordering the page link, and dropping pages from the nav bar:


of course, options panels are stripped from wp.com themes, for the crime of not sanitizing values (sensible for text fields, less so for ticky boxes and drop down menus), but rather than sanitizing the values, the options panel, with its oft requested features, is dropped entirely. [snark removed, real reason in the first comment]

so we’re left with fauna as the only theme that supports asides (because it does so without an options panel, kudos to joen). of course, it’s an aged version that doesn’t support sidebar asides, which are the only kind that can’t be achieved with sandbox and a CSS upgrade. i recognize that i’m in the minority when it comes to wanting asides, but that doesn’t stop the contradictory nature ‘designing themes for wp.com‘ process from really annoying me.

it’s just so very anti-open-source. users ask for a feature, someone gives it to them, and the benevolent dictator takes it away. mind you, i’m still confused as to how the benevolent dictator model can possibly nurture a meshwork and not turn it into a hierarchy, but i think that comes from reading ‘a thousand years of non-linear history’, rather than ‘the cathedral and the bazaar’. i’d link you to those books, but linking to amazon is forbidden.

now I’m really far afield. misty look is a great theme. kudos to Sadish.


5 thoughts on “misty eyed

  1. Matt

    Because introducing features like asides in only some of the themes is far more annoying. Themes should be design decisions, not functionality decisions. When/if we officially do asides, it’ll be in all themes equally, and far easier than using a different interface for every single theme to configure it.

  2. adam Post author

    there’s a logistic headache i can’t get my head all the way around. that means using your <ul> method for every theme then, since not all themes have styling for asides? or just adding the equivalent of andy’s CSS to the code for every theme?

    i suppose in that light, sidebar asides would be easier.

    nonetheless, i have to agree about themes as design decisions. although i still think that the skins/mods distinction makes way more sense than including all that PHP for a design decision.

  3. timethief

    From my viewpoint if a theme doesn’t function as I want it to then whatever its design may be – I’m not going to use it. That’s why I don’t understand what Matt said:

    Themes should be design decisions, not functionality decisions.

    Presumably Andy’s bit of code will one day be added to all the themes and we’ll have asides. I’m wondering if that event will follow or precede the event of equipping all themes with widgets.

    I immediately switched two of my blogs to the Misty Look theme. I now have contact pages and fonts of a readable size as well as a clean looking theme I can easily create headers for. YAY! 🙂

  4. adam Post author

    @ root-
    i think that’s what matt’s getting at. i like using asides, and that preference shouldn’t predicate, or impinge upon, my design/aesthetic choices.
    @ tt-
    again, i think this is what matt’s suggesting, despite it being contradicted by the majority of the themes installed here. the process of editting/installing/normalizing wp.com themes is supposed to bring them up to a baseline standard of functionality. most of the older themes don’t meet this baseline, which is probably due to the limited number of staff focusing their efforts on new themes.

Comments are closed.