OT: Defending HTML4 (was: Re: Chelume - My Conlang website up.)

Some people wrote, so I defended my major:

>>Is that a problem? I've only used it to keep a single consistent
>>navigational bar across the top. I thought all modern browsers supported
>>frames?
>I don't know a single webbrowser that doesn't support frames, and I've
>never understood the complaints against them. I find them myself rather
>neat. On the other hand, the current evolution of HTML I'm firmly against.
>Complicating things needlessly so that it becomes impossible to code HTML
>by hand without using an IDE is not my idea of progress.
HTML isn't actually that much more complicated than it was. The w3c standard
is just incomprehensible.

I do think their separation between "content" and "style" was a very
necessary step. As I understand it, TeX had been doing that for years. Took
long enough for the 'net to catch up.

HTML, at this point, really isn't that difficult. No more so than it already
was. The problem is, as I noted, that the w3c standard doc is
incomprehensible. That and there's no good tutorials that I've seen that
follow the standards and explain them.

The main differences between HTML4 (contemporary standard; I'm not dealing
with all the X-stuff for now) and HTML as it was several years ago is simply
in the tags. The deprecated the tags that denote what text should look like
(bold, italics, underline) in favor of more generic tags that allow for
internationalization, such as citation. Surely you can appreciate that
different languages would cite the title of a book differently (in America,
we use an underline. Other places might not), and so we would want the style
of the citation to reflect the language of the document. So designing a
generic template for a cross-language page that will display a book requires
a generic citation tag, rather than a culture-centric punctuation tag. Then,
in a style somewhere, it's noted what a citation should look like. Stuff
like strong and emphasis (instead of bold and italics) were added to
genericize how text was rendered, especially in an aural format. That is,
they considered bold and italics to not be good enough to determine how
something should be read--again, cross-linguistically, it changes. That and
this way, someone could change how emphasized text should be
displayed--bigger size, bolded, who knows. But it's changeable.

On the font size note, I will agree they threw a wrench into the gears. And
I'm not convinced that even mozilla follows their standard with font
sizes--it's confusing. Basically, they didn't want to make text size
static--old people read websites, also. So they allowed for a greater
flexibility, by stating fonts in relation to their base sizes. This way,
"bigger" text was still bigger regardless of how big the "normal" text was.

As well, they emphasized the use of the tags div and span. What they had
seen were people who were designing webpages and setting up layouts based on
tables. This is not what tables were for--tables were for displaying tables
of information. Not for laying out webpages. So they devised a much more
flexible method of laying out elements on a page that was adaptable to
screen size, font size, and everything else. And they did it with two tags:
div and span. But mostly div. And because they split style from content, it
would be very easy to go back and change the background of a section of a
website. Or to change aspects of the base font of the text. This gives
developers a higher amount of control over what their webpages looked like.
Along the way, they developed the incredibly confusing box-model, which I am
still trying to get my mind around. I will admit that the box model could
probably use some work, but it's better than what we had--a mishmash of
ideas of how the same code should be rendered.

Span made it possible to create parts of text that had not been forseen.
Suppose there is a language that whenever it writes the name of an
individual, there is an overline written as well. Someone could define a
span class to be "person name", and so whenever you had a person's name, you
told the rendering engine it was a "person name". That way, if the language
changed and names were underlined, you only had to change code in one place
(where you specify how to render a "person name") as opposed to everywhere
you did so. It allows for more flexibility and a more generic way of looking
at a document.

Of one more particular note is the addition of stuff in the header. That's
copy-paste material, and isn't worth bothering with learning about aside
from the copy-paste, unless you really are a developer. And even then, I
don't think it's that important except from a browser point of view.

So I will admit, HTML now isn't like it used to be. It's become the language
of specifying a document's structure, instead of structure and style. It's
become more generic, so that it can easily accomodate any language or
culture--much more easily than it used to, at least. And while we have lost
a bit of simplicity, we haven't lost as much as it seems. People used to
sweat endlessly on getting their frames and tables set up perfectly to look
right. Now it's all accomplished with divs. It's just that the hard parts
have shifted to something new. HTML is becoming what it should have been in
the first place: a generic way of describing electronic documents in terms
of structure and content.

This has been a long-winded response to a short complaint :P

-Keith

Reply