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



"Stan R." <stan@xxxxxxxxxxx/hmrprint/com.com> writes:
Chris Morris wrote:
"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?

This actually a similar case as HTML. Too many seperate
/implimentations/ flkoating around, and thats what I want to take oput
of the equation and have one centralized implimentations (with versions
for each platform of course.) While still on the note of C/C++, your
statement is actually one of the reaosn languages like Perl and Java
weere created. They both have centralized compilers/interpreters instead
of having various implimentations out there.

Indeed (although it's worth noting that you can't just take a Perl
program on Linux and expect it to always work without modification on
Windows, because there are differences at the kernel level you can't
avoid). Java never quite lived up to the write once, run anywhere
ideal either (and there are now several Java compilers/VMs available,
of course, partly because not everyone likes Sun's licensing terms)

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.

As for as graphical user agents go (sory for not beign clear on the the
graphical part previously), I really think it would of been a heck of a
lot beter for web developers had there been a lot more uniformity in the
rendering part. HOW it achives this on a given operating system would be
specific to that platform, just as Java, Perl-TK, and Python guis (just
to name a few examples) would.

In my scenario, users would simply used the version for their platform.
Again, this concept is anything but new.

But you're still requiring the standards body to write a version of
the display engine for each platform. Obviously, yes, it might use SDL
on one platform, and OpenGL on another, and DirectX on another - but
that's a lot of work to maintain them all.

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?

Actually I hadn't realy thought abotu that, but having interface
libraries in any language to use the operating system's HTML and such
component's (either for parsing, or even rendering would actually be
quite useful.

It's the 'any language' bit, though. It's just not practical for the
standards body to do that. Haskell has a very different paradigm to
languages such as C, for example.

It would no different than any other type of shared component on a
system, such as a database engine, or a parser of sorts.

The difference is who writes it. MySQL, for example, has released a C
interface library. When I came to a language without a MySQL interface
library, and needed MySQL support, I had to write my own interface
library [1] because it would have been entirely impractical to expect
MySQL AB to write it for me.

[1] Fortunately, the language has decent methods for calling C foreign
functions, so it only took a day or so in this case.

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

Oops, my mistake. ECMA Script :-)

Right. But it was - in this case - the browser implementations leading
the need for a standards body. Most standards work like that, of course.

Also, I though it was proper web design (good use of CSS, for example)
that would make web pages acceptable on PDA as well as on normal
computers :-)

I don't see why that would suddenly change.

It wouldn't - but since CSS post-dates HTML by years, it wouldn't have
been practical to do it for the initial version of HTML (which makes
it impractical to do now for historical reasons)

Well lets be reasonable here. When I say uniform, I mean more in terms
of layout, dimensions, and such. Things like fonts and controls (like on
a form) would more than likely be system dependant, but in my screnario
of uniformity it would eliminate the problems like the following:

Fonts is a tricky one, though, since different fonts have different
(apparent and actual) sizes for the same point size. If you've then
got a <textarea> set to 60 cols, then very clearly the width of that
textarea may depend on the font in use, which the renderer and the
page author can't guarantee.

This would allow the web developer to actually focus on just making the
page instead of the tedius work of ensuring cross browser/agent
viewability.

With the exception of a few tweaks for IE 6, the last bit of graphical
web design I did worked near-identically on Mozilla, Opera and
Konqueror. IE 6 is over five years old, so it's understandable that it
has more rendering bugs.

But there wouldn't be any need to "catch up" in my screnario, as one
central body would be rolling the HTML engine, as well as the CSS parser
(the HTML engine would require the CSS parser of course, as dependency,
same with Java/ECMA-Script.

I think one of the reasons this sort of method works for programming
languages and couldn't for standards is that programming languages are
usually excellent for incremental development, and standards by
definition aren't.

Also, the core syntax of a programming language is generally tiny -
it's the libraries that make it useful. The Perl people may have
written a language and an interpreter and a few core libraries, but
most of what makes the language useful is libraries written by other
people. Similarly C - even if it had a single compiler - most of the
usefulness would be in the libraries. Having a reference
implementation of the compiler is a reasonably easy thing to do (but
may still take a while to write).

Compare the complexity of a compiler to a web browser. In a very crude
comparison:
$ ls -l /usr/bin/gcc-4.0 /usr/lib/firefox/firefox-bin
-rwxr-xr-x 1 root root 93776 2006-03-04 17:46 /usr/bin/gcc-4.0
-rwxr-xr-x 1 root root 11263404 2006-02-07 05:25 /usr/lib/firefox/firefox-bin

Writing a reference web browser is a very tricky task. How long has it
taken to write Mozilla or Opera to the stage they're at now in terms
of (almost) bug-free HTML+CSS rendering - several years. If the
publication of the CSS standard had been delayed by several years
while the rendering module was written, we'd still have been using
<font> for the lack of anything better in 2002.


A second consideration, incidentally, is licensing of the rendering
engine. It'd have to be free to use, but to be incorporated in a GPL
product like Mozilla it'd also have to be free to modify, which of
course means that there'd be potential for drift from the reference
implementation. (Or if it wasn't free to modify, an entirely separate
implementation - just as gcc was a GPL reimplementation of older
non-free C compilers)

I think my scenario would be the best solution. It logically structures
the needed components (and dependencies) and would of allowed User-Agent
developers, as well as Web Developers, to focus more on the the tasks
and not the quirks.

Give it five years and I think it'll be like that anyway, more-or-less.

--
Chris
.



Relevant Pages

  • Re: How Common Lisp sucks
    ... certainly a mechanism for creating defacto standards. ... libraries that work across implementations that provide de facto ... which also mean an increase in expressive power when added to Common Lisp.) ... language and making changes to the language. ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... There is certainly a mechanism for creating defacto standards. ... There are definitely portable libraries out there. ... What matters in today's world varies heavily across different users of Common Lisp. ... Peter Seibel has done a very good job of attracting newbies without any change to the language at all. ...
    (comp.lang.lisp)
  • Re: Python does not play well with others
    ... you have to undestand that python is not like other languages. ... what some people actively developing the language are actually doing with it ... Libraries, on the other hand, ... Something like that happened to the C++ standards committee. ...
    (comp.lang.python)
  • Re: future C standards
    ... keeping C a vital and relevant language in the ... The thing about libraries is that they don't require the ... blessing of official standards to be useful. ...
    (comp.std.c)
  • [LONG] Re: Why code completion and early error checking are needed
    ... > the programmer who wants such features. ... the guiding principles in the evolution of the c++ language should be ... the problem with this is that ide must first be able to assume ... libraries to find the type declaration. ...
    (comp.lang.cpp)

Loading