Ask HN: Why is HTML so complicated? | Hacker News Reader

Ask HN: Why is HTML so complicated?

9 pointswicknicks9 comments

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.

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.

I see that HTML5 has a canvas tool, but its just not enough (mainly because all my widgets on the canvas dissolve into images).

Any thoughts on this would be highly appreciated.

View on HN

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.

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.

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.

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.

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: http://yuiblog.com/crockford/

Designing an "HTML killer" is no simple task, all attempts so far have failed - from Java applets to XML.

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.

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.

Yeah! This backward compatibility is the devil. I feel that this is the time to flush everything down and rebuild the whole thing from scratch. We can provide support for existing features, but in the right way.

What's the right way? The appealing thing about HTML is that it's actually rather simple, and it works extremely well for most tasks. Some of the styling rules in CSS are a bit arcane and difficult to master, but in general the CSS box model still feels a lot more simpler than the TeX box model, or the layout model used in many UI toolkits.

You want a markup language that satisfies a few simple properties. It should be text-centric, to make it easily searchable, indexable, and accessible. It needs to be easy to write by hand, since people want to be able to write simple pages quickly without using heavy graphical tools. And it needs to be relatively simple to programatically generate, since programatically generated pages are an important part of the web (i.e. pretty much every non-static website).

If you think about it, HTML satisfies these requirements fairly well. The fact that some kinds of complex markup are difficult isn't really important enough to counteract the fact that it's structurally simple and really amenable to programmatic manipulation.

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.

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.

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

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.

Don't blame physicists. We were just trying to organize and describe in a rational, rule-based language the sorts of document behavior humans find acceptable and useful. WYSIWYG would not have worked any better because deep inside the WYSIWYG system there would need to be some HTML like system to describe the document, its styles, its layout, etc.

Reply on news.ycombinator.com