Pimp My Semantic HTML Ride

Had a conversation at work about producing semantic HTML. The idea is that each piece of content should be described by the most specific HTML element that does the job, and the current is driven by CSS's success in separating presentation from content. A noble goal.

The all too pervasive incarnation of this crusade to make thine document semantic is materialized by the menu as list. The concept is simple. Instead of div and span elements, use ul and li elements to describe the structure of your menus. After all, isn't the menu a list of items?

Mmm... not really. Not more than pretty much anything in the page, like the collections of paragraphs that you're now reading. In fact, you must resist the temptation to see a list in everything; otherwise, the menu as list rule will transform your whole document into a collection of lists of lists of lists in no time. I call it the menu as list syndrome.

Not convinced? The purpose of ul is hinted not only by its name and formal description at the W3C, but also by its default appearance in web browsers. In fact, a list renders as a series of bullet points in all serious browsers (the browser that I'm going to write in order to disprove this assertion notwithstanding), a good indication of its inclusion into the group of typographic elements of a document.

I don't blame my colleagues for having come up with lists for menus. In fact, the web is buzzing with this approach (probably a trend promoted by ALA). I guess people do it out of that innate desire to improve that we all share and out of a will to be on the wave and use the buzzword.

But, at the end of the day, I prefer to describe my menus as divs and spans. It saves me the trouble of overriding default, common-sense rendering rules in my stylesheet, and, frankly, I don't really see the semantic gain of the list as menu.

The Code Convention as Rule

I frowned when my colleagues came up with the requirement of using a tab size of three characters in all our C# and JavaScript source code writing. The requirement came about as a compromise between two different preferences -- one, to use a tab size of two, and the other, a tab size of four. The former of which must refer to JavaScript files.

When they came up with this result, my colleagues missed one important point. Conventions already exist, and they exist to be used. Conventions are not meant to be flexible and adapted to the team. I say that with the strongest of convictions; I haven't yet found a reason to stray from Java's coding conventions in all my years of coding Java. Nor did I have to stray from Microsoft's C# code conventions now that I'm back to C#. I did have to fill gaps sometimes, but I didn't have to bend any existing rules.

Whether the decision to compromise on the tab size of our C# source files was driven by a JavaScript indenting preference or not, the point of interest is that one who wishes to embrace coding conventions must use the existing de facto conventions whenever available.

Philosophy aside, there are pragmatic arguments in support of this preference: the generally accepted convention has already produced zillions of C# files with a tab size of four characters. Upon integration into your projects, such source files will render with an indentation foreign to your conventions. Such files should be pervasive in source code attached to compiled external assemblies that your projects will undoubtedly use. (It seems that Visual Studio and the .NET compilers don't do such a good job of linking a compiled assembly to the original source code. I've had to create the NHibernate source code into C:\NHibernate before Visual Studio let me navigate it.)

Yes, some source files will have tabs and will, as a result, appear as having a tab size of three per your Visual Studio settings. But some won't. And, let's admit it, you don't really want to use the tab character for indentation anyway (a post is pending on this topic).

Yes, you may edit these source files in Visual Studio to force a reformatting of the code and thus a tab size of three. But you and I know you don't want to do that, not only because you don't have the time to do it, but also because you don't want the footprint of such changes in your version control system.

Another pragmatic argument takes shape in dynamic teams (who doesn't have them?). When a new member joins your team, chances are she is already acquainted to the de facto coding conventions. To require of her to stray from these rules is an additional, unnecessary effort.

Don't stray from the established conventions.