I’m becoming increasingly confused about what direction the Web is heading in. More precisely, I’m slightly concerned that the direction the Web is heading in is completely different to the direction in which various researchers believe it is heading in.
In my field of research, I often run into material on the “Semantic Web”. This is supposed to be the vision of where the Web is going: more structured mark-up of information using tags from well-defined, domain-specific vocabularies (so-called “ontologies”). On top of this, we can then build intelligent applications (“agents”) that can draw together information from diverse sources, integrate it, make inferences from it, and generally use this knowledge to act on our behalf. This is a vision I have some sympathy with, although there are clearly huge obstacles to overcome before it becomes anything like a reality. We’re still not sure what logic dialect(s) to base it all on, and that’s just the first step!
But the problems I see with the Semantic Web are not primarily technical. The main problem I see is that the Web is actively evolving in the opposite direction. Just take a look at the HTML 5 (draft) specification. While some lip-service is paid to “semantics” in the introduction, in actual fact the spec moves further away from a declarative, logical language, and instead embraces vacuous tags such as <canvas>. This tag exists solely to provide a context into which to render, procedurally in JavaScript, arbitrary 2D graphics (or 3D graphics with the emerging WebGL standards). While I welcome the attempt to provide an open alternative to technologies such as Flash, I’m not sure that <canvas> really delivers. Indeed, it seems that it suffers many of the same drawbacks of Flash. If the goal was to continue to evolve the more meaningful distinction between different tags, why didn’t they develop a set of specific-purpose tags rather than developing another procedural API? For general graphics, the SVG standard already exists. For charts and graphs, why not introduce a more meaningful chart element, with declarative descriptions of axes, data points, formulae, etc? For example, suppose we wish to plot a 2D chart of the formula y = x2. In the current HTML 5 specification we could “mark-up” this formula as follows:
<!DOCTYPE html>
<html>
<head><title>Test of HTML 5 Canvas Tag</title>
<script>
function point(x, y) { this.x = x; this.y = y; }
function axis(min, max, scale) {
this.min = min; this.max = max; this.scale = scale;
this.start = min * scale;
this.end = max * scale;
}
function xSquaredChart() {
var chart = {
origin: new point(100, 0),
xAxis: new axis(-10, 10, 10),
yAxis: new axis(0, 100, 1),
interval: 0.1
};
chart.f = function(x) { return Math.pow(x,2); }
return chart;
}
function drawChart(ctx, chart) {
var H = 100;
var o = chart.origin;
// Draw the axes
ctx.fillStyle = "rgb(0,0,200)";
ctx.fillRect(chart.xAxis.start+o.x, H-o.y, chart.xAxis.end+o.x, -1);
ctx.fillRect(o.x, chart.yAxis.start, 1, chart.yAxis.end);
// Plot the data
ctx.fillStyle = "rgb(200,0,0)";
for (x = chart.xAxis.min; x <= chart.xAxis.max; x += chart.interval) {
var y = chart.f(x);
ctx.fillRect(x * chart.xAxis.scale + chart.origin.x,
H - (y * chart.yAxis.scale + chart.origin.y),
1, 1);
}
}
function draw() {
var chart = xSquaredChart();
var canvas = document.getElementById("canvas");
if (canvas.getContext) {
var ctx = canvas.getContext('2d');
drawChart(ctx, chart);
}
}
</script>
</head>
<body onload="draw();">
<canvas id="canvas" width="200" height="100">A canvas should be here.</canvas>
</body>
</html>
If you try this out in a modern browser such as Firefox or Safari, that supports the canvas tag, you should indeed see a plot of the formula for values of x between -10 and 10. My point is not so much about the length of code needed to plot this simple function—indeed, I have deliberately made the code longer than it needs to be for generality—but more the total opacity of its purpose or meaning. The best we can hope for is that libraries become available for such common tasks, and that authors take the time to also supply marked-up comments and captions that identify that it is a chart and what it is a chart of. Consider a hypothetical alternative if HTML 5 directly supported tags for marking up charts:
<chart id="x-squared" type="line">
<axis id="x">
<range from="-10" to="10" step="0.1"/>
<legend>x</legend>
</axis>
<axis id="y">
<formula>y = x^2</formula>
<legend>x<sup>2</sup></legend>
</axis>
<caption>Plot of x<sup>2</sup>.</caption>
</chart>
The formula element could be specified in MathML content tags or even in JavaScript. Explicit data points could be given with a datum tag supporting error bars and other features. The browser can add all kinds of nifty features, such as the ability to edit data or change ranges on the chart and automatically display the new values, like a spreadsheet. However, the main point is that the mark-up is much clearer, and more importantly, its purpose is easily extracted by automated tools. Other uses of the canvas tag could also be handled by special-purpose tags, such as animation, presentation slides, logos, simulations and even games.
At this point you may be thinking to yourself: OK, but surely you can’t cover every possible use of the canvas tag with special purpose tags? Indeed, you probably can’t. That doesn’t mean that we should try, though. By including special-purpose tags alongside the canvas tag we can encourage people to use them when they fit, and only resort to procedural APIs when all else fails. After all, custom tags should be much simpler to use, more maintainable and readable, and offer the possibility of much more efficient implementations within the browser rather than in JavaScript. Another much more powerful alternative also exists: an ability to define your own custom tags and tag-views. A further post will expand on this topic soon!
Neil Madden 