Is Manipulating the DOM for Presentation Acceptable?

Personally, I’m a big proponent of both progressive enhancement as well as graceful degradation (fault tolerance). While both concepts are similar in nature, they both possess small unique parts that set them apart.

To me, keeping graceful degradation in mind while developing will aim to leave you with a functioning document no matter the circumstances. Progressive enhancement on the other hand, is a level of functionality present only if the reader has the needed technology readily available. While it may seem that both are nearly identical, to me graceful degradation seems to be more passive in nature when comparing it to progressive enhancement, which is a more active. Progressively enhancing a document gives the ability to make alterations where applicable in an effort to make a document that much more useful, while graceful degradation is more of a fall back plan.

Separation of structure, style & behavior

At the root of Web standards comes the idea of keeping the structure, style, and behavior of a document separated by making use of (X)HTML, CSS, and JavaScript, respectively. While only a partial explanation of the idea behind Web standards, the separation is the basis for best practices and accepted techniques. By keeping these three facets separate, you’re able to produce work with a caliber of maintainability and organization that otherwise goes unmatched.

While keeping structure, style, and behavior apart is a generally accepted practice by professionals and amateurs alike, we’re constantly faced with solutions that blend the technologies together. There are many applications JavaScript which constantly make use of element.style or a comparable snippet which directly adjusts the rendered style of an element (or group of elements). Lots of developers don’t see any issue with something like this because your end product is the desired change. In my opinion, it’s easier for a designer to forget that the style and behavior of a document are being mixed simply due to the syntax of the JavaScript. It is less apparent the style is directly being manipulated.

When looking at this circumstance in more detail, it becomes apparent that directly editing the style of an element via JavaScript can be juxtaposed to using a set of font tags to set some text apart. In my opinion, a better way to handle something like this is to provide the element with a class as opposed to directly altering the rendered style. This way, the only edit made using the DOM is an element’s class, which is styled within the style sheet.

A more interesting situation

While directly changing the style of an element can be easily resolved, there are many circumstances which make a solution much more complicated. The combination of (X)HTML and CSS gives designers and developers a fantastic tool set to create amazing, accessible, standard websites. While many great things can be done with markup and style alone, there are many times a design needs to be brought to the next level. Whether it be a client request or an unforeseen hurdle during a design phase, there are certain times that (X)HTML and CSS aren’t going to provide everything needed by you as the designer or developer.

It is in those situations where JavaScript comes into play. As many pieces of JavaScript directly manipulate the style of an element, but the core purpose of using JavaScript is directly manipulating the structure of a document. Long ago this was accomplished using ugly instances of document.write, but that practice has been replaced by interaction with the DOM. DOM scripting is a much more effective way to use JavaScript in an effort to control the behavior of your document.

Using the DOM to prepare for your CSS

While many fantastic techniques have come from progressive enhancement through DOM scripting, there is an area of DOM scripting which I’ve become partially weary about implementing. This gray area comes about when JavaScript is used to manipulate the DOM for the sole purpose of achieving an effect otherwise unattainable using semantic (X)HTML and CSS. While the resulting markup is more than likely valid, after the application of JavaScript, it is bloated from additional nodes needed to achieve a desired effect.

I’m timid about using scripts such as these due to the fact that it seems as though you’re using the document behavior to alter the document structure for the sole purpose of styling the document differently. It is a bit of a gray area to me because while the structure, style, and behavior are still maintained separately, the resulting markup is bloated and has lost semantic value at the cost of adding a design element that is not otherwise possible.

Going back to the original dilemma of a project requirement, however, solving the issue using a solution such as this seems more favorable than including the bloat in the markup from the start. There has been an ongoing discussion regarding whether or not it’s required to provide valid and semantic markup when manipulating the DOM. In my opinion it goes without question that the integrity of a document should be maintained regardless. Simply because (many) search engines do not process JavaScript, you’re not given the liberty to do with the DOM what you please. Expanding upon that, just as important is maintaining semantic markup when manipulating the DOM. This is where things become shaky as far as my stance is concerned.

On one hand you are striving to include a design element keeping best practices in mind, but on the other hand your resulting markup (after interacting with the DOM) is anything but ideal. At this point, what is the solution? Is it better to neglect the issue as a whole and work with what you’ve got? Is a bit of code bloat while DOM scripting an issue that needs serious consideration?

Some time ago I was browsing the threads of a forum with a particular discussion being centered around proper markup used to create accessible forms. I took a minute to provide my opinion, which, at the time seemed to me like the best solution. The technique was using as little markup as possible in an effort to avoid code bloat, something I was working very hard to do in all cases. Shortly after, two developers whom I hold in high regard, offered their opinion on the matter explaining the faults in my suggestion and offering their own. The developers were Jonathan Snook and Kyle Neath, two people with opinions I greatly respect and use their writing to expand my own knowledge. Their solution called for a bit of extra markup, but the additions made sense in the overall structure of the document in consideration. Point being; not all additional markup can be labeled as bloat.

Some questions I’d like to discuss

I’ve got some questions for the community as a whole as a response to an issue such as this. First and foremost: do you feel this is an issue at all? Is it simply making effective use of accepted technologies to achieve results not otherwise possible? Is using the DOM to generate bloated documents for the purpose of more elaborate style taking things to an unacceptable level? As designers, should we only be allowed to work with the tools we’re given and leave design elements limited to what can be done with (X)HTML and CSS alone? What other opinions do you have on the matter?