I am sure by now, everybody has been scorned upon for not using semantically correct markup. It's all over the web today. The message is clear, Web standards are important. Valid Xhtml is important but above all, SEMANTICALLY CORRECT MARKUP!
What is Semantically correct markup ? First lets define semantics :
Semantics refers to aspects of meaning, as expressed in language or other systems of signs.
So, when we say semantically correct markup, we are reffering to the use of the correct HTML element that best describes the content contained within as such giving it meaning. There is actually an HTML element for pretty much any type of content you may want to display. For example if we had a heading, then we have the <h1 element, if we had a paragraph, we can throw it in a <p element, had we a list, we can use a <ul element. Ever wanted to display a quote block ? Use the <quoteblock element. You got tabular data ? Then you can use the <table element and that's how it goes. There are just way too many html elements to list here but you get the idea.
But, isn't Valid markup enough ? Today we are all moving out of quirks mode and into the XHTML arena. We can see many benefits coming from writing valid XHTML that does not send our browser in quirks mode (which would mean the browser will be performing many code checks to see where you messed up in your mark and try and correct it for you). Obviously valid XHTML markup means your page will be rendered faster by the browser than one that has to go in quirks mode.
So back to our question, isn't valid XHTML markup enough ? What does semantically correct HTML bring to the table. Moreover, how is this rule enforced by the browser ? Well, it's not. However had you any common sense you would use the proper HTML element to achieve what your trying to do, because there is actually an element for pretty much any type of content you may have and there is no need to try and disguise or fake one element to perform like another.
But is that it ? Yes, i think so, but not only. It has more uses. Using semantically correct HTML allows your applications to easily provide proper accessibility support, since you can place your markup in a linearized manner that allows it to be read from top to bottom and make sense without the styling obviously as will be the case with some useragents.
But look, Google uses tables for layout. How bad is that, accessibility wise ? Well,it is possible to achieve accessibility with tables too as long as when the table is linearized, it's content is readable in a meaningful way by the useragent for the disabled, parsing the content, just maybe harder or impossible to do in a complex layout. Well, good for google, their layout is quite simple, so it does not surprise me that they never felt the itch to update their HTML and use semantically correct markup, since i doubt that investment would be bringing anything to their *table* anyway.
I've read several claims that semantically correct markup helps in search engine optimizations as in search engines use particular HTML tags to give weight importance to what they index on your pages. I'll agree that the <title tag is important, but apart from that, I have not seen or heard of actual facts or claims made by the search engines themselves, so i'll leave that as a myth. Again let's not forget google, quite the example they are setting if this were to be true :-)
I'll agree however that Valid XHTML markup on the other hand can help a search engine index your page better, since it is valid, without markup error, you also have a lighter weight page(since style and markup are not mixed up), making it easier for search engine bots to crawl, search and index your pages content.
One thing i want to note before I continue is that semantically correct markup, is not the same as valid markup. A non-semantically structured page is also valid markup. Neither the browser or the XHTML schema enforces any rules on what kind of content is contained within the html elements.
Now that we know what semantically correct markup is and what the benefits are, mostly it boils down to 3 things for me :
1) Common sense, there is an html element for the type of content you want to display, so use it.
2) Accessibility
3) Works nicely with CSS layout, allowing us to keep elements in a certain order for accessibility + changing layout without needing to touch markup while were at it.
Achieving semantically correct markup with ASP.NET today is quite a TASK. In most cases you might find an escape by resorting to css friendly adapters, while in some cases you don't have a choice like with Webparts whose render output is tables.
I still feel however that a combination of both CSS layout and using a table where necessary or beyond our control is not so bad, so long as the table can be linearized(Acessibility is not lost in this manner).
What maybe lost however, is the ability to use css layout on the table we just introduced. A table lays out it's cells and rows. Not much you can do with css to lay it out. But how big of a problem is that really ? We do have valid XHTML markup.
And unless you are abusive and unless your layout is completely dependant on Grid layout, i believe css layout and a couple of tables when needed, provided that the table can be linearized for accessibility, i feel you have nothing to worry about.
Using css layout, you can control the layout of elements on the page easily without touching markup. However, there are limitations to this. It is possible to want to have different views of a page based on certain conditions. Note, different views as in content being added or totally absent. In case we need to hide content, this can be accomplished, but hiding content via css does not stop it from rendering in the markup(which we can consider un-necessary bloat). While replacement of content is pretty much impossible. We can basically work with elements in the markup, but we cannot add new elements without touching the markup. This is easily a requirement in many scenario's, so the only viable solution is to use templates.
Using templates, we can easily have a different template for any view. In this manner, we are able to have markup in any way imaginable. At this point, css for layout while useful is coming short. Further more, even if we had tables in our layout, we can easily rearrange them or change them in any way possible since we are in contact with the markup.
This is a common need, especially if your working on content management systems. Templates come into play here, and templates are files with actual markup in a different order or markup that is included in one template which does not have to be present in another and so forth. All things achievable on the serverside obviously, so it wont really matter that much if you used a tabular layout or a css layout, atleast wont as far as easy customizations and modifications are concerned.
100% semantically correct markup is not easy today with ASP.NET, and not something i want to bother with investing too much time and effort over. Clearly it is indeed a time consuming task and the time spent to achieve it does not easily translate into something you can easily justify for when you end up not having enough time to spend in the real functionality of your application at hand.
During development, i like to think of writing my code in a way that will require minimal amount of effort on my part since always i'm on a time frame, and then how i can easily maintain that same code. The functionality and ease of use, maintainence and time spend to achieve the task at hand usually surpasses by far the requirement to maintain 100% semantically correct markup. I like to write semantically correct markup where it makes sense in time needed, code need to achieve the task and effort later to maintain that code.
Ofcourse the big question when you throw in a table will be : Can your table be linearized ? When linearized is it meaningful ? Accessibility is a fundamental need in many projects.
I hope with this post i'm not discouraging semantically correct markup but on the contrary, you should try to write semantically correct markup, however if i may be frank, there is no need to sacrifice time,ease of use or maintainence to achieve it at 100%, instead a "compromise" can exist.