However, I think you’ll also agree that lists do imply some kind of relationship between its items, and with widgets there is none.

Re: function_exists: I think of it as a ‘goto-like’ solution because if you have the same function defined by a user after the initial function_exists call, it will call the original. In other words — the output of function_exists depends on the order of the code.

Regarding the rest — I agree that there is no single argument for either of the approaches and therefore both are in a way viable.

Doctype: HTML5 is the way of the future, so using that doctype is just fine. But the use of elements such as header and such, which are not well supported by current browsers, makes little sense. The idea that you have to go whole-hog-or-none is flawed. It’s perfectly valid to use an HTML5 doctype without using every possible HTML5 element.

Lists: Think again, List Items (LI) can indeed contain block-level elements just fine. I think you need to brush up on the HTML specs.

function_exists: No, it’s not a goto solution, it’s a standard php programming technique for making functions that can be overridden. WordPress calls them “pluggable” functions.

Comments: The most important part of a comment is the name and email address. Not the comment. I don’t understand why anybody would think different. Comments are part of a conversation, and the first part of having a conversation is knowing who you are talking to and how to reply to them.

And really don’t like themes that got a mangled title tag. Sometimes you can’t even override the default title with a plugin.

HTML5: Why use it at all?

div: Agree. The most important headline should be h1 and that is never the homepage name except for on the front page some times.

widgets list: Its very ugly to use lists that way. List are to display text I think. like grocery list. But list items can contain block elements. Check the standards both 3.2 and 4.01 say they can contain block.

function_exists: I agree. WP has hooks for a reason. They are there to make it easy to override.

Re: header background. I agree that inline CSS is not the best solution, but it certainly the easiest of the semantic ones. WordPress doesn’t have a built-in mechanism for generating and caching dynamic stylesheets which would be ideal for this kind of a theme feature.

Re: widgets & lists. There is a better solution and it doesn’t include unordered lists. Just choose anything else and it’ll be better than lists ;)

Re: title filter. That would be another way of doing it, although I think it’s already way too much of a PHP & HTML soup in one boul. And that big ass functions.php file is also a problem which should be addressed.

Re: HTML5. So you think it would be better to specify another doctype?

Re: p vs. div. I think h1 and h2 should never be used for site title and description (the only exception could be the front page, although I don’t see enough semantic reasoning for that either).

Re: Widgets as lists. We’ll have to disagree on this one. I really don’t see how widgets that are in no way related to each other must be linked together in a list. In addition, no block elements are allowed inside list-item (which is neither an inline nor a block type element).

Re: function_exists. To me this sounds like a goto solution to a bigger problem.

Re: comment input field order. I prefer to put the most important stuff first and I don’t understand why others do it the other way around. However, you raise an even more important problem with comment input validation — that blank page with “Please fill in all required fields” and the need for back button is a huge usability issue.

Again, thanks for your comment.

If we are not using any of the HTML5 than it doesn’t make sense to specify an HTML5 doctype.

There is no such thing as an HTML5 doctype. It’s just a blank doctype.

An IMG tag certainly isn’t sensible for the header, although an inline styling on a DIV tag is also a bit nasty, so unless dynamically modifies the CSS you are always going to get nasty code for a changeable header image.

Otto is correct that lists can most definitely be block elements, and in fact they are block by default. I see no reason why they need to be an unordered list though and many markup specialists find it a bit hacky to even refer to them as lists at all. The late Dan Schulz who was probably the leading expert on WordPress markup until his death not long ago, often complained about the shonky list markup used in sidebars and comments areas in popular themes. There’s plenty of others who feel differently though. I think the problem there is that there is currently no good option, and so there are a combination of different ways that things could be done.

1. Adding filter functions for front page display to the functions.php file is the wrong way to do it. That function and filter should be in the header.php file. Why? Because functions.php is loaded on every page load, even admin page loads. A function should be close to where it is used, and not loaded when it’s not used. To that end, putting the code that generates the header into the header makes the most sense, is the fastest, and makes it easy to find things. If somebody wants to change the title, then making them search through a big ass functions.php instead of simply looking in the header.php is stupid.

2. HTML 5 elements = I agree. However, IE doesn’t cope too well with them. Yes, you can use the HTML5 shiv from Google and the IE8.js to make things work (see http://www.smashingmagazine.co.....m-scratch/ ), but why go to all that trouble? We can move to real HTML 5 when IE catches up. In the meantime, this works fine.

3. P vs. DIV – This is questionable. Actually, I’d say that they should be in H1 and H2, respectively. Post titles and such should be H3 and below.

4. Actually, Lists are the *only* correct way to build sidebars. Anybody doing it any other way is wrong. Furthermore, Lists are not inline. UL, OL, and DL, are all block-level elements.

5. All the function_exists bits are there to allow child themes to override those functions by simply redefining them, if necessary. This is not a valid critique in any way.

6. I agree with both mobile stylesheet and not using px values. In practice, the px thing isn’t going away, too many theme designers are overly sensitive about this one.

7. I don’t understand the Comment input fields thing. Fields should be before the comment block, not after. If they’re after, then it’s more likely that a user will submit a comment without a name on it, and the comment will be lost. He’s got his UI design ideas totally reversed here. Your comment form is confusing, in fact, because it’s asking for data not only after the fact, but in a different order from every other site on the internet. You need to standardize, man.

<div id="header" style="background-image:url(...)"></div>

would be better than <img>.