Semantic Sound-Off

This week’s articles all deal with discussions on semantic markup. The first reviews some of the basic differences between semantic and un-semantic code. The writing was mostly a reminder of things we’ve already covered in class, but the examples the author used were a great side-to-side comparison of what makes code “well-formed”. In particular, his explanation for using a header tag for something like a company logo was helpful; I hadn’t considered using an h1 tag to delineate something other than a text header.

The next piece is a lengthier discussion on some of the difficulties faced when taking internet data and integrating it into semantic markup. It’s worded a bit clumsily, but the author seems to worry that it is very difficult to agree on what tag names we should use when trying to describe our content. He is concerned that everyone will come up with their own tag names to fit their data and the result will be an online “Tower of Babel” where our ability to read and understand code content will be diminished by the great variety of different tag names we would have to absorb.

I can understand some of his concerns, since it seems very unlikely that there will be a wholehearted acceptance of any one way to name tags due to the deluge of different information on the web. However, I don’t think the goal is a single naming convention for all web data; rather, it seems our aim should be to use tag names that are well-defined and clear summaries of what content lies within. For example, rather than naming something ambiguous like “right_column2”, we should try to use names like “content_news” or “testimonial_box” – names that tell anyone reading the code what kind of content lies within. As long as our tag names aren’t too confusing and we try to abide by the other rules of well-formed code (ie: breaking down the content using standard tags such as headers, paragraph tag, lists, etc.) I believe we need not worry about having such exactness between tag names as this author fears.

Finally, I really enjoyed the last reading for this week. It’s a short rant on the recent emphasis towards making sure everything you create on the web is “validated” and why this isn’t as important as many like to preach. What I like best about this author is his frankness – you can definitely tell the author’s opinion is born out of many a late night trying to make a deadline. I definitely relate to his complaints. Sure, having really clean looking, validated code is great when you have a good amount of time to finish your work, as is often the case when we get school projects. But sweating bullets about not being “validated” when you have a much more pressing schedule to meet isn’t necessary. As the author points out, many of the most popular pieces of web-media or other code won’t validate unless you write specific work-arounds for them, which can be unrealistic for those times when the most important issue is, “Will this work right now?” I found this a refreshing piece amongst the many cries for validation that I often hear.