

Ask HN: Why is HTML so complicated? - wicknicks

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.
======
cpr
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.

------
j-g-faustus
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.

------
aristus
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.

~~~
wicknicks
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.

~~~
eklitzke
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.

------
jheriko
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.

------
rradu
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...

------
th
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.

~~~
drallison
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.

