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.

So now you may be wondering: why do inline styles have such a bad rap? For one, you’re breaking the separation between style and structure. For two, they can’t be overridden. From least- to most-specific, it goes: class, element, element.class, element.class.class (and so on), ID, and in-line style. There is nothing more specific than an inline style.

More often than not, I find inline styles used as “band-aids.” It’s a quick fix to a bug or “I couldn’t figure out a better way.” But as with all structural band-aids, they’re good in the short term and bad in the long. The basic principle behind the ideological separation of church and state — I mean, style and structure — is that you can change one of them, entirely, without affecting the other. For a site redesign, you’d need only change the CSS and would be able to leave your markup (or whatever is generating your markup) alone. In the case where there are a bunch of inline styles, you now have to remove every single instance of them or mitigate them separately.

I’d made a joke in my first blog post that I took the MacGyver approach to coding — I meant this very loosely. While MacGyver could come up with a solution to any problem, he never meant for his death ray made of chewing gum, coat hangers and paperclips to last longer than it took to get rid of the bad guys. I’d like to think that if MacGyver were engineering something that was meant to last, that he’d spend some time using the proper materials and practices.

Realistically, the only situation that I can think of that you would, absolutely, need to use inline styles is if you were writing a blog post and wanted to do something really fancy; but even then, most blogs remove the ability to add markup to your posts.

So the moral of the story is: unless a group of bad guys tell you that they’re going to blow up a children’s hospital if you don’t write them a super-fancy post on their markup-enabled blog, don’t use inline styles. Inline styles are bad.

D.C. digital agency adds staff to meet demand, maintains recruiting efforts.

WASHINGTON, D.C. – Q-Industries, a digital marketing agency that develops online brands, websites and custom applications, is continuing its steady growth in 2009 – bringing on five new employees in response to a significant increase in customer demand.

In recent weeks, Q has added to its Client Services, Creative and Technical teams; Q is still seeking other experienced individuals interested in joining its group of smart, dedicated web professionals. If current trends hold, Q will more than double in size this fiscal year, further expanding its already-robust client base and customer offerings.

“The companies we work with tell us that in this challenging landscape, a full-service agency like Q has become even more essential to their success,” said Tim Neill, CEO of Q-Industries. “We pride ourselves on the great work that we do, and that wouldn’t be possible without our talented staff. I’m pleased to welcome our newest employees, who will join in our ongoing efforts to help our clients successfully navigate the constantly changing digital marketing space.”

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?

Brad Heidemann, Executive Vice President, Client Services

The bright lights gleam on every square inch of tile, glass and metal. Soft, soothing music wafts through the air. Each item on the shelves is perfectly positioned, as if awaiting a military inspection.

Your new store is now open for business, and there isn’t a single price tag out of place. But getting to this grand opening takes lots of hard work from a diverse team of retail professionals – buyers, merchandise managers, display managers, store managers, sales executives, et al. You wouldn’t think of constructing an expensive new brick-and-mortar store without their invaluable input.

But all too often retail companies – even quite successful ones – don’t employ the same attention to detail when building their online presence. Central to this costly misstep are thinking of a website launch as just a technology project – not a sales or brand development project – and tackling it without input from the people who painstakingly craft, and protect, that in-store experience.

Stacey Berry, Manager, Analysis and Quality Control

Ready… Set… Go…

They’re the three words we all heard in elementary school when preparing to run a foot race. No one questioned them. Well, almost no one. There was always that one kid who everyone knew was a cheater, who just yelled “go,” but for the most part, we were all OK with “ready,” “set” and “go,” right?

Those three words gave everyone a chance to understand that the race was about to start, to position themselves however they felt would give them the advantage, and then to race. And yet, too many of us seemed anxious to be that kid that just hollered “go” and cheated everyone else running the race.

Yes, web development projects are races of sorts. We might not be competing. And they’re more of a relay; we’re on the same team. But we can’t run the race effectively if we’re not all ready and set for the race to begin.