In the 90s, the programming model for a graphics program was a simple 2D plane upon which one could paint anything. HTML started off as a way of putting documents on the web.<p>I have been struggling to digest why it uses DOM as a way of arranging elements on the page. Looking at what people are doing now on the browser (Real Time Search, 3D games, multi-modal communication) I feel that this architecture is not the best way to go ahead. Surprisingly, the basic painting canvas is great as it lets me bend things the way I want to.<p>I see that HTML5 has a canvas tool, but its just not enough (mainly because all my widgets on the canvas dissolve into images).<p>Any thoughts on this would be highly appreciated.
There were so many thousands of micro-decisions along the way, in all three areas of HTML, JS (language and DOM) and CSS, that the result looks more like a random walk than a set of well-thought-out standards at any given point.<p>Still, they're what we have, and, like the gauge of railroad track in Europe based on the ruts originally made by Roman chariots (the width of two horses), we gotta build the trains to run on 'em.<p>And, unlike the physical case, we can widen the rails every so often when most trains have adapted to the new widths.
HTML is not complicated at all, that's why it became a success - pretty much anyone could learn to write a basic web page in a few weeks.<p>Web pages became complex over the years as people wanted do things that HTML was never meant to do. Like page layouts: Early on, people would use invisible images for spacing, humongous nested tables to "hack" a page layout in a language that didn't support page layouts, and pictures of text rather than actual text for example for non-standard fonts or text shadows.<p>The primary problem is that HTML was never designed for the kinds of things we use the web for today. See the Crockford Javascript presentation for a history of HTML and Javascript, I recommend Episode IV: <a href="http://yuiblog.com/crockford/" rel="nofollow">http://yuiblog.com/crockford/</a><p>Designing an "HTML killer" is no simple task, all attempts so far have failed - from Java applets to XML.<p>But even today you can use applets or Flash to embed more complicated programs. The web protocols turned out to be eminently hackable, and with server-side page generation, forms, CSS, Javascript and now canvas it is "good enough" for more and more tasks, so I expect it is safe to say that HTML will be with us for quite a while longer.
HTML started out as a simple language for formatting research papers. It is a tree of text nodes and elements, ie section 1, table 3. It was not and is not intended to be a 2D anything.<p>Over the last 20 years many people have layered on things for different reasons. The biggest, of course was the "style sheet" which came from the print world. Javascript poked its head in, which prompted an attempt to standardize the DOM without breaking backwards-compatibility. Then the Semantic folk tried to enforce a separation of "meaning" and "styling", which struggle continues to this day.
I've often found myself just wanting to access a framebuffer as an array or pointer or whatever like in the "good ol' days", but the truth is that unless you are writing low level libraries, or bleeding edge special effects you shouldn't need to do this. Its not a nice way to work 99% of the time, when what you really want is to draw a whole polygon, or image or whatever.<p>Unfortunately the web is yet to catch up with hardware accelerated graphics, so we don't have shaders etc. yet. Stuff like WebGL are looking to solve this problem though, and soon you will have a similar level of low-level access to a framebuffer.
Personally I've used it for so long that it's just become second nature. Can't even imagine anything else.<p>Still way excited about HTML5. I'd like to imagine how HTML6 will be like...
It's complicated because it was created by physicists. :p<p>I believe Alan Kay mentioned during a recent talk that he thought a WYSIWYG interface would have been a much more suitable design for the web. I think HTML is ill-suited for many online documents, but I wonder if a WYSIWYG would have actually worked any better.