Wednesday Aug 15, 2007

Front-End Quiz Part 5, Users who Disable JavaScript

What's the best approach for dealing with the approximately 7 - 10% of visitors who disable JavaScript?

  1. Preemptively send them to a sorry, but you must activate JavaScript in order to use this site screen.

    Not a good way to make friends. This is like saying, "go away, we don't want you" or, "we only want 93% uptime for our website." I think the business case for this is rare indeed.

  2. Condition your plan on building it to work without JavaScript, then use JavaScript as an enhancement.

    I like this approach the best. This is known as the "progressive enhancement" method, and it's the best way to build bullet-proof websites in the modern age.

  3. For each feature needing JavaScript, use an inline this feature requires JavaScript <noscript> section.

    Still not very friendly. This is marginally better than blocking access to the whole site.

  4. Place a block of alternative content in a <noscript> section containing equivalent functionality.

    Workable, but inefficient. <noscript> functionality is really a suboptimal solution, since it requires you to basically code your functionality into the page twice.

  5. Just let certain features break, it's not really that big a deal.

    Possibly confusing. Not only do visitors not get the functionality they were looking for, now they're confused as well, without any explanation of why it won't work.

  6. Avoid using JavaScript in the first place.

    Maybe not the best, but it's an option. JavaScript offers a lot of capability that has come to be expected on the web. Your site might seem outdated without it.

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.

Thursday Jan 18, 2007

HTML class attributes aren't just for CSS

HTML's class attribute was meant to be used in several ways, not just as a CSS tie-in. According to the HTML spec, class attributes are a general-purpose semantic hint. Here's an example of such a usage:

<div class="calendar">

There are at least three ways classes are useful outside the CSS context:

  1. They make HTML structurally self-documenting. HTML is fairly generic. Classes allow you to specify the meaning of various parts of your document, making it easier for yourself and others to unravel its meaning in the future.

  2. They serve as triggers for unobtrusive JavaScript. Now that hard-coded event attributes are dying off, class attributes allow JavaScript to dynamically select and operate on various parts of the document.

  3. Classes are a key part of microformats, which allow online tools to extract meaning from HTML code. Being plain old snippets of HTML, microformats are readable by humans using browsers. But because they're built in a standardized way, they can also be understood by software.


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


« June 2016