[wp-hackers] Theme development and hooks.

[David Chait]

> 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 
> table?

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 
best results.

> 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 
and class').
- 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.

-d