Hey all. I'm relatively new to Drupal in the past six months and overall I love it. In general, the Drupal sites I've developed are relatively easy to maintain and the community built around the CMS is responsive and helpful.
However, there is one thing that keeps on tripping me up: there is all sorts of additional markup that is generated that is just plain unnecessary for the display and styling of pages. I'd like to explore the feasibility of reducing some of the markup that is output in future versions of Drupal (probably beginning with v7 since v6's core code was just frozen, right?).
Here's an example of what I'm talking about. The primary links on one of my sites:
<ul class="links primary-links">
<li class="first menu-1-1-2"><a href="favorites" class="menu-1-1-2">My Favorites</a></li>
<li class="menu-1-2-2"><a href="product" class="menu-1-2-2">Store</a></li>
<li class="menu-1-3-2"><a href="forum" class="menu-1-3-2">Message Board</a></li>
<li class="last menu-1-4-2"><a href="categories/all" class="menu-1-4-2">Browse Categories</a></li>
</ul>
There's no reason to repeat the class on the li's and the descendant a's since you can style descendant selectors via css. That is, if you wanted to style the first link based on its class, you could just use the following css markup
li.menu-1-1-2 a {
/*whatever my style is*/
}
So the markup I would like to see for my primary links would be
<ul class="links primary-links">
<li class="first menu-1-1-2"><a href="favorites">My Favorites</a></li>
<li class="menu-1-2-2"><a href="product">Store</a></li>
<li class="menu-1-3-2"><a href="forum">Message Board</a></li>
<li class="last menu-1-4-2"><a href="categories/all">Browse Categories</a></li>
</ul>
In fact, I'd like to see a less verbose option available that removes the classes from the li's, as well. I'd argue that the :first and :last pseduo-selectors are becoming more widely supported and you can effectively target browsers that don't support the pseudo-selectors through jQuery... and I would guess that there are many Drupal users that don't always have the need to style each individual primary link.
I'm also not sold on the idea of using positioniseverything's easy clearing in modules/system/defaults.css (http://www.positioniseverything.net/easyclearing.html). That adds all sorts of extra classes all over the place. It might be nice to have an option to insert the clears via jQuery, if a user is so inclined or to develop markup that doesn't require CSS that's full of hacks. The positioniseverything technique was developed in 2004/2005. It's at least time to take a good hard look and see if it's still the best way to accomplish effective floats.
Thoughts? Feedback? What am I missing?
Comments
interested to see discussion on this
i agree wholeheartedly with your first example.
as for clearing floats, the liberal use of span class="clear" does bug me, as i usually clear my floats with the width/overflow method, but it's also a matter of personal style. plus, i think it's easy enough to remove these by adjusting template.php and some of the tpl.php files although i haven't tried yet.
i agree that it seems there is a bit more markup than necessary, but i guess it's to cater to themers/developers who perhaps don't understand css to the fullest extent and it makes it easier for them, which is fine. i'm hoping that as i learn more about this application, i'll be able to go through and strip out the extra classes (clear-block block block-block, anyone?) where i don't need them.
i guess my position (pardon the nerdy front-end pun) on it is that at the moment i'm so busy trying to get drupal to behave in other ways that i haven't had a chance to worry too much about the html so long as it validates. would love to hear other opinions on this from people who have been working with drupal longer than i have.
template.php
Hey, I'm not a php developer, but I can copy and paste it in the correct spot in themes.
My suggestion if you need a solution now is to look at other themes. Its real quick to enable them. Check and see what kind of code they output with a source check. If it looks good then go into the template.php file and the page.tpl.php file and see whats going on.
You might want to start with zen.
Zen is a good starting point
There is even a task force whose aim is just that: http://groups.drupal.org/zen-task-force
A lot of the "clear-block
A lot of the "clear-block block block-block" kind of things come from the block.tpl.php files. In general, I've found that if I'm constantly using multiple classes to style an element, I haven't thought out my design very well. In the case of styling blocks, a more reasonable format might be:
Where blockTitle is the unique name of a block and standardBlockStyling is a general class applied to all blocks. Sure, it's fixable as it is now, but I have a general issue with having to fix markup that is verbose and confusing. It may not be so bad were there not a general "defaults.css" outside of the general theme structure.
You can try putting up
You can try putting up patches and see how others take it. a 7.x dev tag is up already.
It'd be very low priority and the only objection I can imagine is that it *may* put an extra burden on themers in the next upgrade if they used those classes. Then you have to ask, for what gain?
I haven't looked into how IE7 supports pseudo selector (if it does at all) but depending on jQuery I'd guess would not be acceptable for core. jQuery = more client side processing and more potential confusion for themers. Again, for what kind of gain? The way it's done now works very well.
All these classes can be overridden and if it bothers anyone enough, there is the opportunity to change it from your theme. Maybe when it becomes overwhelming with redundant classes there would be more focus on it but currently, I don't see it as a problem.
If there are any bits of HTML not overrideable, patches are almost always accepted to change that.
Can you point me to
Can you point me to documentation on overriding the the "bits of HTML."
The problem with the extra classes are that they clutter the markup, potentially damage search engine results, make it difficult to troubleshoot problems with CSS styling, and discourage potential themers who find the sprinkling of unnecessary classes distracting and confusing. Additionally, it sets a bad precedent for the markup made by contributed modules (views in particular).
Google on theme
Google on theme functions.
Classes have no impact on search engines. It's more about semantic markup.
<h1>with a class of "paragraph" is still seen as a header no matter how redundant.There's Firebug to track styles and to see what it's hooking into. Everything is filtered so it doesn't matter if there are too many classes. There are so many great tools out there these days. Extra class here and there shouldn't be too confusing. Everyone should be aware of Firebug, I'm sure you are. I use Xylescope & CSSEdit myself.
Even with Views.. Definitely looks confusing but Merlinofchaos (the author) made sure each iteration of a view is hookable so it can be styled. But again, it can be changed by overriding theme functions.
And using jQuery to substitute the clear-block class would be a mistake. Not everyone has js turned on. Page behavior and presentation should be separated. The easy clearing method still works great. Why change it? I'd be amazed if an improvement was made since it's such an elegant solution.
btw, I think overriding theme functions just to remove classes is a waste. I'm not saying the way Drupal applies classes is perfect. A central API on defining them would be great but more work than most devs think it's worth, but that's just my understanding.
Yes, it's pretty clear that
Yes, it's pretty clear that you think overriding theme functions to remove classes is a waste.
I'd like to make a few clarifications:
* jQuery to substitute the clear-block class is one possible solution that I suggested, and I would agree it's a less than ideal fix. Typically, web traffic statistics indicate approximately 10% of web users have Javascript turned off. It would definitely be my last resort.
* The position is everything fix adds extra markup; it's a less than ideal solution that is not needed for many semantically correct designs. That's my beef with it. Why change it? Because it's a one-size-fits-all situation that is oftentimes not needed. I wouldn't suggest getting rid of it; just offering a few different choices of how markup is output in the core. It's not just the position is everything fix that's the issue of course; it's a symptom. Added classes and markup that are really not needed for proper display or functioning of the site is endemic throughout the default Drupal installation.
* It's important to remember that it's not just developers that use Drupal; there are web designers, too. I'm familiar with Firebug and other tools to assist in CSS development. However, I believe wholeheartedly in the KISS principle; the simplest markup and the simplest answers will often get you a lot farther than convoluted output.
I agree with prattboy
There are a lot of unnecessary markup in Drupal. A lot of divs (divitis) and a lot of classes (classitis).
http://ahsanity.wordpress.com/2007/05/15/divitis-and-classitis-two-new-w...
http://sanjaymalge.com/blog/?p=52#comments
http://drupal.org/node/110413
Omtisis Consulting