Wednesday Aug 08, 2007

Front-End Quiz Part 4, CLASS and ID attributes

What are the purposes of the class and id attributes?

  1. Presentational hints for CSS, for example <span class="green"> and <div id="leftcolumn">.

    Not a very good approach, IMO. This is the classic mistake of mixing content and presentation. For example, if you want to switch to "orange" instead of "green," then your CSS will have to change from{color:green} to{color:orange}, which is, well... weird.

  2. General-purpose semantic hints, for example <p class="warning"> and <div id="nav">.

    I overwhelmingly prefer this approach. This allows the utmost flexibility in evolving the presentation and behavior layers independently of the content, plus it has a self-documenting effect on the HTML source code.

  3. To replace outmoded HTML tags, for example <div class="heading"> instead of <h1>.

    Run away! Run away! I hesitate to say that any one development approach is evil, but this comes close. HTML elements such as <h1> have a structural meaning used by search indexers and user agents of all kinds. Breaking away from all but ultra-generic generic <div> and <span> tags breaks searchability and accessibility, as well as the ability to meaningfully syndicate your content via RSS or Atom. It prevents use of your content in ways that you don't anticipate, and in contexts that you might not have considered.

Wednesday Aug 01, 2007

Front-End Quiz Part 3, Adding Events to Elements

What's the best way to add JavaScript "onclick" event behavior to a link?

  1. Add an onclick="" attribute to the <a> tag.

    My opinion: this is a nasty, outdated way of doing things that needs to be euthanized ASAP. It's the most prevalent method as of 2007, but mixing scripting commands with HTML is just as bad as mixing presentational commands with HTML, and for the same reasons. Presentation should be removed from content via external CSS files, and behavior should be removed from content via external JavaScript files. Even if it seems justifiable to throw in a quick onclick="" attribute for convenience's sake, it risks getting accidentally overwritten by more sophisticated event attachment methods that deploy via external scripts.

  2. In a script, use document.getElementById("someId").onclick = function() { ... }

    Better, but still nasty, IMO. This method is a vast improvement over inline event handler attributes such as <a onclick="">, but it still only lets you assign one event handler per element, and succumbs to the common problem of events being accidently overwritten, since there is only a single onclick property per element.

  3. Use event attachment, preferably via some kind of event library that abstracts away browser differences.

    My personal favorite. Event attachment lets you assign an arbitrary number of events to the same element. This is especially useful for the window "onload" event, which often needs to spawn multiple actions.

Wednesday Jul 25, 2007

Front-End Quiz Part 2, The Philosophy of JavaScript

What is the underlying philosophy of JavaScript? (As used on the web)

  1. As a way to add interactivity to a page, as opposed to HTML alone, which is static.

    I think this is only partially true. The problem is, as a philosophy, "to add interactivity" doesn't go to the root of the issue. This definition, however, is a sufficient one for those not involved in architecting the front-end.

  2. JavaScript defines the behavior layer.

    This is where I set up camp. This way of thinking about JavaScript is now emerging as the Way of Enlightenment, often dubbed "Unobtrusive JavaScript." The web consists of three layers: Content, Presentation and Behavior. These correspond to HTML, CSS and JavaScript, and it's best to keep them separate, living in separate files. The HTML layer is considered the base-functionality layer, and the other layers are considered the enhancement layers. It's a very elegant paradigm.

  3. As a client-side programming language, as opposed to a server-side language.

    True, but it doesn't really get us anywhere. While not incorrect, I don't think this distinction is the most significant or useful way of thinking about JavaScript. Perhaps this definition is popular because many programmers code mainly for the server, and tend to contemplate JavaScript in comparison to that task.

Wednesday Jul 18, 2007

Test your Knowledge about Front-End Web Architecture

Here are some questions about front-end web architecture to test your knowledge of the craft. Sometimes the answers are fuzzy, so I'll throw out a few possible answers in quiz form, and then give my opinion about what I think the correct answers are and what my reasoning is. Feel free to disagree!

What is the underlying philosophy of CSS?

  1. To distill out the presentation layer so the markup can focus on content.

    As I see it, this is the underlying philosophy of CSS. With CSS managing the details of the presentation, HTML can shed the presentational encrustation it developed during the browser wars, making it more concise and powerful. There's a term for this: Plain Old Semantic HTML, or POSH for short. POSH is easy to produce, maintain, style and script against.

  2. Because HTML turned out to be a horrible presentation language.

    Yes, but I'd clarify this one thing: HTML wasn't supposed to be a visual formatting language in the first place. In fact, the world's first web browser, which Tim Berners-Lee wrote in 1991, actually used stylesheets for the specific purpose of handling presentation. Subsequently, HTML got hacked into the role of handling the presentation during the tumultuous early evolution of the web.

  3. To give visual designers better control over a website's look and feel.

    I would somewhat disagree with this for a couple of reasons. A) CSS was meant to control presentation in more than just visual media. For example it can control Aural and Braille presentations. The visual (screen) medium just happens to be the most widely-adopted way of using CSS. B) CSS doesn't necessarily give better control, so much as a better means of control. For better control, we'll have to wait for future versions of CSS to be finalized by the W3C and implemented by browsers.

  4. So visual designers wouldn't have to muck around with HTML.

    I would disagree with this. In my experience, if a visual designer is writing CSS, they must understand HTML on a very deep level, and will almost certainly have to muck with the HTML. If, on the other hand, a visual designer is just designing in Photoshop and handing off bitmap comps to front-enders, then CSS is irrelevant to the visual designer anyway.

Tuesday Jan 02, 2007

How this Blog Design was Created

I decided to go the total web-standards-nerd route in creating this blog design. Semantic HTML, source-order, accessibility, and unobtrusive JavaScript were all factors from the outset.

The first thing I did was to customize the "Basic" theme. This gave me a starting point. I removed all presentational information, starting with the CSS code. Then I went through the HTML and removed presentational hints. For example, layout tables, <center> tags, &nbsp; characters, etc. Even things like class="left-bar" had to go. "Left" is too presentational, and I relaced it with "sidebar," since it might be argued that "sidebar" is a semantic hint. (Yes, that's how much of a nerd I am.) Fortunately there wasn't much presentation baked into the HTML to start with, because most Roller themes are pretty good about separating content and style.

Next to go was JavaScript. I had just removed the presentational layer, and now it was time to remove the behavioral layer. These layers would be added back in later via external files, once the HTML-only blog was proved working.

Wherever possible, I made the HTML as semantic as possible; selecting and organizing tags elements by meaning and structure. Source-order sensibilities were used, placing more important things higher in the source code. Headings/sections were arranged such that if you removed all but the headings (<h1> - <h6>) you'd get an outline of the page. <p> was used to contain all logical fragments of text. <div> was used to delimit sections. <ul> was used to build lists. It turns out, semantic HTML is really pretty brainless and straightforward, once you yank out presentational noise.

Once the blog was purified, it was boring-looking, but usable. No columns, just black Times New Roman text that strung all the way across the browser screen on a white background, with blue hyperlinks. It was nekkid! Time for some clothes. An empty CSS file was <link>ed to the blog, which I began populating, resulting in the current design.

As you may know, it's easy to do CSS design in Firefox, Opera and Safari, all of which understand and render CSS beautifully. But then you inevitably have to do battle with IE. Most designers approach the IE problem by peppering their CSS file with hacks. Hacks are oddly structured CSS commands that, due to IE bugs, either can't be understood by IE or can only be understood by IE. Instead of doing this, I used conditional comments to load corrective stylesheets into just IE. Conditional comments are an IE-only feature that look like regular HTML <!-- --> comments to real HTML parsers, but have special meaning to IE. This way, I was able to quarantine IE-specific bigfixes to a couple small, IE-specific files.

Friday Dec 15, 2006

Blog Redesign!

I've redesigned my weblog. I've always wanted to do it, but Roller's templating and theme system was too daunting. It's easy to tamper with the HTML your blog generates, but as a web designer by trade, I wanted total control over the HTML, CSS and JavaScript. Alas, lots of HTML-generation happens deep within Roller-specific Velocimacros that you have no obvious control over. So, if you really want control, you have to get intimate with Roller. You have to have its babies and cook it three square meals a day, and not complain when it doesn't want to cuddle. Gritting my teeth, that's what I finally did, and this is our love child.


My name is Greg Reimer and I'm a web technologist for the Sun.COM web design team.


« June 2016