At the moment, I’m attempting to completely rewrite the HTML and CSS beneath clagnut (you won’t see any changes until it’s all done). In terms of HTML, I think the site is written pretty well; there’s very little Bed and BReakfast markup and it’s pretty accessible. There is, however, room for improvement; there a too many nested divs, particularly when more relevent markup (usually a list) could and should have been used.
As for the CSS, the site has grown organically over the past 8 months and the style sheet has grown with it. Combined with the extra divs, there are heaps of classes which I’m struggling to keep track of, generally making things a bit of a ’mare. Plus, as mentioned before, the margins are erroneous on IE6.
The new mantra is context before class. Which translated means don’t use a class for presentation when the context of the HTML element is equally unique, e.g. a <p> element inside <div class="sidebar"> does not need a separate class of sidebartext. Hixie goes as far as to advocate not using classes at all.
I plan to publish a complete build/design spec once I’m done. I’ll keep you posted. Saila’s Web building tips might help me along the way.
Tomas wrote:
I like clean markup, and I admire your effort. But, why exactly is it important to not have redundant class-names? I mean without getting excessive about it..
David Dorward wrote:
Tomas: Redundant class names make it easier to make mistakes (such as leaving the class out on one paragraph) and bloat up the code, which makes it less readable and slightly more consuming of bandwidth.
Rich wrote:
Tomas: For further discussion of David’s valid reasoning see:
http://tantek.com/log/2002/12.html#atoc_cbeforec
There is also the question of classes being semantic-free: they mean nothing. In the real world this only becomes relevent when we use XHTML as a way of structuring information with a view to it being aggregated. The idea being that aggregation programs would be able to visit a website, pull out the structured information and present it usefully in a different medium. There’s lots of this going on already with other XML formats, where programs exchange structured data as an XML file.
For this to work well in a web page context, we would need to use the semantics (meaningful tags like H1, UL and DFN) already available in XHTML. More info:
http://ln.hixie.ch/?start=1038263537
Tomas wrote:
I get that much of it; less bloat means cleaner code, which is a virtue, sort of. Less bloat leads to less chance of a mistake, which is good for me, which I get.
But are there any tangible reasons beyond that of “it’s good, so do it”?
I can think of atleast one reason why “redundant” classes, and divs, are a good thing; in case I would want to change something in the future, I’d only have to add or change a couple of lines of CSS, where I with minimal amounts of divs and classes might have had to do add what was previously “redundant”. I experienced just that with my first blog design/layout, I’m now on my third and I’ve learned my lesson: better safe than sorry.
Kris wrote:
Using less to no class attributes at all, opens up the cascading nature of CSS, to your advantage.
Writing things in one line of CSS where you previously needed 2, 3 or more.
I recently had to work on a colleague’s product where she had used font-sizes on every selector and a class for everything. I struggled over 5 hours to get a simple link look okay in a page that I had to add with a slightly different appearance. It was hell.
html,body,table,input,select,textarea { font-family: sans-serif; font-size: 100%; }
is all there is to it.
Johan wrote:
Now that Dean Allen is about to release his Textpattern, I’m considering ditching MovableType and switch to it, and redesign in the progress. While my current HTML validates just perfectly, it’s a jungle of classes and id’s.
When designing it I wanted lots of classes so I could change pretty much everything just by poking at the CSS, but I shot myself in the foot with that. The next design will be nice and clean with no unnecessary tags, classes or divs. knock on wood
Rich wrote:
As Kris pointed out, by minimizing classes and ids I find ‘m actually making good use of the cascade effect.
In the long run, I don’t believe this will save me much code, but when I have set a class, I’m much more aware of what styles that class is likely to inherit.
The key seems to be avoiding using a classes purely to change the presentation of an element (AOT assigning some meaning). Before creating a class, look closely to see if that element already has a unique context (paragraphs in a ‘sidebar’ div). Perhaps the element could be styled with more meaningful markup? ULs, DLs, BLOCKQUOTEs, ADDRESSes, CAPTIONs, FIELDSETs, CITEs, DFNs are all good candidates.
Kris wrote:
What I also find helpful, is using a Strict DocType to validate against. “Bed and BReakfast” markup is seriously a lot harder in Strict, so this may lead to a better understanding of how to code correctly. The result can be a much semantically richer repertoire of elements (and attributes) that you can use as unique CSS selectors.
For instance:
<body>
<h1>form</h1>
<form>
<h2>personal</h2>
<label>Name:</label>
<br>
<input>
<br><br>
<label>Name:</label>
<br>
<input>
</form>
</body>
Will simply not validate under a Strict Doctype. A much better deal is the following (extra stuff added):
<body>
<h1>form</h1>
<form>
<fieldset>
<legend>Personal</legend>
<p>
<label>Name:</label><br>
<input>
</p>
..
</fieldset>
</form>
</body>
Now look at all the elements you can target here.
Rich wrote:
If you wished to be really picky, you could remove the <br> after the <label> element by making label display:block in the style sheet.