The usual code for a widget-enabled sidebar goes like this:
<div id="sidebar">
<ul>
<li id="pages" class="widget widget_pages">
<h2 class="widgettitle">Pages</h2>
<ul>
<li class="page_item page-item-2"><a href="http://url/?page_id=2" title="About">About</a></li>
<li class="page_item page-item-2"><a href="http://url/?page_id=2" title="About">Contact</a></li>
</ul>
</li>
<li id="categories-1" class="widget widget_categories">
<h2 class="widgettitle">Categories</h2>
<ul>
<li class="cat-item cat-item-3"><a href="http://url/?cat=3" title="View all posts filed under Asides">Asides</a></li>
<li class="cat-item cat-item-1"><a href="http://url/?cat=1" title="View all posts filed under Uncategorized">Uncategorized</a></li>
</ul>
</li>
</ul>
</div>
This is where I begin to wonder. Why do widgets go into an unordered list? Semantically, it’s possible to argue that the sidebar is actually a list of widgets, therefore the usage of the <ul> tag. But with that same logic, the content area of a blog is basically just a list of posts. Yet I never found any theme placing each post inside an <li> tag. Have you?
This is what Automattic has to say on this, emphasis mine:
Notice that the entire sidebar is an unordered list and the titles are in <h2> tags. Not every theme is built this way and it’s not necessary to do so, but it’s currently the most common sidebar markup in the themes we surveyed so we adopted it. The element with id=”links” is the equivalent of one basic widget.
So, I assume that this practice date back before WP Widgets is created, and is simply picked for compatibility reasons (so that it’s easy to convert already-made themes to be widget-ready). But that does not mean it is still necessary for new themes, I believe.
If you take a look at some of the more well-known web designers’ code, you’ll see that they don’t do this on their sidebar. While none of these examples actually used WordPress widget on their site, but does that matter? Widgets or plain old hardcoded PHP, we’re simply talking about items (or sections, contents) on the sidebar, right?
The last thing that also bothered me is that the usual code above looked so cluttered. Tag soup, anyone? Nested <ul>’s and everything. They’re actually quite difficult to follow, and I don’t see a reason why something simpler can’t be achieved yet still be semantically okay. Something like this, for instance:
<div id="sidebar">
<div id="pages" class="widget widget_pages">
<h2 class="widgettitle">Pages</h2>
<ul>
<li class="page_item page-item-2"><a href="http://url/?page_id=2" title="About">About</a></li>
</ul>
</div>
<div id="categories-1" class="widget widget_categories">
<h2 class="widgettitle">Categories</h2>
<ul>
<li class="cat-item cat-item-3"><a href="http://url/?cat=3" title="View all posts filed under Asides">Asides</a></li>
<li class="cat-item cat-item-1"><a href="http://url/?cat=1" title="View all posts filed under Uncategorized">Uncategorized</a></li>
</ul>
</div>
</div>
Mm. Tasty.
And So We Bump into Troubles…
By default, the value for the function register_sidebar (consult Widgets API docs page for more info) are these:
$p = array(
'before_widget' => '<li id="%1$s" class="widget %2$s">',
'after_widget' => "</li>/n",
'before_title' => '<h2 class="widgettitle">',
'after_title' => "</h2>/n"
);
register_sidebars(1, $p);
In other words, the built-in Widgets code is to put each of them inside an <li>. To fix this, we do it this way:
$p = array(
'before_widget' => '<div id="%1$s" class="widget %2$s">',
'after_widget' => "</div>/n",
'before_title' => '<h2 class="widgettitle">',
'after_title' => "</h2>/n"
);
register_sidebars(1, $p);
And to set-up the Widgets area inside sidebar.php, simply use the code:
<div id="sidebar">
<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar() ) : ?>
// static code here
<?php endif; ?>
</div>
And that’s it. Simple changes, much lovely code. Thoughts?
