Building Web UIs

So my new job has been keeping me very busy, which is why I haven’t written a post in a long time. However, since I have a little extra time during these Christmas holidays, I’ve decided to write a little post about some UI coding principles I now embrace. This mostly pertains to HTML\Javascript\CSS. The over-arching philosophy for this is a seperation of interests similar to MVC, but just on the view side things. Whenever possible, I try to use JavaScript for UI functionality: events, calculations, loading (ajax), ui logic, etc.; As for anything visible, I try to use HTML and CSS. Within the HTML\CSS, the common theme is “state” over “style.” Style only lives inside CSS classes.

Embracing CSS3

No more jQuery (and other js) animations. Sure CSS3 transitions aren’t supported by older browsers, but screw ’em. If you’re using IE8,7,6 you’ve got to get used to a crappy experience. Perhaps it’ll force some people to switch to modern browsers.

Embracing CSS Classes over Manipulation of Inline Styles with JS

No more jQuery (and other js) show, hide, toggle… Anytime that I want to display or hide something now on the UI, I add or remove a class that does just that. Why? There are several reasons. To display something or not is not necessarily a question functionality as it is a question of styling. Imagine you have an application that hides all the unavailable products from a list. The choice of “hiding” products to illustrate the unavailability is styling choice. It’s much better to add a class to all the unavailable items with a display:none style, than to let JS do it inline. So now when the UI designer comes back to you to say, “Actually we would like display and to put a strike-through all the unavailable items,” all you have to do is edit the CSS.

  • Gives you complete control on HOW to hide\show elements. (Is there are fade out to that hide? Is there an empty space there? When displayed is it in-line, block…)
  • Hide\show is just a visual state, which is much better controlled through CSS.
  • It’s generally good practice (every web-dev will tell you that in-line styles suck).
  • Seperation of functionality from design
  • Notable exception: When you need to update elements interactively (and very often) like the library jQuery library Isotope.

No Generic CSS Classes For Simple Shit

This drives me nut: “fl” class for float left, “hide” for display none, “show” for display block. Why? Because this is no better than in-line styles. What’s the difference between <div class=”fl”> and <div style=”float: left”>  (other than the first being more taxing on the browser)?  You lose all the benefits mentioned above. The chances are the “hide” class will be used in hundreds of places, so you will lose all control of any single element or logical group of elements. You can’t just change the style of the “hide” class to line-through because it’ll mess everything up! And for me, it’s much better to edit the CSS than the HTML.

Note, that this does not mean that you can’t have generic logical classes. You can most definitely have a class called, “emphasis,” which will MOSTLY be used as a font-weight: bold style. But do you see the difference? “Emphasis” describes the state and not the visual representation of that state. Perhaps emphasis in some element or with some class will look completely different. That is, “.funny.emphasis” might not be bold but some funny font. This brings us to the next topic.

Name Classes After their State

I like classes to describe the business logic whenever possible. If you have a list of products with unavailable ones hidden, it’s much better to name the class that hides them as “unavailable” than “hidden.” Why? Because “unavailable” describes their state, while “hidden” describes their style. When the style of their state changes, you’ll have silly (in-descriptive) class names. If you want to strike-through unavailable items, it’s much better to put that style in a “unavailable” class than a “hidden” class. You can, of course edit the HTML as well, but we’re lazy programmers–we either won’t do it, or we won’t want to. Plus, why create extra work?

Use Id as JS Selectors and Class as Style Selectors

In general, I don’t like to ever see the “#” symbol in my CSS. If necessary, I don’t mind duplicating the id name as a class name (<div id=”submit-form” class=”submit-form” >). This is a personal preference to some extent, but mostly it helps to remind me to make styles specific to the function\state and not to one single element. The chances are the “submit-form” could have had a better CSS class that might be re-used; perhaps a “submit-button” class. There are rare times that styles will be very specific to an element, which is fine to use the Id selector, but I still choose not to.

Similarly, unless I’m selecting multiple items in JS, I try to use their Id tags. Instead of querying some complicated CSS selector that only selects one item anyway, I simply add an id to it and select it that way. Not only is this easier on the browser, but it also makes your code more logical and readable.

HTML as Simple as Necessary, not Simpler

I’ve seen HTML code on both sides of this spectrum. On the one hand, I’ve seen nested elements within nested elements until the comes come home, but on the other side of the spectrum, I’ve seen logical visible units with no tags around them. To get this right, it takes a little practice, but the idea is that your HTML code should be logical to the view it displays, and other elements shouldn’t control the look and feel of some other logical visible unit. For example, it’s bad to rely on some in-line div to control location\spacing of some non-tagged text next-to it. Remember spacer gifs from the 90s?

Achieving this princes is usually evident by the minimal use of absolute and fixed, by grouping visual elements into logical units, and readable HTML\CSS code. If, without loading the page in a browser, I can look at the HTML and CSS and guess accurately as to how it may look, then I know it’s a well written UI.

No Inline HTML Strings in JS

I just hate to see HTML code inside a string var. It’s prone to error, you have no fine grained control, you have to worry about escaping special characters, you can’t do anything with it, and it sucks! Just don’t do it. Ever. You can either construct the element with pure JS, or the JS library you’re using. EVERY library I have experience with has an element constructor: jQuery, Google Closure, MooTools, Prototype…


In general, when building a UI, first ask yourself: can this task be decoupled into functionality and display? If so, put the functionality into the JS and the styling into the HTML\CSS. Next, when doing the styling, ask yourself, “is this styling actually a state?” If it’s a state, find a way to represent it accurately and as close to the business logic as possible. Then, style it.

I know all this is very high level, but I will have more concrete examples in the future.


Leave a Reply

Your email address will not be published. Required fields are marked *