Pigsflew.com Realization of a Dream

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.