[wp-hackers] WP Theme Directory Submission Restrictions

Ptah Dunbar pt at ptahd.com
Mon Oct 6 16:18:51 GMT 2008

WP 2.7 introduces better support for child themes so I started developing a
theme framework per say, to serve as the parent theme for all my future
theme releases (which I'm also gpling for others to benefit from). I'm sure
you heard all about child theme benefits I don't to go into that here...

Enter WP Framework <http://code.google.com/p/wpframework/>, a powerful theme
framework that empowers theme authors to create solid, functional WordPress
themes faster than ever!

Let's take a peak at the styles.css:

/* Reset Browser Defaults (css/reset.css) */
@import url(css/reset.css);

/* Base Stylesheet (css/base.css) */
@import url(css/base.css);

/* Site Specific Styles - (css/screen.css) */
@import url(css/screen.css);

/* That's all folks! */
All standards complaint browsers support the @import
rule.<http://webdesign.about.com/cs/css/qt/tipcssatimport.htm> No
hacks involved.

Alignment/caption css classes are clearly declared in the

This method of including the css is widely used by many wordpress themes,
adopted from many advocators in the web standards world.
In fact, I just attended a talk at Web Master Jam Session 08 where Jina
Bolton, a highly respected css designer discuss this.
BluePrint CSS Framework and many other css frameworks promote this.
At WordCamp Utah, Alex King just introduced his theme framework to the
world, Carrington.

Lets check out the styles.css:

@import url(css/carrington-blog.css);

I could go on. It's not about creativity, it's about given structure and
organization to your code. Some people might only need a reset, or a
sensible typography base, or whatever. How would they go about doing this
without including everything else using the
one-css-file-put-everything-in-here method?

Themes are getting much more advanced (which is a good thing) and so our
stylesheets play a much more important role than ever.

Ptah Dunbar — Web Developer

On Mon, Oct 6, 2008 at 11:17 AM, Otto <otto at ottodestruct.com> wrote:

> On Mon, Oct 6, 2008 at 9:58 AM, Joost de Valk <joost at joostdevalk.nl>
> wrote:
> > Otto,
> >
> > While I agree with most of what you're saying, I don't think it's wise to
> > set that all in stone, restrictions aren't the best thing to boost
> > creativity :-)
> Some kinds of creativity should be suppressed. I don't want my
> mechanic getting all creative when fixing my car engine, nor do I want
> my plumber getting creative while running my shower lines... And I
> don't want my WordPress themes to be all creative about where the
> styles go.
> I mean, you must have a style.css file, in much the same way that
> WordPress requires specific naming for many other files. Does that
> also suppress creativity?
> I ask somebody, anybody, to present a valid use case for not having
> these mandatory styles (and they ARE mandatory, in the sense that your
> theme is broken in 2.5 and up if you don't have them) in the style.css
> file. There's only about 8 of them, you could stick them at the end of
> the style.css file, after your @import lines (which are also, in
> themselves, evil) if you wanted to. Why keep them separate? What,
> exactly, is the advantage to that? If your theme is worth it's salt,
> then those styles are different for each theme anyway, so there's not
> going to be a whole lot of code reuse going on.
> Which is true in general, really. CSS doesn't see a lot of code reuse
> if you're doing it properly. The whole point of moving styling out
> into the CSS is that the HTML becomes semantic. You're not supposed to
> use "alignright" and "centered" classes in HTML, really, because
> you're supposed to define things as what they actually are (post,
> title, etc), and let the CSS handle the styling. The only reason we're
> using these non-semantic classes in WordPress is that we have to
> signal the theme what the users selection was from the editor, in
> order to let the theme handle the styling correctly, and these are
> easy to understand and deal with.
> So if you're defining things semantically in your own themes, there's
> not going to be a heck of a lot of code reuse. And if you're using
> tricks and hacks for CSS on a regular basis, then you're doing it
> wrong anyway, no?
> That's just my opinion, of course. Sorry for the mini-rant. :)
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list