OOP and Fitting JS into CSS/HTML, a Thought Experiment
Recently I've been thinking about how website design could be cleaner and clearer. My brain is wired for Java and OOP development, so I couldn't help but think that maybe an actual object oriented approach would be far better than what exists now --functional manipulators of a single DOM object.
We already have this idea of "classes", thanks to CSS and how it interacts with HTML. Future specs of javascript (and many current js libraries) already include a getElementsByClass function that work with this as well as the getElementsById that already exists.
So we're already to an extent treating these elements as "instances" (with a unique ID in the DOM) of one or more "Classes". So why doesn't the Javascript conform to this?
What I'd love to see is for something like this:
HTML:
<div id="article-1" class="article">
<h3>Article Header</h3>
<p>Paragraph 1</p>
<p>Paragraph 2</p>
</div>
<div id="article-2" class="article">
<h3>Article Header</h3>
<p>Paragraph 1</p>
<p>Paragraph 2</p>
</div>
Nothing new there.
new CSS:
.article {
h2 {
padding-bottom:10px;
border-bottom: 1px solid black;
}
p {
padding: 5px;
}
}
See what I did there? It's actually not that far a stretch. Typically this would be done by using ".article h2" and ".article p". This format mostly just allows for greater clarity in the CSS--at a glance--for what your style really expects elements to look like. Let's face it, styling has a dependancy on content--you can't theme a webpage unless you have some vague idea of what's going to be represented.
The next part is where I get serious:
Javascript:
class article {
var header = this.getElementsByTagName("h3")[0]; // We expect only one of these
var paragraphs = this.getElementsByTagName("p");
var hidden = false;
function onContentReady() {
this.header.addlistener('onClick',this.hideShowContent);
}
function hideShowContent() {
for ( var i in paragraphs)
{
if (this.hidden) { paragraphs[i].style.display = ''; }
else { paragraphs[i].style.display = 'none'; }
}
this.hidden=!this.hidden;
}
}
You get the idea, I think. Your non-class CSS defines what to do with elements occurring outside of classes, and gives styles that will cascade into classes unless overridden. Your non-class Javascript would include basic functionality used in many classes, and some of your classes might even require helper javascript classes that would be pulled in at need, and only once. (say, a date picker class that is required by several parent classes).
You could even separate your class-based js and css out, storing them locally, and providing "glue" in your base-level javascript, so that whenever the browser loaded a class it had not already seen in the DOM, it would look at that glue, and go and fetch the necessary JS and CSS if necessary.
This means that unless there's an Article on the page, you'd never load the Article css and javascript. The javascript and CSS would never be loaded more than once.
Clearly, my example is not incredibly good--the idea could probably use a lot more work, but what strikes me as funny is that when I look at it this way, it seems like it's almost meant to be. Javascript/ECMAScript is constantly improving and is at this point a full-fledged programming language in its own right, albeit one without a canonical interpreter. HTML and CSS specs are constantly improving as well, but there is a divide sharply between the two. I wonder if perhaps Javascript not being under the purview of the W3C has something to do with how separate it is from the HTML/CSS setup, and why they don't seem to be converging, aware of each other, toward something cleaner.
Photoshopped
1) I like interesting photography.
2) I am a stumbler.
3) Most websites allow comments now.
4) The internet is filled with goons and other silly people.
As I was stumbling through the internet a moment ago I came across an interesting photo of an underwater restaurant that is enclosed entirely in glass such that the diners have a constantly changing view of underwater life while they eat. Looked really cool. There was the obligatory comment as the third or so on the page:
"Definitely photoshopped. I can tell by the pixels, and I've seen a lot of 'shops in my time."
Given the fact that goons are known for stockpiling clubs and hunting dead horses for years at a time, the comment should come as no surprise to anyone. But I just thought of something, three little letters that are like gold to any business: "EAV".
EAV stands for Equivalent Ad Value. When companies get positive face time on large networks such as a news network or paper or a highly trafficked website, they are essentially getting ad space for free. And it's extremely valuable ad space, because it is placed in content spaces where people are actually looking to read the content. Here's an example: My company, TripAdvisor, got mentioned a couple months back in the show "The Office". If anyone remembers, it's the episode where Dwight Schrute opens an Agrotourism Bed and Breakfast at Schrute Farms. Its page is still at tripadvisor, and the clip is up at both tripadvisor and youtube. The mention cost us very little, but the value of it is exceptionally high, since it is in front of millions of people across the US who watch the show.
for an even better, slightly less biased example, Research In Motion says it estimates that it had millions of dollars of EAV from the whole "Barackberry" debacle, and I'd believe it. Think of him what you will, there is no denying our President's intelligence and simultaneous stardom, and if he uses a RiM smartphone, then hell, shouldn't I look into it. They paid nothing for that plug, and they didn't even expect or look for it. The fact that Obama didn't actually use a blackberry doesn't matter at all.
So now we go back to this meme: it seems there are like 20 goons or farkers or the like who spend hours a day going across thousands of websites and delivering equivalent ad value to Adobe with this tired joke, and you know what? They hit all the highest trafficked images first. I'll bet it's worth tons.
The Responsibilities of the Technologically Literate
I want to walk you through something I read a while ago and have been stewing on since. From October 18th in Wired Magazine, a robotic cannon killed nine people and wounded fourteen others.
They wrote that these machines are supposed to select and aim at a target, and "[wait] only for a human to pull the trigger." Except that sometimes, "these machines start firing mysteriously on their own."
They call it a software glitch. A malfunction. The problem I have with these terms is that, similar to the term "accident" in a traffic collision, they tend to imply no one is to blame.
I submit that somewhere, some programmer is to blame. If you write code, no matter how trivial, your job is to ensure the efficiency, consistency, and most of all the accuracy of your code. To fail in this regard can be tantamount to negligent homicide.
Coding errors can cause great cost; in the simplest of projects, this cost may only be in time, but soon that cost becomes money. In greater projects, it might be personal possessions, or public relations, or in still greater projects, lives.
This is not the first time something like this has happened. I am reminded of the infamous Therac-25, which between 1985 and 1987 was involved in at least five deaths due to poor interface design and failure to sanitize inputs. The Northeast Blackout of 2003, caused by a race condition in power monitoring software. The MIM-104 Patriot whose failure resulted in the deaths of 28 soldiers in Saudi Arabia in 1991 due to an error in time synchronization.
These are our responsibilities, laid upon us by virtue of our interest in the technologies which run our world today and those that will tomorrow: To provide value through technology by relieving stresses in tasks, or by relieving those tasks altogether, and to protect ourselves and our fellow man from those very technologies we create, and to the best of our abilities, from himself.
~Pigsflew