Re: default.css

On Fri, 15 May 1998, Jan Roland Eriksson wrote:

> Mozilla spawns are a dead end in relation to both HTML and CSS,
> Arjun Ray stated that well over a year ago and he was right then,
> and even more so now.

I know... I haven't looked at the code (no Motif libs on my Linux box, no
devel tools on my Win box) but it seems from their plans on www.mozilla.org
that they value "backward compatibility" (meaning compatibility with
previous - broken - versions of Navigator and perhaps IE) more than spec
conformance. This, in my view, is backwards. If you take a look at the
implementations you'll see that the reason they get everything wrong is that
they *go about it the wrong way*. Both Netscape and MS need to rewrite their
browsers from scratch. What I mean is this:

It is obvious that both browsers refuse to consider an HTML document as a
tree of elements, but instead consider it as a *series* of... things. No
wonder both object models are so inconsistent. And this is the reason why
correct rendering of paragraphs (possible the simplest and most basic
element since the birth of HTML!) is so messed up in both browsers: they
consider <P> to be a *paragraph break entity*, not a *paragraph element
start-tag*. Ommit the </P> and in most cases you get no space after the
paragraph. And no wonder it's practically impossible to set the space
between paragraphs using CSS... the space is rendered as a result of the
aforementioned "break", and not as the (collapsible) vertical margin between
two elements, as it should be.

And has anyone noticed that all CSS is simply internally translated into
either proprietary/deprecated HTML or JavaScript/JScript? For instance, CSS
positioning in Navigator is almost entirely based on Layers. Navigator takes
a DIV with absolute positioning and translates it into a layer. It even
supports its proprietary layer-* CSS selectors when used on it. This is
*backward*.

Same with OBJECT. Both browsers blatantly do an s/OBJECT/EMBED/i and process
OBJECT elements like that. No wonder both implementations are broken.

The CSS2 specification gives very detailed instructions on a CSS2 visual
rendering model [1]. HTML UAs should base their rendering on *that* and
perhaps translate proprietary/deprecated HTML (like the FONT element) to
appropriate CSS rules instead of the other way around, probably using HTML
version information (read: Document Type Declarations) to decide which way
to go. That's why we *have* DT Declarations. Not for the author to put them
in for validation's sake (well, that too). But also for the user agent to
know what version of HTML it's rendering.

The problem with the implementations is not bad implementation per se, it's
bad programming. Back in the day before HTML 2.0 it was possible to use a
"serial" model to process HTML documents and get satisfactory results. But
not any more. And any application that still uses code from the days of the
old approach has to be reworked from scratch, not patched hastily in an
attempt to fake conformance.

My tuppence worth, that was. Sorry if I was too offensive or presumptuous,
and please correct me if I'm wrong - that happens some times :-)

[1] http://www.w3.org/TR/REC-CSS2/visuren.html

-- Stephanos Piperoglou -- sp249@cam.ac.uk -------------------
All tribal myths are true, for a given value of `true'.
                         - Terry Pratchett, The Last Continent
------------------------- http://www.thor.cam.ac.uk/~sp249/ --

Received on Friday, 15 May 1998 20:30:33 UTC