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

Author

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

Stan R.

2006-08-30, 6:41 pm

Spartanicus wrote:
> "Wayne Poe" <louis@h4h.com> wrote:
>
>
> Sadly CSS2 does not offer a good method for creating layouts suitable
> for the web, this is indeed a shortcoming. But layouts that work on
> the web are a complex problem if the serious drawbacks of table

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.

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.

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
(think JavaScript compatibility between NN4.x (and equivalent Mozilla)
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.)

Why the governing bodies who write the spces for HTML/XHTML, XML, CSS,
JavaScript, in their seemingly boundless wisdom, could not of seen this
as a far better solution, is a mystery to me. They could of made this
happen. They could of developed the parsing and rendering engine cores
that would be a dependency of any UA/browser. These engines would then
be updated regularly, just like things like Perl, PHP, Python, and even
entire operating systems are.

HTML, CSS, etc, updates could become part of normal operating system
updates in fact. Newer version of UAs and browsers could call on the
user having a minimal version of HTML, CSS, etc installed (or perhaps
come packaged with a version, or even better yet, check for updates
regularly!)

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.

Thats my $0.02

* * * * * * * * * * * * * * * * * *

[1] Granted, XML, XSLT, Schema, etc, all have command line and
GUI tools for parsing and checking code (like for
well-formed-ness), and on that note, there's even nsgml
for checking HTML, but what I mean by having HTML, CSS, and
JavaScript as components is having the body that governs
them, instead of just writing the specs, they should of
released components in the force of parsers and maybe even
rendering cores that any UA would use.

Such a system would of been truly harmonious imho.

* * * * * * * * * * * * * * * * * *

--
Stan

* If emailing a reply, please use stan^blz/hmrprint/com,
* after properly converting it into a legal address :-)

Chris Morris

2006-08-30, 6:41 pm

"Stan R." <stan@invalid.blz/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-spreadsheet 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 stylesheet 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

Harlan Messinger

2006-08-30, 6:41 pm

Stan R. wrote:
> Spartanicus wrote:
>
> 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.
>
> 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.

For the same reason that there isn't just one company manufacturing
television logic chips, vacuum clearer motors, or thermostats, leaving
only the embedding of these functional cores into consumer-friendly
casings to competition: free enterprise.

>
> 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
> (think JavaScript compatibility between NN4.x (and equivalent Mozilla)
> 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.)
>
> Why the governing bodies who write the spces for HTML/XHTML, XML, CSS,
> JavaScript, in their seemingly boundless wisdom, could not of seen this
> as a far better solution, is a mystery to me.

Standards organizations *consist of* representatives from the various
competing concerns, commercial, academic, and otherwise. Their purpose
is to create standards that those organizations can follow to improve
efficiency and interoperability of their respective products, to the
benefit of both the organizations and their customers. The standards
organizations aren't competing *against* the competing concerns.

An organization that does what you're talking about *isn't* a
*standards* organization. Sun (with Java) and Microsoft are examples of
this.

Stan R.

2006-08-30, 10:40 pm

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

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

For graphical user agents, rendering arguably IS the experience. Else
you would not see anything :-)

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

> 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 would no different than any other type of shared component on a
system, such as a database engine, or a parser of sorts.

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

Well the biggest problem since thne was writting good clean code that
displayed as expected on a wide variety of graphical UA's, instead of
the various hacks and special browser specific code that were sometimes
required, and still are for certain things.

>
> 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 :-)

> [...]
>
> 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).

Ok I should of been more clear that I was talking about GUI based
UA/browsers. I think we can all agree that text-only UA/browsers are
another animal all together in terms of rendering.

As for loosely specified, this is a great example to my point. I think
web browsers (ahem, user agents) are one area "leaving it to the
implementers" has resulted in so many inconsistancies across the board,
and if the body that writes the specs actually wrote a software that
would handle the job of rendering, it would of eliminated the
inconsistancy problem.

> 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?

Well look at this this way. In my screnario, instead of focusing on the
rendering engine, the browser (user agent) developers could focus more
on the interface itself. such as allowing the CUSTOMIZATION of how a
given element gets rendered. You got to admit that would be very useful.

The base rendering would be uniform, and the user would be in full
control of it (like I said, being able to overide defaults as they see
fit. Some of this is available in some browser/agents already actually.)

> [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)

There is no reason for a PDA to render in the same way a monitor does,
but my screnaio, the base render would handle that job, it would just be
configured for PDA.

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.

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

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:

o On the windows platform, the form controls in IE, NN, and
Mozilla/FF differ a bit. I always found this strange
considering this is on the same platform.

o In NN 4.x win32 text input fields (especially textarea
fields would be a bit larger than on other servers on
the same platform.

My scenario would eliminate such inconsitancies. As for behavior on
different platforms, since each platofrm would have it's own release,
the engine would attempt to work with the native controls so that size
and such are as close as possible.

In other words, you could think of my scenario in a similar way to Java
works; you have command line and GUI components. Also PERL (and PERL TK)
too. Both are available on many platforms, and are subject to quirks and
limitations of the host platform.

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.

> Similarly, what about a browser that lets you double-click on a table
> to open it in a mini-spreadsheet 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.

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.

Basicall, in my proposal, it would breka down like this:

1. HTML/XML Parser. Think something like `nsgml`, `xmllint`,
`xsltproc` and such as one parser (also DTD parsing), as all of
these have some relation to each other in one way or another.

This would centralize the processing and checking/verifying of
HTML, XHTML, XML, XSLT, DTD, Shema, etc parsing.

2. HTML/XHTML Engine, which would be capable of standalone rendering
(which could be useful to perhaps quick-test web pages; think
java applet viewer in a sense) as well as be called or embeded in
applications, mainly User-Agents.

Dependencies: 'HTML/XML Parser', 'CSS Parser', 'ECMA Script Parser'

3. CSS Parser. I would like to think this would be a seperate
component all to gether, as it is not limited to use in
HTML documents. XML also comes to mind.

4. ECMA Script Parser.

5. User Agent.

Dependencies: HTML/XML Engine

Yes, this may all be a pipe dream, but I really think this would of bene
far better and much more logical than having so many seperate
implimentations of the same thing. Especially when developers of the
various renders still cannot semm to see eye to eye on some things.

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.

--
Stan

Stan R.

2006-08-31, 3:42 am

Harlan Messinger wrote:
> Stan R. wrote:
>
> For the same reason that there isn't just one company manufacturing
> television logic chips, vacuum clearer motors, or thermostats, leaving
> only the embedding of these functional cores into consumer-friendly
> casings to competition: free enterprise.

I mean no disrespect, but that's a completely different thing. What I
propose would be a heck of a lot more akin to the what has pretty
successfully been achieved with the likes of Java and Perl. One body
writes the specs AND the software that runs said code. I fail to see why
the same would not of been a far better solution for HTML, XML, CSS,
ECMA Script and the likes then the mess we've had for nearly a decade
now. It may be much better now, but its far from perfect. Had what I
proposed been done from the start, a lot of (browser-compatibility)
headaches might of been prevented :-)

>
> Standards organizations *consist of* representatives from the various
> competing concerns, commercial, academic, and otherwise. Their purpose
> is to create standards that those organizations can follow to improve
> efficiency and interoperability of their respective products, to the
> benefit of both the organizations and their customers. The standards
> organizations aren't competing *against* the competing concerns.
>
> An organization that does what you're talking about *isn't* a
> *standards* organization. Sun (with Java) and Microsoft are examples
> of this.

Well, they are actually both a sort of hybrid committee, in that they
create both a specification as well as the core implementation. The
whole point of Java, Perl, Python, and the likes is to take the core
implementation out of the equation. Am I truly the only one that thinks
this would of been a much better route for HTML and related?

Even if Sun, Larry Wall & others in the PERL world, and the likes aren't
writing specifications in the same way as W3C does, that doesn't mean
going a similar route as Java, Perl, etc, wouldn't been a better
solution.

--
Stan

Christian Kirsch

2006-08-31, 3:42 am

Stan R. schrieb:

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

....

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

Excuse me for interrupting, but could you please be so nice as to take
a bit more care of your text before posting? There are quite a lot of
people reading Usenet news who are *not* native speakers (I for one).
Your habit to write "of" instead of "have", "implimentation" instead
of "implementation", "whose" instead of "who's" etc makes it
incredibly difficult to read your postings. May be it's some kind of
joke I don't quite get? Anyway, mentally rearranging the letters until
they make sense is quite tedious.

Chris Morris

2006-08-31, 6:41 am

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

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

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

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

Stan R.

2006-08-31, 6:51 pm

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

Well, with Perl, a large percentage of code is transferable, same goes
for Java. It's when you get into platform dependant aspects that
compatibility begins to break down, but that exactly what "platform
dependant" means. For example, in Perl, using select for socket handles
is fine on most platforms, but try using select on file handles or pipes
handles as you would in Linux on a Win32 or Solaris machine and you'll
witness completely unexpected results.

In my scenario of uniformity and shared components, there is always the
chance of platform specific quirk creeping up. I fully acknowledge this.
But at the same time, such a core as I describe would be geared to best
work with the platform it's built for to keep things as uniform as
possible.

I think it's important to not worry so much HOW this would be
accomplished, but rather that it COULD be accomplished, and if so, could
truly be something wonderful.

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

Why would you use APIs like those? Most user-agents just paint the
screen using normal application methods and not a special API. Just as
user agents currently and always have rendered. I'm simply proposing
that having the rendering, as well as the parsing process, each but it's
own system wide shared component.

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

Well the 'c' argument could go the same way :-)

I actually think it would of been very practical to have designed it
that way, as web development would be more rapid, as would the
technology advancements in this area.

[snip]

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

And you really want to tell me "JavaScript" really could not of
benefited from uniformity as I laid out instead of having so many
version of what should of been the same thing over the years? This was
(and to some smaller degree still is) one of the biggest headaches in
client side web development.

>
> 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 if my scenario, I'd assume the portable operating system running a
given handheld would have such components preinstalled (possibly
updatable via USB to your PC or wireless or modem connection, or the
likes.)

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

That can be true, but in my little scenario, the render would do it's
best, and the actual user, in the user-agent, would have full control to
override anything.

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

Which would not be the case if things had gone down the route I
described, as the core would of been long updated and the actual version
of the user-agent would be largely irrelevant.

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

Yes, but HTML still something that was growing over the years, and I
still believe having a separate core would of been the way to go,
allowing user-agent developers concentrate on the actual user-agent
rather then the core, as they would not be responsible for that part,
just only that it properly makes use of the core installed on the
system.

[snip]

> 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

Not a very good comparison considering parts of gcc are actually spread
about among the system. Actually it uses many shared components (many
form gclib), which is basically what I'd advocating :-)

> 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 body who was coming out with HTML, CSS and the likes made such
shared components, then the user-agent developers could of concentrated
on other things, and the development of better user-agents could of
evolved much quicker, and virtually independent on the version of the
HTML parser, CSS parser, ECMA parser, and the render-er that uses each
component.

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

CSS has been around since at least 1998, if they had gone the shared
components route, I'd imagine it would of gotten CSS out there quicker,
as uniformity could of made it infinitely more appealing early on, as
I'd imagine compatibility would be much less of an issue.

> 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 you're too worried of HOW things would be implemented instead of
what they would offer. If such a thing was developed, I'm sure all lot
of things would be considered and thoroughly dealt with. Same goes for
any major project of such a scale.

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

That would be great to see :-)

--
Stan

Chris Morris

2006-08-31, 6:51 pm

"Stan R." <stan@invalid.blz/hmrprint/com.com> writes:
> I think it's important to not worry so much HOW this would be
> accomplished, but rather that it COULD be accomplished, and if so, could
> truly be something wonderful.

I don't disagree that more uniform rendering (within graphical
browsers in the same context) would be useful, but my experience is
that the way to achieve this would not be to have a standards body
write a complex modular library that browsers would then plug in to.

In another field that I'm interested in, there are some people wanting
to work on generic engines for writing applications, and some people
wanting to write an application. The latter might be helped
considerably if any of the former were to succeed, but the former
don't succeed because the distinction between the generic part and the
application-specific part isn't very well defined. Similarly there are
some quite simple concepts implemented by the latter that would
nevertheless be unnecessarily complicated as part of a generic
engine [1]. I think it's much the same in HTML.

[1] As an example, consider a generic engine that could be used to
make games of chess, draughts and backgammon. It would be harder to
write that engine than it would be to write each game individually in
sequence. The analogy - like the programming language one - is flawed,
but I think the situation with the grey area between the rendering and
the interface is similar: writing a generic rendering engine that can
provide all the API and interface handles that any user-agent might
want is much harder than writing a specific one that only provides the
API and interface handles your user-agent needs.

>
> Why would you use APIs like those? Most user-agents just paint the
> screen using normal application methods and not a special API. Just as

Fine - you've still got XWindows, MS Windows, and Mac OS at least with
three different 'normal application methods'. (Mac OS X does have an
XServer, but most users prefer native looking apps, apparently)

>
> And you really want to tell me "JavaScript" really could not of
> benefited from uniformity as I laid out instead of having so many
> version of what should of been the same thing over the years? This was
> (and to some smaller degree still is) one of the biggest headaches in
> client side web development.

Of course it would have - but the software development process was at
that time working much faster than the standards process, and the
browser software developers benefited (at least temporarily) from
going ahead of the standards. Because they benefited they wouldn't
have been willing to wait.

>
> Which would not be the case if things had gone down the route I
> described, as the core would of been long updated and the actual version
> of the user-agent would be largely irrelevant.

Would the core have been updated, though? IE 6 has been available from
2001 *but* it's only in the last few months where the number of IE5.x
hits in my access logs has fallen to a relatively insignificant level
(and *still* it's more than all hits from Opera versions combined,
though usual caveats about web log files apply there...)

>
> If the body who was coming out with HTML, CSS and the likes made such
> shared components, then the user-agent developers could of concentrated
> on other things, and the development of better user-agents could of
> evolved much quicker, and virtually independent on the version of the
> HTML parser, CSS parser, ECMA parser, and the render-er that uses each
> component.

Hang on, though. Most of the delay between Netscape releasing the
Mozilla code as open source, and the Mozilla project releasing 1.0
(the first version to have a reasonably small number of rendering
bugs) was due to the Mozilla developers completely rewriting the
rendering engine (rather than work from the NN4 code). It took them
years!

> I think you're too worried of HOW things would be implemented instead of
> what they would offer. If such a thing was developed, I'm sure all lot
> of things would be considered and thoroughly dealt with. Same goes for
> any major project of such a scale.

The problem is that different browser manufacturers have *conflicting*
licensing requirements. Especially if you consider that 'freedom to
modify' is entirely contradictory with the goal of 'one uniform
universal implementation'. Just think how long the GPL-3 drafting
process is taking, for a licensing compromise of smaller scope. Having
the reference implementation tied up in lawyers for the first six
months to a year would only encourage people to write their own in the
meantime...

>
> That would be great to see :-)

Absolutely. The situation today is really a historical accident,
though, because of the *lack of concern* for (and often deliberate
breaking of) standards in the browser wars and the five-year pause in
IE development. A standard rendering engine, had it existed, would
have been either ignored or extended in incompatible ways.

Conversely, while the various parties might *now* be willing to accept
a standard "bug-free" rendering engine, it would take years to write
one from scratch and they already have mature rendering engines
anyway, that perhaps suit their purposes better (see above on
genericism of complex apps) and - IE temporarily excepted - are
pretty consistent in behaviour with each other.

I think it *would* have been great, but there are so many historical,
legal, technical and political reasons why it would never have worked
that the current situation - while not the best we could have had - is
going to work out pretty well in the end.

--
Chris

Darin McGrew

2006-08-31, 6:51 pm

Stan R. <stan@invalid.blz/hmrprint/com.com> wrote:
> That can be true, but in my little scenario, the render would do it's
> best, and the actual user, in the user-agent, would have full control to
> override anything.

And how is that different from the actual historical scenario?

FWIW, there are rendering engines that are being used by multiple browsers.
The Gecko engine is used by Firefox, Camino, and others. Various MSIE
shells use Microsoft's engine. KHTML is used by Konqueror, Safari, and
others. And so on.
--
Darin McGrew, mcgrew@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, darin@htmlhelp.com, http://www.HTMLHelp.com/

"Predictions are difficult, especially about the future." - Casey Stengel

Stan R.

2006-08-31, 11:00 pm

Chris Morris wrote:
> "Stan R." <stan@invalid.blz/hmrprint/com.com> writes:
>
> I don't disagree that more uniform rendering (within graphical
> browsers in the same context) would be useful, but my experience is
> that the way to achieve this would not be to have a standards body
> write a complex modular library that browsers would then plug in to.
>
> In another field that I'm interested in, there are some people wanting
> to work on generic engines for writing applications, and some people
> wanting to write an application. The latter might be helped
> considerably if any of the former were to succeed, but the former
> don't succeed because the distinction between the generic part and the
> application-specific part isn't very well defined. Similarly there are
> some quite simple concepts implemented by the latter that would
> nevertheless be unnecessarily complicated as part of a generic
> engine [1]. I think it's much the same in HTML.
>
> [1] As an example, consider a generic engine that could be used to
> make games of chess, draughts and backgammon. It would be harder to
> write that engine than it would be to write each game individually in
> sequence.

Maybe, but once it's written, it does make things a lot easier for
developers down the road. Look at the Quake engine. since the original
Quake came out, countless game developers licensed that engine for their
own games, and the engine itself evolved into Quake 2, from there
evolved into Quake 3, which lead to Doom III and Quake IV, and like
wise, the Quake/Quake 2 engine was licensed to create Half-Life, which
later evolved into the Source Engine.

[snip rest - I'm strapped for time, need ot make a flight. I will
re-read the rest when I reach my travel destination. ]