Web Standards Evolution - VML, SVG, Canvas, CSS, XML, JSON, and JavaScript.
This post stemmed from an unpublished reply (comments are closed) to a very good article from Mark Pilgrim on the Overton Window applied to web standards and the W3C in particular.
<digression class="philosophical">Standard organizations, and standards, just like any system in our known universe, have to die someday. When their time has come, they allow the birth to their next evolutionary iteration. Just like supernovas are dying stars that allow the creation of the atoms that eventually allow life to emerge, and the death of dinosaurs allowed mammals to strive. We humans will someday give birth to our evolutionary child, be it intelligent machines to allow the universe to acquire an enhanced understanding of itself - which is all the universe cares about in the end.</digression>
Lets start by not complaining too much about the current state of the W3C or other web standards, what's relevant is to understand the limitations of all the things out there and get ready for the evolutionary changes ahead.
Regarding SVG and Canvas, I believe we need both (a format language and an API) at this point although there is a big overlap between the two. We might need a third standard to unite them both or split them in 3 parts: one common and 2 extensions to account for the specificities of both. This could come in the form of:
- A rendering and behavior specification for vector graphics integrated in the DOM with events on individual vectors (unlike Canvas that requires to scan all objects to bind events to elements). This behavior would be accessible to HTML, CSS and JavaScript, etc, through their respective syntaxes.
- A language format for vector images (à la SVG/VML)
- An API for vector libraries (such as drawing or charting libraries like Ico).
Even if such a standard does not emerge anytime soon, web browser developers could adopt the above architecture to implement both SVG (plus VML in IE) and Canvas. An underlying rendering and behavior engine could very well be a common backend to both SVG, VML, Canvas, you name it, and of course the freaking CSS3 rounded corners. A nice side effect of this architecture would provide events to Canvas elements.
In any case, one must recognize that the real problem with SVG from the start has always been it's denied and angry VML father [Luke, ... I am your father]. The excellent Raphael JavaScript graphic library over the last year and a half has managed to reconcile VML and SVG while sharing some similarities with Canvas (being an API vs a format). Raphael and Canvas are therefore evolutionary children of the standard war.
CSS is still not a real language with variable, let alone objects. Where is CSS going? It is currently dying supernovae-style giving birth to a myriad of modules never-to-be-released, missing programmability altogether, and in total ignorance of encapsulation-concepts. Instead of premature componentization, we first need to see the big picture of where we want the web to go. Here is my proposition for an evolutionary change: Drop CSS for a JavaScript DSL.
What's the big deal about rounded corners? Do we need another iteration of CSS just for that? What if Apple drops rounded corners next week for some other box shape? Will we have CSS4 to handle that too? In 2022?
We need to add vector graphics in the toolbox of style designers so that they stop relying on raster images which are only slightly ok at carrying approximate representations of our chaotic world. I say "slightly" because if the world is chaotic as it is, then we don't need compression, not even fractal compression, we need fractal shapes.
How about the XML standard and its agile evolutionary child, JSON? I could have used JSON for the above digression but XML provides a more award style more appropriate for emphasized off topic content. JSON is more human readable, and fits better in the current JavaScript-bound-web.
What's ahead for JavaScript? Hold your breath, .... drums, ..., and the winner is: JavaScript for now. Why? Because, for now, JavaScript does the job once one realizes it is a really good evolutionary child of Class-based Object Oriented languages (such as C++ and Java) with easy to use (I would even say intuitive) closures. There's another reason of course: our life in the browser is for now limited to a single language. Although that will have to change someday, for now JavaScript only flaw is its performance in IE that should mostly be fixed in IE9.
