implementing html
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.
back-end implementation
Before I was hired at my current job I worked for a firm where I had to do almost everything from start to finish (excluding design work). Database setup, html/css/javascript and back-end coding were done almost simultaneously. It's there I learned that doing all these things yourself will often compromise the quality of certain aspects. More than once I changed html code simply because it was easier to implement in the back-end.
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
As an html guy I spend quite some time tuning my html to deliver structurally and semantically correct documents with high level of flexibility towards future changes. I might add classes where I think they'll come in handy or where they are needed for semantic differentiation, even if that means I don't need them right away. It's not because a class has no direct function in css or javascript that it is useless and should be left out.
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.
concluding
The implementation of html is often checked by looking at a template in a browser. When the implementation matches the design it is often considered okay. While this might give an indication of an approximation of the html structure, it's hardly proof that they indeed match each other. I believe that css and javascript are not at all needed for implementing the html, maybe even a little counterproductive. When implementing html it is important that the output matches the structure of the static deliverables. This can not be seen by loading a page in a browser, but by comparing the html source of both the static and implemented page.
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.
More than wanting to dictate how others should do their job, I hope this article demonstrates the time and effort spent in coding html pages and the need for an implementation as close to the delivered templates as possible. People writing html often don't write it in function of styling (css) or functionalities (javascript) but have other/more priorities to take into account. So put a little trust in us, most of us know do what we are doing :)