Specialization has made our trade a lot harder. Just 10 years ago it was still possible to make a quality site by yourself, today you need to take into account accessibility, strategy, content structures, browser compatibility, usability, flexibility and scalability. In all of these fields you will find people with specialized skills, but getting all of them on the same line isn't always easy. This article will dig a little deeper into the relationship between the html guy and the people implementing the html and how to improve it.
Key to a successful project is making sure the next node in line has a good understanding of what it is you just handed them. As a html and css guy I have to put my trust in the wireframers and designers. Whatever they give to me should be considered as their ultimate attempt at excellence. Of course, within whatever constraints the project is dictating (time, money, meddling clients, ...). My job is to honor their work as best as possible without hurting the goals and constraints I have to deal with.
After I finish my work the same process is repeated. I deliver static templates to the technical implementation team, which in their turn has to sculpt it into a working, living and breathing website. From experience I have learned this isn't always an easy process and based on the feedback I've been getting, similar questions keep popping up. Reason enough to take a good look at what the exact problems are we are facing.
This has a serious impact on the quality of the final product, though at the same time I realize that the decision between fixing an error in the price calculation or adding a seemingly useless class to the html is an easy one to make. What I suggest is rather than forcing such decisions it would be much better to eliminate the need for these kind of dilemmas.
the invisibility cloak
While it is quite easy to explain the importance of css, it's usually a lot harder to do the same for html. The reason is simple: html is hardly visible. There is no way you could say anything about the quality of the html by using a website or by looking at it. The cleanest and brightest html can come of as ugly when the css or back-end is badly implemented. Similarly, the crappiest html can look shiny and impressive when viewed in a browser.
Only a couple of fringe cases will ever get a glimpse of the quality of your html. People using assistive technology or people browsing with css disabled is one such case. Then there are automated scripts and programs interpreting your html page and finally the quality of the html might show itself as the level of flexibility when a website needs a visual tune-up. Especially this third issue is key to the consistent quality of your project over time.
These cases are often somewhat ignored in the pre-launch testing phase, of course that doesn't mean that the quality of the html should be a low-priority issue and should suffer from it.
we, the html guys
It's for the same reason I don't like extra classes generated by automated back-end systems (often CMS systems) because they can clash with the current or future implementations and mess up the clarity of the html. I also don't like structural differences even when they don't impact the visual output. Simply because structural relevance is very important for flexibility. When elements on a page belong together there's a very real possibility that one point they will be visualized as such.
This is what htmlers worry about. This is where our expertise lies and this is where we hope to earn people's trust. It is a difficult task as it's not easy to come up with direct proof of how important the quality of our work really is, but nonetheless the html remains one of the most essential parts of a web page. Without html, almost nothing can exist in a browser window.
I believe that it would be helpful to have someone in the implementation team responsible for the correct implementation of html templates. As far as I know this isn't a standard profile nowadays, with every person part of the implementation team writing both programming logic and implementing the html code. It is perfectly normal that this setup puts most of the weight on the programming logic rather than on the html implementation, which often nullifies a lot of the work put into our html.