Skip to main content or search

Front-End Architecture: Don't Change Styles in JavaScript

Monday September 18, 2006 / 10 Comments

As DOM Scripting becomes increasingly popular, so are some common bad practices. I’d like to formally declare that referencing an element’s style atribute via DOM Scripting is today’s equivalent of font tags or inline style attributes. It’s common knowledge that it’s bad practice to use the style attribute in our markup, so why are we still using it in our DOM Scripting?

<span style="color:red">Red Text</span>

...is something we know we should avoid at all costs, so why then are we still using the following in our DOM Scripting…

this.style.color='red'

Instead, our DOM Scripting should only maniuplate the class attribute, leaving the presentation and styling up to the CSS. This way, we’re keeping presentation completely separate from behavior and getting one step closer to the nirvana of loose coupling.

Naturally, to do this, what we need is a simple and reliable scripting library for manipulating the class attribute, and Christian Heilmann’s CSS Class Scanner Tool Set is just the thing for the job. So, let’s eliminate that one more dirty little practice and be on our way to better and cleaner code.

Featured Stuff - Resources: Wireframes & Page Description Diagrames

Omnigraffle and Visio versions of the wireframe templates and stencils I use on all of my projects. There’s even a few examples included for good measure. More about Wireframe & Page Description Diagram Stencils and Templates

I agree. It gives a good overview of the styles, and it’s easy to revert to previous states.

Raevel

i tried and tried to get this to work and couldn’t. then i tested it in IE and it gave me the big yellow bar at the top telling me it was blocking “active content” (this script being the only one in the page). wtcrap? have you used this yet? any luck?

daniel

Garrett, would you say this rule applies to hiding/showing elements? Using element.style.display is (from what I’ve seen) the usual way of doing this – switching to classes for this kinda feels like overkill.

Pat Allan

Pat – That’s probably the only grey area I can think of, but my default answer would be to avoid it unless it really made sense. Showing, hiding, and positioning can be related to behavior, and as such, it could make sense in some cases that the manipulation of those values is more related to the behavior layer than to the presentation layer. So it’s acceptable if done with discretion.

Garrett

Showing, hiding, and positioning can be related to behavior, and as such, it could make sense in some cases that the manipulation of those values is more related to the behavior layer than to the presentation layer.

Definitely – you shouldn’t tie yourself in knots trying to get floating pop-up Javascript windows positioned using CSS.

Matthew Pennell

I think one other exception would be animated size changes. For example, if you want a box to expand smoothly to its full size, there’s really no alternative to setting element.style.width and element.style.height, unless you load your CSS with rules for all possible sizes.

Nick Fitzsimons

Here, here!

But I agree with previous commentors – there’s still a place for manipulating display, width, height, x, y, from within the JavaScript (as this is where such new values would be calculated) – especially true for animations.

Adam

I personally believe both inline styling and DOM scripting are valid.
I also believe the dogma “avoid tables at all costs” has lead us to the wrong way of thinking, or rather to a misleading one.

Semantics is one thing, making things work using the methods built for that purpose, is another.

Defining classes, thus css declarations and/or files, just to avoid setting a style property explicitly leads to sanity, if you ask me.

To summarize: I had been in that path, using ugly css and markup to avoid tables, constructing classnames just to dom-apply em to avoid with (this.style) {} coding, yet I have come to believe that this is just wrong.

George E. Papadakis

Great point! The ASP.Net frontend post & this one. n.style.xxx isn’t “standard” either despite its support in the major browers.

J. Porter

One important point, that wasn’t mentioned explicitly, is that if you keep your JavaScript and CSS completely separated, you can very easily do dynamic print layouts. For example, the jQuery Tabs Plugin works natively with print layouts – simply because it uses CSS classes to hide-show page elements, rather than style.display.

John Resig

Comments are closed for this entry.