Best practices mandate the separation of semantics, presentation, and behavior, each of which is expressed in separate files (more or less) and in a separate language. I'd add a separation of form and content (page types as templates presenting similar types of content), and then the two additional server-side layers of the database and server-side computation - with two more languages. So we've got, in order of machine proximity (more or less): SQL, PHP/Python/Perl/Java, HTML, CSS, and JavaScript. (Plus whatever natural language is, you know, the content.)
There are sane reasons for this, primarily the fact that content writers, graphics design people, and programmers have a very, very small intersection indeed - but even in cases where, say, the programmer and graphics designer are one and the same, a separation still enhances quality: if I have a certain set of elements that I can move around and design with a graphical tool, it's far, far better to be able to isolate that in CSS and just concentrate on appearance.
But.
To do this efficiently, we need to define a set of classes (say) that CSS can grab onto, that JS can manipulate, and that HTML can key in - and those strings are arbitrary and their meaning is now spread across three files in three languages. Get me so far?
Google's JavaScript example consists of a collapsing set of menus; when I click on a menu header, JS changes a "status-on" class to a "status-off" class, and the CSS defines that as hidden or shrunk or whatever. Meanwhile, I have to remember to set things up correctly when generating the HTML, and JS has to do some trivial initialization that I can't forget to invoke on page load, either. There is a lot of coordination to do, and it's worse than that - the class attribute of things is overloaded; it both identifies items of a given class (which is what it's supposed to do) and it's used as a "shared signal" to integrate the three languages, representing the status of a given object. I'm not saying that this is wrong - I find it rather elegant - but the details are easy to miss and hard to specify correctly.
This is where a higher-level language is a real win - ideally, it would be nice to compile all three of our defining languages from a single source. (This mirrors what I had already thought about the three areas of the database, server-side code, and HTML, but bear with me - I'm still not at the epiphany.) There's only one problem: this interleaves all the stuff we've been so very careful to pull apart over the past few years.
OK, here's the epiphany. Really, kind of two.
First, we can still separate out semantics, presentation, and behavior at the object level without having to put them all into three widely separated places for the entire site. This is a far better model for the overall meaning of the things we want to present. That's kind of the lead-up epiphany, because it doesn't address the issue of specialization on the part of our creative staff.
The follow-up epiphany is that by selecting class names that are easy to key back to our object definitions, we can publish a CSS, allow a designer to modify it, then analyze the changes made in order to pull those back into our object designs. Ideally, this process would be fully automatic, but in reality there could often be a little post-hoc analysis of the changes made in order to work them into the overall design better.
This is more or less the same situation we're in when a customer marks up an existing template-generated page to represent a design, or when we do some lower-level debugging with the output of a literate programming definition. It's kind of a reversal of computation - this is not solvable in all generality, but we can certainly provide some tools for its solution.
So that's the epiphany - a high-level language that would represent Google's best Web practices. I'll follow up with some examples in a later post.
No comments:
Post a Comment