Semantics is one of those things that HTML nerds like to go on and on about but most normal designers either don't understand it or don't care about it. Being an HTML nerd, I find semnatic HTML interesting and I prefer to use semantic HTML elements whenever I can. But I know that I'm the exception not the rule. I was talking with a group of print designers a month or two ago, and one of them asked me why the STRONG element was better than the B element. Apparently, his web designer had switched over to all semantic HTML and was asking that all the content developers do the same, and that primarily meant that he wanted them to use STRONG instead of B and EM instead of I, but my friend couldn't see why STRONG and EM would be better. After all, they do the same thing, and from a speed perspective, B and I are both better because they use fewer characters. I tried to explain that the STRONG and EM elements have a semantic meaning that B and I don't.* But if you don't understand semantics, it doesn't help.
* If you're familiar with HTML5, you know that the B and I elements have been given semantic meaning as well, but most of the time the are just used to add the styles of bold and italics, which should really be handled by the CSS.
this is good idea,i have voted no, why ,i indeed not understand semantics in HTML. But while i read the post , i am googling , maybe i can understand it and use it.
You can`t describe in details google is a better way to understand.
Actually, a STRONG element is almost as bad as a B element. Neither is as good as a SPAN with class=”strong emphasis”.
Don’t get me wrong: I’m all in for a semantic web. The problem is that HTML is not (it never was, and it will never be) the right tool to annotate semantics. HTML is a language for marking up the structure of a document, and it’s freaking good at that. When one tries to shoehorn another task into the language, the tasks clash with each other and things begin getting messy.
On presentation, we found that HTML 3.2′s FONT, BIG, SMALL, etc, led to a mess of over-bloated, broken documents from whose markup no real structure could be inferred. CSS not only put some order to the mess, but also solved the presentation needs much better than HTML3.2 did.
It was also seen (to some degree) with behaviour: stuff like APPLET vs. OBJECT vs. EMBED or, evne worse, Microsoft’s “data-binding”… And, as we learnt, behaviour is best left to client- and server- side scripts.
Just like it happened with presentation and behaviour, semantics are a separate aspect than structure, and thus HTML can never be suitable to handle it. All those attempts just hurt HTML’s ability to describe structure. Only this time we already have solutions to deal with semantics, like RDF or Microformats.
HTML5′s sectioning model is a good example: SECTION could have done the job, and it’s enough to describe sectioning structure; but HTML5 insisted on including several elements (ARTICLE, ASIDE, NAV, etc) for the same structure, just differing in semantics. A class or some new attribute for SECTION could have dealt with the semantic distinction well enough. Now we have a huge cost to introduce any new kind of section (older browsers wouldn’t recognize it at all), and we have no way to describe sections overlapping two kinds (ex: a “See also” section should be both an “ASIDE” and a “NAV”) unless we compromise actual structure (putting one element inside the other).
I have just a vague understanding that “strong” is better than “b”, but I actually don’t use either in practice. I do all styling via CSS and always define styles for italic and bold styles.