Archive for July, 2008
Cleaner HTML by Avoiding Attributitis
Friday, July 25th, 2008Did I just invent that word? Most developers using CSS layouts have likely heard of “divitis” (using far too many DIVs in your markup). But what about “attributitis” (or, Attribute-itis, if you will) — the distant cousin of divitis? I didn’t bother googling that word to see if anyone else has used it; I’m hoping I’ve coined it! I thought of it this morning while helping a coworker debug a CSS problem. It struck me that the class and ID attributes that are commonly added to HTML tags can really get out of hand if they aren’t controlled properly. Let’s discuss a few points that will ensure cleaner code and better future development time through the practice of avoiding attributitis.
Fewer attributes further enhance clean code
Often because we want to easily identify our styles in our stylesheet, when we code an HTML tag, our first instinct is to add a “class” or “id” attribute. At times I do it without thinking. But think of how much cleaner the code would be with no class or ID on that tag? That’s right — just a plain ol’ tag. And when you combine this with the avoidance of divitis, you can easily see the contrast:
With divitis and attributitis…
<div class=”my_ul_holder”>
<ul class=”my_ul”>
<li class=”my_list_item”>Example Text<li>
</ul>
</div>
And Without…
<ul>
<li>Example Text<li>
</ul>
I know what you’re thinking: It’s not always that easy — sometimes you have to apply classes and attributes in order to differentiate. But, to some degree, it can be avoided.
Have site-wide defaults for commonly used tags
By now you should be using a CSS reset to revert all your site’s styles to the bare minimum. If you’re not, do yourself a favor and research the topic and start using a reset. It’s extremely helpful for cross-browser compatibility. But further down in your style sheet, you should have a section of code that contains the site’s custom default styles for various HTML tags like H1, H2, P, UL, and others.
For example, if you know you’re going to have about a dozen unordered lists on the site, styled exactly the same way, there is no need to put class=”my_unordered_list” on every one of them. Just leave the class attribute off completely, and style your UL element to reflect this in your style sheet.
Even if you want to apply a different style to one of them, you can simply do so through the DIV hierarchy that you’ve already likely created in your XHTML. So instead of of adding
class=”other_unordered_style”
to your UL tag, you can leave the UL naked and use something like this in your CSS:
#footer ul {
// enter styles here
}
to declare a different set of styles on the single unordered list that appears in your footer.
Cleaner markup and better site performance
This will leave your HTML code clean, semantic, and (somewhat) attribute-free. True, this will likely add a few kilobytes to your CSS file. But since CSS is cached by your browser, it will work out better overall for your site’s performance. With a little careful forethought, XHTML and CSS can easily be stripped down to its bare bones — or close to it — and your site will still look as beautiful as it was intended from a visual perspective, and will no doubt be easier to maintain in the future.
Impressive Links of the Week (July 24/08)
Friday, July 25th, 2008Homer Simpson’s email address hacked
Hi-tech is turning us all into time-wasters
Evoking Curiosity — a Form of Marketing
What Boston and Nirvana Can Teach You About Finding Your Winning Difference
SEO Rules vs. SEO Concepts
Friday, July 18th, 2008Often times, web development blog posts recite easy to understand, step-by-step instructions on how to optimize XHTML code for SEO. Generally, I think this is good. The fact is, web users have low attention spans, and usually the best way to get a message across is to state it simply in point form. But in order for developers and internet marketers to enhance their abilities over the long haul, more is necessary, as we’ll discuss. With this article I’ll show how online writers and readers alike can become part of a long-term commitment to making the web a better place to surf.
Why lists of “rules” can often fail in the long run
It is often said that behind every rule there is an underlying principle. Let’s illustrate this with an example. When a blog post tells a user to use H1 tags for headings instead of something clunky like
<div class=”header_main”>My Example Heading</div>
then the whole reason behind the necessity of the H1 may become lost on the reader, especially a reader that is new to web development, or is picking it up simply as a hobby. In such a case, the reader needs to understand why such an approach to markup is necessary — not just that it is necessary. Simply stated, websites are more findable, search engine friendly, and faster loading when the markup is semantic. Now, I’m not going to go into the details of defining “semantic markup” here. That is a topic for another post. But I’m emphasizing that the rules can easily be forgotten over the long run if the readers are not understanding the reasons behind certain SEO techniques, best practice coding, and other standards-based ideas.
Online writers and readers both play a role
So writers should be more aware of the effect their content will have on the future of web development, SEO, and the internet in general. We as writers should strive to teach others based on strong foundations and concepts that are clearly understood. Likewise, we as readers need to strive to read and learn from others based on strong foundations and concepts that are clearly explained. Both sides have a significant role to play in what the web will be like down the road.
Readers and writers, aim for a stronger foundation of learning
Therefore, in conclusion, while the typical bulleted lists and point-form rule-sets have their place and can be very useful, the more important “reasons behind the rules” are what will truly enhance a reader’s development as a web site professional, and will, by extension, make the web a better place for all.
Impressive Links of the Week (July 13/08)
Sunday, July 13th, 2008Cracking Google’s 1,000 Page Barrier
Tips for Better CSS Files
Thursday, July 3rd, 2008While working on medium to fairly large websites, I’ve recently found it helpful to apply certain coding practices in my CSS files to help readability, and to ensure that any future developers (including me) will have little difficulty editing the CSS code. Since my main CSS files nowadays often end up being anywhere from 1000 to 2000 lines long, here are some quick tips that I think help CSS code to be more readable and web developer-friendly:
1. Indent CSS using the same structure as the HTML
I don’t know why this isn’t more prevalent (at least it’s not written about a lot online), but I recently started doing this after viewing an online video from a fairly popular CSS developer and blogger. Having the Web Developer Tool Bar in Firefox helps track down CSS fairly quickly, I find the indenting actually assists the development of the site itself. It’s much easier to read the CSS and see what the code is doing, even as you type. Especially is this important if the project spans many weeks or months, as the structure of the HTML and how it relates to the CSS styles can easily go forgotten. So, indent your CSS in a hierarchical manner so you can easily match a nested section of HTML to its CSS counterpart.
2. Use lots of spacing and comments
The comments are generally a no-brainer. All good code is commented. But the spacing is simply for readability. I know, the more white space you have, the more bandwidth it’ll cost you, but you can always remove the white space towards the end of the project, if necessary. And spacing should not just include that which occurs as entire lines between ID and Class groupings — I personally like to see white space in between all the selectors and colons as well as between grouped styles that are organized all on one line (as opposed to one on each line within the group, as seems to be most common). So do this:
#example_section {
float: left;
width: 300px;
height: 400px;
background: url(../images/example_image.jpg) no-repeat 0 0;
}.example_section_2 {
color: #fff;
line-height: 14px;
}
Not this:
#example_section{
float:left;
width:300px;
height:400px;
background:url(../images/example_image.jpg) no-repeat 0 0;
}
.example_section_2{
color:#fff;
l ine-height: 14px;
}
The difference is subtle in this short example, but the first example is much easier to read when applied to a 1000+ line CSS file.
3. Always use external files to hold your CSS code
This is a basic tip, and all good developers should do this. If your main CSS file applies to dozens, or even hundreds, of content pages, then your pages will load faster with an external file because all subsequent page loads will get the CSS code from your browser’s cache. Thus the CSS will only load once, saving bandwidth and improving user wait times. And of course, the other benefit is that the CSS stays separate from the HTML, the same way the JavaScript should, keeping the 3 layers of front end web development clean and separate.
4. Keep default styles and link styles near the top
For me, this one is a bit of a personal preference. I like to know that all my default styles (CSS reset code, heading styles, unordered list styles, hyperlink styles) are easily accesible near the top of the CSS document. After all, those styles are not always part of the HTML hierarchy, and often won’t fit well with the DIVs, custom paragraph tags and the like. So when I do a high-speed scroll through my CSS code, I know that when I get to a certain section near the top (in my case the section that styles all hyper links on the page), then I know that all my default styles have ended and the hierarchical section begins. And with some effective commenting, the rest of the document can be just as easy to scroll through and find a particular section.
5. Use shorthand notation
This will improve your CSS code immensely, as well as save a few kilobytes in bandwidth. Basically it means putting related CSS styles on one line instead of declaring them all using separate selectors. So for example, here is a long-winded example of applying a background image to a DIV tag:
#my_example {
background-image: url(../example_image.jpg);
background-image: background-color: transparent;
background-image: background-repeat: no-repeat;
background-image: background-position: 0 0;
}
And here is the better shorthand version of the above code:
#my_example {
background-image: url(../example_image.jpg) transparent no-repeat 0 0;
}
Much easier to read, easier to maintain, and the order of the values doesn’t matter, so you can make the reference to the JPEG image the last value if you prefer.
Benefits while you develop as well as in the future
The benefits reaped from these tips will not only help developers working on the site in the future, but will help you during the process of developing the site. Often, client requests and other project details interrupt the workflow. That can put a damper on your mental ability to stay focused on how you’ve organized your code. To ensure that your code doesn’t become an unintelligible mess, keep things neat and organized and you’ll see the benefits now as well as in the future.