Re: Why why why? (Was: Re: Vertical alignment of text within a DIV)

"Stan R." <stan@xxxxxxxxxxx/hmrprint/com.com> writes:
What I am really curious about is why HTML/CSS/JavaScript (and even XML
[1]) weren't created as components one would download and install on
their operating system, much like you would Perl, PHP, or such.

The comparison isn't really valid, but on that analogy, how many
different (sometimes slightly incompatible) C compilers are there?

It's also expected behaviour for standards bodies. RFC 822 was not
accompanied by a full MTA. RFC 2616 was not accompanied at release
time by a fully-debugged implementation of Apache, and nor did it need
one.

In this scenario, everyone, regardless of OS or user agent (or browser)
would all have the same components making up the core parsing and
rendering parts, while the UA/browser sits on top of that, doing any
ad/popup blocking, blocking of components, or anything else a browser
adds to the base web experience.

The rendering *is not* necessarily part of the base web experience,
though. Parsing I could agree with if it wasn't for the fact that the
parser is the trivial [0] bit of writing a web browser.

Having to write not only a reference implementation (difficult itself)
but a full rendering implementation for every possible display
environment (display code for MS Windows probably won't work in X
Windows, and neither stands a chance on a VT100) that they have to
keep up-to-date any time an OS gets a new display environment would be
very impractical. Remember that back when these standards were written
there was very little in terms of cross-platform display libraries.

Also, now it's getting to the stage where it's practical to write
complex desktop applications in languages other than C, would the
standards body be responsible for writing interface libraries to this
rendering platform in Java, Perl, Haskell, Intercal, etc?

To be honest, this would of infinitely been the best solution that would
of easily prevent years upon years of browser wars, mounds of extra code

The browser wars weren't really about rendering of standards-compliant
code, though.

(think JavaScript compatibility between NN4.x (and equivalent Mozilla)

Though Javascript didn't start out as an official standard in the
first place - it was implemented in browsers first.

and IE4.x and pre 4.x of each. Anyone whose been on the HTML scene since
the late 90's would know what I mean there.)
[...]
Was there any real reason that this would of been a bad idea? I mean,
look at my scenario. It still allows for everyone using whatever UA they
wish, as is presently the case, with all the features, the only
difference being uniform rendering across the board, like, IMHO, it
should of been from the very start, instead of the mess we ended up
with.

You're assuming that uniform rendering is a good thing or even
possible. A text-mode browser has very different rendering
requirements to a graphical browser, or a speech-based browser. There
are other areas in the specs where behaviour is only loosely
specified (table layout algorithms, for example).

Even with just graphical browsers, what should happen? <blockquote>
typically gets rendered indented. I tend to prefer unindented but with
a border, and if I'd written a web browser back in the early 90s, that
would have been the default behaviour. Pre-CSS, or without any
additional CSS given, what should this universal rendering engine do?
[1] Perhaps more historically realistic, why should a handheld PDA
browser render identically to a monitor-based one (Opera makes a good
job of displaying the same content very differently in these two
contexts)

Also, what's 'core' rendering and what's UA? Most graphical browsers
handle form controls by passing it to an OS-level or windowing
system-level library. When I run Konqueror the KDE form controls don't
match the rest of my system. On the other hand, the KDE people would
be annoyed if a 'uniform renderer' swapped the controls in their
browser for the relatively ugly ones I get in my browser.

Similarly, what about a browser that lets you double-click on a table
to open it in a mini-spread*** app [2] to do things like statistics,
partial copying of data, etc. The specs don't say anything at all
about how that should look - I'd be surprised if a standard renderer
even came close to supporting it.

Most of the *unwanted* differences in rendering HTML+CSS in modern
graphical browsers are due to bugs more than they're due to the
semi-theoretical things above. We can assume the reference
implementation would not be bug free, and that given the noticeable
minority still using IE 5(.5) and until only a couple of years ago
NN4, any fixed bug could not be relied on for consistent layout for
years. What's the gain?

Meanwhile, in today's world, Gecko-based browsers, Opera and
KHTML-based browsers all render the same HTML+CSS in pretty much the
same way, apart from trivial differences within the discretion allowed
by the spec. Now Internet Explorer development is back on, I expect
that will catch up within a few years.

[0] In comparison to the user interface or renderer, anyway.

[1] Nowadays the answer is theoretically relatively easy, because you
could pass in a UA style*** to be processed at a lower priority than
the author and user stylesheets. However, for this alternative history
to work, this whole scheme would have had to cope for several years
without CSS having been invented yet.

[2] It's not *that* far-fetched. I know of at least two browsers that
let you open a text editor or word processor to edit textarea
contents, though they do it slightly differently.

--
Chris
.