Jeremy Hilts, Technical Lead

The Web has come a long way since the dark ages of Lynx. There are an infinite number of designs out there and an infinite number of ways to implement and integrate those designs. We have Information Architects trying to make order out of the chaos, designers trying to make it look interesting, and developers trying to make it go.

If the multitude of browsers and operating systems weren’t enough to give a front-end developer a headache, add in the mobile platform and it’s enough to give one a serious migraine — you know, the kind that leads you to a doctor for something that makes your head disappear. At that point, it becomes a delicate balancing act between the flashy and the sturdy.

Our lesson for today, kids, is graceful degradation and progressive enhancement — i.e. “How can I make my website sturdy enough not to fall apart when technologies do?” Unfortunately, this is not an easy question to answer. The first step to graceful degradation is solid contextual markup; if you can disable CSS and still have a usable site, then you’re one step closer to graceful degradation.

Progressive enhancement usually comes into play with the addition of technologies such as Javascript and Flash. Many of the effects experienced on websites are due to Javascript. With the introduction and standardization of CSS, a portion of that Javascript isn’t needed anymore. I remember writing Javascript for image mouse-overs a long time ago; now all you need is the ‘:hover’ pseudo-class. If you can keep as much of the fancy stuff in CSS as possible, you can provide a lot of interactivity to those with Javascript disabled. And when Javascript is enabled, that’s when the real show begins.

We’ve had a number of discussions around the office recently regarding Flash’s place in an interactive website. For my money, I’d say that Flash should be used as a visual enhancement, a non-integral visual centerpiece or a technological extension (a video player, for example). There are a number of Flash-only websites out there; they’re pretty, but are rendered useless by an older machine or an office worker who doesn’t have the rights to install Flash. I could mention a number of websites that I avoid simply because the fancy-pants Flash advertisements make my dated machine come to a screeching halt. Not to mention that most mobile platforms, currently, do not support it.

Am I saying that Flash shouldn’t be used for building a site? Well, no — but there are plenty of ways to use it in a progressive manner while not forgetting about us rockin’ an old-school PC. I’ve seen a few websites using Flash that will simply read an actual website and enhance it accordingly. If one isn’t using Flash, one can still see everything that the website has to offer; that way, the site isn’t killing an entire section of the owner’s market share… or fan base… or whatever audience they’re looking to find.

Someone will probably hit me for saying this, but Flash reminds me of the <blink> tag. A long, long time ago, in a state far far away, I took an HTML class. Lesson #1 of that class was: if you use the <blink> tag, you instantly fail the class. “Websites should not act until an action is requested,” the teacher often said. However, that’s a dated philosophy — much like “Children should not speak unless spoken to”.

I believe that there is a Zen approach to structure and interactivity, form and function. So developers, hug a designer; designers, hug a developer. Take a deep breath, ‘cuz it’s gonna be a bumpy ride as we move forward in the direction of interactive designs. And that’s our lesson for today.

Jeremy Hilts, Web Developer

I’ve said it before and I’ll say it again: inline styles are bad. Mmkay?

Hey, I know what you’re thinking … if you’re allowed to do it, how can it be bad? Just because you won’t go to jail for cutting your toe off doesn’t mean you should be cutting your toes off. Do you remember our conversation about IDs being too specific? Same thing. Except worse. Much worse.

In any situation where an ID has been used and needs to be overridden, you could always use more IDs or a later definition of the same selector. Basically, “#big_section #small_section” is more specific than “#small_selection”; but if you don’t have “#big_section” you could always define “#small section” in a second CSS file or later in the same CSS file. Granted, I can’t think of any good reason to have the same selector twice in the same file, but it’s still possible. A later definition, top-to-bottom, of an equivalent selector is always more specific.

Jeremy Hilts, Web Developer

Sorry, this is not a Freudian debate on whether or not primal instincts have a place in modern society. That’s in the classroom down the hall…

In the world of XHTML and CSS, when should you use an ID and when should you use a class? I’ve heard this debate many times. In one particular instance, this decision is made for you: ASP.NET. If you’re using .NET, IDs are heavily used by the back end; if you need to style an element, it’s much easier to give it a class than it is to figure out what the ClientID will end up being.

Some believe that IDs should never be used when styling a website. Why would anyone disapprove of the use of IDs? The fact is: it’s just too specific. But wait! Isn’t it good to be specific?

Jeremy Hilts, Web Developer

The recent Cherry Blossom Festival here in D.C. really got me thinking about aspects of good design. A couple of weekends ago, I dug out my trusty Canon SLR and went to town. Granted, the only thing that ever comes of my photography is some new wallpaper for my work computer; but the experience is always half the fun.

As far as design relates to my particular trade, there are usually two schools of thought that go into it: the front-end design and the back-end design. Either of these two things can make for a really good site, or a maintenance disaster. Among Q’s developers, there’s a lot of talk about a term that I’d never heard before I worked here: “technical debt.” The idea is, simply, that if it was a nightmare to make, it’ll probably be a nightmare to maintain.

There are a handful of XHTML/CSS “gurus” around the office, and technical debt often falls in as a topic for discussion – things like proper use of HTML tags, IDs vs. class names, and browser-specific selectors. I find that browser compatibility becomes less of an issue the better formed your XHTML markup and CSS is; however, certain browsers will always be a nightmare (*cough*IE6*cough*).