25 October 2010 ~ Comments Off on The sad state of HTML rendering

The sad state of HTML rendering

I have been spending a fair chunk of my free time over the last several months working on a side project, where one of the fundamental ideas is to improve the ease with which HTML templates can be used, customized and manipulated.

While working on this new type of template system I have come to realize how far away PHP, and for that matter most other web scripting languages have leaned away from their roots, and in the process completely and utterly destroyed the power of HTML.

I can’t put my finger on why, when, or how it happened, but programmers have managed to wrestle HTML away from designers to the detriment of all involved. I have seen very few programmers produce a beautiful design on their own. Most of us are happy once we have a nice looking and functional wire frame that people can click through to see our application in action. Designers are a hugely important part of the process, and I can’t understand why programmers have let it get to a point where designers are unable to pursue their art unimpeded.

Web scripting languages ARE template systems. They have been leveraged for much more powerful uses, but their most powerful feature is, more often than not, short circuited with an additional layer of template functionality, or worse, an HTML generation library.

If I was a designer, and I was editing an HTML template, and I had to write PHP code to echo an <input> tag I would be totally confused. In fact, I often find myself in this situation of my own doing, and it really makes no sense. Think about it for a minute. You are editing an HTML template, and you are telling PHP to echo a tag which is generated by a library instead of just typing it. The standard reasoning is that there is “lots of complex stuff” going on behind the scenes to handle rendering that tag just perfectly and with the proper values initialized, etc.

My current view on this reasoning is that it is laziness and fear. Lazy, because programmers don’t want to type HTML, they want to “spit it out” and have absolute control over the result. Fear, because they can’t stand the thought of designers possibly breaking their code. I am actually one of these people, and these are valid issues, but I don’t like it because you are forcing designers to become programmers. I don’t ever again want to have to explain to a designer why his template is broken because he can’t understand the difference between printf and sprintf.

Looking back on my 15 years of web development, I can honestly say that generating HTML with a library has caused me more harm that good. In the end, you are a slave to the library, because now the designers rely on YOU to help them design. Every time you build HTML into a string and output it, you own that part of the design. Fighting with designers over changes to code because they need these changes in order to do their job, is no fun for either side, and nobody ever gets what they really want.

I am dreaming of a new way for designers to do what they do, where the application does what it is intended to do: serve the interface! Notice I did not say “generate,” I said “serve.” The interface is of course the interwoven yarns of design and feature. The application’s job is to process data from, and return data to the interface. There should be no barriers put in place by the application between the execution of the features and the design.

Its comical looking back at all the arguments I have made for the separation of business and data logic from the view, and solved this problem by taking control of the interface rendering with bloated template engines and other complex strategies that ultimately made the application less agile, slower, and harder to maintain.

Web scripting needs to get back to its roots, as an enhancement to SGML/XML (and eventually HTML5) documents, and not a generator of markup.

Comments are closed.