I was talking with my friend about a job I'd done, when we got into a bit of an argument. Talking simply, I had done this to produce a 1px coloured line: <div id="line"></div> "What a waste of code, you could have just used a <hr />" he said. True, but false. Sure, the HTML would have been tidier, more semantic. But what about the CSS? This is nearly always overlooked! Let's compare (I'll put the HTML and CSS in 1 line so you can see the length difference): Option 1 is the clear victor, it is far shorter. Sure, option 2 is more semantically correct (ignoring the fact the above doesn't work properly in IE6!) but option 1 kicks ass when it comes to minimalisation. This is what minimalisation is about. I spent ages learning how to make everything semantically perfect in the HTML, and once I knew, I realised that it was not about being perfect, it was about giving the target market what they want: the fastest possible loading page, that works on as many browsers as practical (more browsers = more hacks = slower, supporting the major 5 is fine, using hacks for all starts bloating it unnecessarily given the fact next-to-noone will use them) What do users care about more: "technically perfect" HTML and CSS, or a site that loads fast? Some food for thought
I usually don't pay attention to small things like this. I personally don't know what I would use since I've never had this "problem". Usually I'm able to set a border on a div that's already there, and not make a div just for the border. But anyway.. can a human even notice the difference of loading time between small things like that? I always do the best to be as semanticly correct as possible, and that usually tend to result in less code anyway so..
I apply the same principle. I'd rather have a few extra bytes in my stylesheet and use the proper semantics, especially if more people will be editing the site/css later on.
Usually yes, this was a bizarre setup where I actually couldn't due to the design. It's not just that - thats 1 tiny bit - the point is that if you save bits of code like that on everything you write that adds up a lot. It's not just about loading fast. Take Yahoo - they would get billions of hits. Them saving 1kb on their page is a really big deal, thats saved them tens of thousands of dollars in hosting fees EDIT: And actually the <hr /> is a presentational element, not structual, therefore it is not semantic
And a blank div element is semantic??? I have never found myself in this situation, where I do not already have a div to put the border on (or another element.) I probably would have gone for the horizontal rule, but thats just me
No, but the only argument they had was "hr is semantic" when its not. So really, there is no solid argument for using a horizontal rule. HR: Not semantic, longer code (and still doesn't work in IE6, so more css is required to fix that) Blank Div: Not semantic, shorter code, works in all browsers (and less time dicking around getting it to work too) So really, the blank div is the best choice. Why the <hr />?