I’m a taxonomy hawk. I’m a really big believer of the notion that time spent on straightening out confusing terminology is time wasted. As my thoughts have gone to the ageless debate between Flash and HTML, I’ve come to the conclusion that part of the issue of the debate is that we have two groups of people that aren’t doing the same thing, attempting to say each other is doing it wrong. We need a better definition than Flash camp and HTML camp, because that’s inaccurate.

As my colleague Matt Kenefick explains, there are two layers to a web site (besides content): Structure and Presentation. Structure is constant — no matter what page you build, regardless of plugin, stuff that reads your web page — users, search engines, bots, screen readers — looks to the HTML for what is and isn’t important. Presentation is some combination of style and script, which can be done either with native browser tools (CSS and JavaScript), plugins (Flash, Silverlight, Unity) or a combination of both. This is the foundation of the principle Big Spaceship stands behind: That it doesn’t matter what you choose to build in, so long as the user gets a positive experience.

(Structure/Presentation layers diagram — original image no longer available.)

The issue is that it seems the vast majority of the industry is confused about this simple principle. And I believe this stems from the fact that we’re confused about what we do and who we are.

Separate of specific skillsets (like Photoshop or PHP or ActionScript or Facebook Connect) is that there are effectively two kinds of people claiming to “program” or “script” the web — those who prefer standards and those who don’t. I propose that the title of programmer should really be reserved for those who program. Programming is the idea of sending instructions to the computer to be interpreted into executing a specific task. This is vastly different than manipulating an existing computer program. That would be like saying you’re a programmer if you know how to remove red eyes from wedding photos. Sure, that’s great, but did you write the application that executed that task or simply push a few hot keys?

In other words, if the crux of the Flash/HTML debate is a misunderstanding of what these layers inherently are then we need to define ourselves as experts in specific layers… and then work to understand each better. My hope here isn’t to offend anyone with nomenclature, but to simply put a box around what we are and break down the boxes of what we’re not.

With that said, let’s start with this bombshell: CSS and HTML are not programming. They’re closer to the red eye removal, actually. Your browser is the thing doing all the work. Take background-repeat. You didn’t tell the image to magically replicate itself, the browser interpreted your style and did the calculations for you. That’s okay… in fact, better than that. It makes building web sites fantastically accessible to lots of people, which is extraordinarily empowering. Web browsers interpret a special kind of XML called HTML and a special way of mapping certain node attributes into graphics. The img tag doesn’t load in an image, the web browser interprets that img tag and display it. So again: Background-repeat is great. But it isn’t programming.

Instead, I would propose that those who are comfortable with CSS and HTML define themselves as semantic designers,. If you consider yourself a semantic designer, you’re good at structure and style using native browser tools.

JavaScript is programming… but at a very high level. It’s designed to only manipulate the existing structure and style of a page. This is potent enough to turn web sites into full fledged applications, but it’s ease and power is also it’s weakness… it’s an extremely simplistic language that leaves out a lot of virtually every other programming language is capable of doing. JavaScript’s capabilities stop well short of the top of the food pyramid of coder knowledge. It’s an easy language to learn and master, which is critical to the viability of building pages, but comes at the cost of making things hard to write well.

If you consider yourself an expert in JavaScript, call youself a semantic developer.

Good at both? Great, let’s call you a pro in web semantics.

Now if you know what an object is and what it’s doing, feel comfortable with words like instantiate and constructor, and don’t flinch at terms like the Factory, Facade, MVC, if you feel alright with HTTP Request Headers and error codes, know what a crontab is and can write one… then you can feel okay calling yourself a programmer, coder, developer or whatever.

But what about if you understand the Flash timeline and motion really well, but don’t feel as solid with semantic design, development or programming? Comfortable call yourself strong at motion design and that’s just fine with me. The truth of the matter is you’d probably pick up After Effects and other assorted motion tools in a hot minute anyway.

The key to recontextualizing our specific skill-sets is that motion designers should understand semantic design up and down… it’s way easier to learn CSS than it is to learn timeline animation. Programmers have no excuse not to be fantastic at web semantics, even if they can’t outright design themselves. Semantic designers should by their nature want to learn more about motion, as the fourth dimension can add a world of context to user experience when used appropriately, and semantic developers should strive to become programmers because it’s the natural progression of their trade. In other words, we all have room to grow and improve.

Note: This post was originally published on jamie.kosoy.net in 2010.