[wp-hackers] Theme development and hooks.
davebytes at comcast.net
Fri Apr 8 19:27:15 GMT 2005
> Just to point out a glitch in this thinking- You're saying that designers
> inherently use different layout styles in CSS, yet you think it's still
> possible to maintain compatibility between styles by providing a
> translation table from one name to another? Why not just standardize on a
> single set of names instead of complicating things with a translation
A 'translation table' may be minimizing the complexity of what I've been
discussing (and why I kept talking about functions). For MY use, I'm
thinking about 'how do plugins output HTML that looks the same as the rest
of the theme'.
> The *real* issue that will break this translation table idea is that
> designers can use additional/different tags to demark their content. A
> prime example of this is the post ID that is attached to posts. Logic
> would have the post ID for each post be written into the post <div>, but
> in the case of the themes packed with WordPress, they're in the post's
> <h3> title.
Actually, if you read back, I've been talking about this exact thing.
Frankly, I don't use h3's, if it's an archive list they are h2's, and if
it's a single-post page the title is an h1. But I totally agree: people
have different approaches to encapsulation: it isn't enough to know the
CLASS name, you have to know the tag(s) wrappering. At that point, having
"post_wrap_open" and "post_wrap_close" functions that output the proper
wrappering might help (this is why in the CG-PowerPack I have my 'sideblock'
functions, to abstract this very thing from implementation of plugins to the
output for a sidebar block styling...).
> Where this complicates things (and why it would even matter to plugin
> authors at all) is if you use these things as IDs for DOM, you have to
> apply it differently for different themes. On one hand (<h3>) you've got
> to use getElementById(postid).parentElement to get the post div, and on
> the other it's just getElementById(postid). Who knows what radical
> differences there could be in other layouts!
Again totally agreed. Are there a set of elements you might want access to,
and a method that'd provide you access by the theme providing the right
function? I don't know... you're moving into scripting, and I'm only (at
the moment) looking to OUTPUT something that looks like the theme. ;) But
good point to throw in!
> It seems necessary to me to first create a standard that delineates where
> a plugin can expect to find certain elements and what their names (ids)
> should be, then to create any needed translation services.
No argument -- I see the 'standard' and 'services' as one, but you can look
as it as two steps along the path.
> An alternative (and maybe this is what you're actually talking about)
> would be to include a table with every theme that describes how to find
> certain elements of the layout. The table would be indexed by an item
> like "The element containing the entire post, including the title" and
> would provide some method for divulging that tag id based on the current
> post id. It might work, but I think it's impractical, since publishing a
> standard would do essentially the same thing without forcing theme authors
> to go through the extra work of building a table for each theme.
Again, I agreed with the earlier post of it is impractical to expect every
theme author to match a given 'standard' encapsulation, tagging, class
nomenclature, etc. Don't get me wrong, I'd love it! But as I gave my own
site example above, some of us are concerned about things like SEO
optimization work, which requires using certain tags in certain places for
> Enjoying this discussion.
As am I! Glad there's some more going on, finally... ;)
So to step back, I guess the basic form I'm looking for is:
- how do I output something that goes in a sidebar/menu and looks right?
what is the title, what are subelements, etc. (and 'what' means 'what tag
- how do I output something that goes in a 'main content' area, that looks
like a 'post'? what is the title, what is any meta-data (timestamp or other
notation), what is the body of the post, etc.
Note that the 'post' theme info could be used to properly style customized
pages, such as an RSS feed page (which I've started shipping an example of
with CG-PowerPack), or a Contact Form page, etc.
This also hits the issues that Kubrick raised, which is using class tagging
on the id=content block to define a page meant to have a sidebar or not --
which in 'my world' I'd have done as a enclosing-DIV with id=nosidebar or
something like that.
More information about the wp-hackers