It's just voodoo thinking on the part of web designers that were taught about it circa 2000.
And it basically comes from the misunderstanding that the html page is the data, when it's really just a RENDERING of the data. The data is what's on the DB or storage system --and that, yes, has to be semantically stored and attributed.
The template is just a means to show them GRAPHICALLY, not semantically.
Except if our main purpose is to make screen scrapping easier.
We structure databases semantically for backend developers. Why shouldn't we structure display markup semantically for frontend developers?
Only if you have a poor system of sharing data, one that necessitates the rendering to be the data. Why put that inflexible requirement upon yourself? We have plenty of renderings that are not supposed to be data (i.e mechanically readable) by themselves, from graphical UIs to paper printouts.
> We structure databases semantically for backend developers.
> Why shouldn't we structure display markup semantically for frontend developers?
Because the target audience of the display markup is not "front-end developers", it's our website viewers. And they could care less how we structure our display markup.
A truly intelligent system of content/display separation wouldn't use "semantic markup" and such nonsense, but true separation, i.e multiple types of data output.
Take accessibility for example. What's good for a web browser is not equally good for a screen reader.
The optimal path would be not to share the same display markup, but to create a specialized screen reading output that can leverage the same underlying data.
We only do a half baked work when we add media css, alt attributes and such to "semantic display markup". It's a leaky abstraction.
And then you go and implement an interface to the website as an Android or an iPhone app, and suddenly the "semantic display markup" is useless, you do it with custom queries and native controls. Or you go an implement a voice operated interface to the site, like voice xml, and the "semantic display markup" is of no use here too.
Heck, even when we output something as basic as an Atom/RSS feed, we don't get to reuse the "semantic display markup", we output a customized feed.
That's not really true, though. The viewer is the target audience of the display output, not the markup. The target of your markup is either someone technically minded (who would do a 'view source') or some sort of crawler that is trying to derive semantic sense from your document.
In that context, semantic markup makes total sense. Part of me is still disappointed that using XML+XSL for web pages never took off- implementation nightmares aside, separating page data and page presentation is an awesome concept.
By that line of reasoning, why should a semantically-structured database matter? The website viewers never see that, either.
Unless the reason you care about semantics in your database is for ease of development. In which case, all the front-end developers you might work with in the future would thank you for thinking of them when you output your markup.