The W3C specifications are sound; in most cases, but they are incomplete. Therefore, there exists a lot of room for interpretation when it comes to Web site development.
Allow me to start with a common recurring issue; with respect to today's W3C specifications and whether or not they are in-line with how we want our Web documents to function, it is all part of natural progress. For instance, tables for layout were okay to use in the 90s because they did the job at the end of the day (relatively speaking), however, today, depending on needs, we most likely can't say the same for table based layouts. Today, floats for layout is considered to offer the most viable solution. However looking at where CSS3 is heading and even the Markup structures, float based designs most likely will not be 'the' layout solution for tomorrow's Web.
If the Consortium's recommendations are always in an evolutionary process, how then are we to develop sites? Let me put it this way; today's competitive sites - in the interest of getting attention - are constantly in change. Whether they are presenting cutting or bleeding edge technologies in the field or simply even on the Web to have presence, to some extent, they require updates and maintenance. Realistically speaking, those sites that fall into these categories are in need of an update at most every 3 years (take this number with a grain of salt) by today's standards.
So then based on this important bottom line, can we raise the following conjecture; design for today and the very near future if resources allow as such.
Now you may be saying, what about... ya but.. so? The point is to accommodate for today's needs and not to worry about the tidbits of development as if it were to be a one time solution for the next 10 or 100 years to come. If you are in the Webdev business and interested in this field for many years to come, then allow me to suggest; do not worry. The Web is constantly evolving and at this far in the game, the Web as you know it will not be the same in 5, 10 or any x number of years. I am perhaps stating something very obvious here, yet it is apparent that it is widely overlooked. On the other hand, it is essential to keep this in mind: how costly will it be to bring today's documents up to speed in 5 years - facing extensibility? The answer is hidden within compromising among possible solutions from the marketability standpoint.
If you love this art form, do know the specifications well as it suits your needs, yet at the same time do acknowledge its shortcomings and the very nature of Web's evolvement. I tell you, this is the compromising I speak of when you have to get things done. These technologies are merely tools, and they are here to help us with our work. One must not go the other way around by altering the requirements of their projects just to satisfy incomplete specifications.
There is a good chunk of developers out there that takes pride in doing things the right way. The very nature of this mentality exist for two reasons. First being the separation of the level of their competency from the rest of the developers that do not or in-need to follow the best practices. This can essentially open up many opportunities as they may seem to better fit to take on projects then the other developers. Who is to question then for such accomplishment if they are certainly more equipped to do the job well? However, there remains one important point; being technically savvy is not always in positive correlation with having good business sense.
Secondly, there seems to exists a rush to being the purist when it comes to the W3C recommendations. The Standards developers can then only show their competency among other developers whom already follow the good practices. By this, there exists a perception of being more competent then the average good developer, yet overlooking the core project goals. For instance, many Web standards designers can push their knowledge and proper way of applying the W3C documents, yet neglect to apply them in the right places. For small scale, personal, focused target audience sites, this idealistic approach will do wonders and allow them to achieve the most respect within the community, yet the same practices in which they preach of do not necessarily play well with all the complexities of sites where the user base, scope, and the goals of the site vary.
May we remind ourselves that the W3C's specifications are only recommendations? Perhaps it should have been termed differently like; rules or laws, in which the resulting practices would possibly have been different. I personally tend to think of them as good guidelines. If they make sense to you for your real-world development then who is to stop you from using them? Not to mention most of the established specifications have been through a lot of revision by many people, groups, and organizations to push them forward to suit the needs of today's and future's Web. A lot of resources have already been allocated and used on establishing such practices and it would be foolish in my opinion to not take advantage of this but to integrate them in our work. In most cases, they are beneficial to us.
What I'm trying to say is, use your best judgment when it comes to W3C and other Web technologies, and make the best out of what's suitable to your needs. Thank you for reading.