DHTML in NN and IE

[viator]

Hello everybody. I am a student doing my masters in Comp. Sci. Will
some explain to me why it seems completely two worlds when taking
about DHTML in NN and IE. Is there any way to write truly portable
webpages using DHTML ofcourse.

[David Dorward]

viator wrote:

Hello everybody. I am a student doing my masters in Comp. Sci. Will
some explain to me why it seems completely two worlds when taking
about DHTML in NN and IE.
Becuase there was no standard, so Microsoft and Netscape implmented their
own inventions.
Is there any way to write truly portable
webpages using DHTML ofcourse.

Use the w3c & ECMA standards, along with (if you desire compatability with
legacy browsers) routines to cope with the document models of older
browsers.

--
David Dorward http://david.us-lot.org/

[Grant Wagner]

David Dorward wrote:

viator wrote:

Hello everybody. I am a student doing my masters in Comp. Sci. Will
some explain to me why it seems completely two worlds when taking
about DHTML in NN and IE.

Becuase there was no standard, so Microsoft and Netscape implmented their
own inventions.

Is there any way to write truly portable
webpages using DHTML ofcourse.

Use the w3c & ECMA standards, along with (if you desire compatability with
legacy browsers) routines to cope with the document models of older
browsers.

Of course, even this does not guarantee "truly portable" web pages, unless of
course, you define "truly portable" as: works on full-featured personal
computer web browsers written in the last 2 years.

There are still lots of browsers (old and new), on lots of platforms, which do
not properly support or implement W3C standards.

This is why it is recommended that you use client-side JavaScript only to
enhance your existing web page functionality, not replace any functionality.
Anything you want your visitors to do should work regardless of whether
client-side JavaScript is enabled or available. Once you have a working site,
then you add client-side JavaScript to enhance that already existing
functionality.

Of course, for Intranet/private web-based applications, you have more freedom
to exploit client-side technologies, since you have some (or total) control
over the target browser.

--
| Grant Wagner <gw*****@agrico reunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 6/7 and Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[Phil N]

viator wrote:

Hello everybody. I am a student doing my masters in Comp. Sci. Will
some explain to me why it seems completely two worlds when taking
about DHTML in NN and IE. Is there any way to write truly portable
webpages using DHTML ofcourse.

It's because Bill Gates does everything he possible can to eliminate competition
in the computer software industry _period_

(And now he's trying to move into the hardware world.)

If Bill had his way you'd have to pay him to turn on your computer then pay him
again to connect to the internet then pay him again for every page you viewed -
ad infinatum.

I know it's a little off-topic for the ng but Gates _has_ done everything he can
to screw JavaScript. It just didn't work. But he's still trying.

--
Phil Newcombe - philn?telus?net
http://www3.telus.net/bikim

Netscape/Gecko/Mozilla - standards conformance and cooperation
Internet Explorer - standards obfuscation and divergence
Linux += 30,000/Germany + 80,000/Spain + tomorrow

[DU]

Grant Wagner wrote:

David Dorward wrote:

viator wrote:

Hello everybody. I am a student doing my masters in Comp. Sci. Will
some explain to me why it seems completely two worlds when taking
about DHTML in NN and IE.
Becuase there was no standard, so Microsoft and Netscape implmented their
own inventions.

Is there any way to write truly portable
webpages using DHTML ofcourse.

Use the w3c & ECMA standards, along with (if you desire compatability with
legacy browsers) routines to cope with the document models of older
browsers.

Of course, even this does not guarantee "truly portable" web pages, unless of
course, you define "truly portable" as: works on full-featured personal
computer web browsers written in the last 2 years.

There are still lots of browsers (old and new), on lots of platforms, which do
not properly support or implement W3C standards.

This is why it is recommended that you use client-side JavaScript only to
enhance your existing web page functionality, not replace any functionality.
Anything you want your visitors to do should work regardless of whether
client-side JavaScript is enabled or available. Once you have a working site,
then you add client-side JavaScript to enhance that already existing
functionality.

Exactly! Very well said and I absolutely agree. Define the HTML
structure, then add the content and then add client-side javascript to
enhance presentation of content or ease navigation: these are the
correct steps by which everyone should build a webpage. If javascript is
disabled (8%-12% of people surf with javascript disabled), then the
content should still be accessible, usable, reachable.

Validate your HTML markup so that if visitors use some assistive
technologies (speech browsers, text browsers, braille browsers, web tv,
translation software, etc.), handheld web-aware devices, a web-aware
device based on another medium or technology, then the content should
still be accessible, reachable, usable. W3C web standards compliant
markup code can and should always be accessible, reachable, usable by
W3C web standards compliant applications, softwares, devices on
different media, os, platforms, languages, etc..
Of course, for Intranet/private web-based applications, you have more freedom
to exploit client-side technologies, since you have some (or total) control
over the target browser.

--
| Grant Wagner <gw*****@agrico reunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 6/7 and Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/

[DU]

Grant Wagner wrote:

Phil N wrote:

viator wrote:

Hello everybody. I am a student doing my masters in Comp. Sci. Will
some explain to me why it seems completely two worlds when taking
about DHTML in NN and IE. Is there any way to write truly portable
webpages using DHTML ofcourse.

It's because Bill Gates does everything he possible can to eliminate competition
in the computer software industry _period_

(And now he's trying to move into the hardware world.)

If Bill had his way you'd have to pay him to turn on your computer then pay him
again to connect to the internet then pay him again for every page you viewed -
ad infinatum.

I know it's a little off-topic for the ng but Gates _has_ done everything he can
to screw JavaScript. It just didn't work. But he's still trying.

The above is inflamatory and inaccurate. Using your logic, Netscape was trying to do
everything it could to eliminate competition in the computer software industry by
adding <layer> and <blink> to Netscape 4.

In the absense of any real standards to have versitile control over a web browser's
DOM, Netscape created their own (document.layer s) and Microsoft created their own
(document.all). If the situation of lack of standards had gone on longer, you most
likely would have seen these "standards" embraced by other browser vendors (as is
the case with document.all in Opera) or new "standards" emerging to provide
functionality not provided by the already listed mechanisms.

Now that there are W3C standards, a complete re-write of the Netscape rendering
engine has resulted in standards compliance, and Internet Explorer and Opera 7 are
well on their way. If what you say is true, Internet Explorer would not support
document.create Element/getElementById/createTextNode/etc

I'm just going to add one small point to your excellent reply. MSIE 6.x
or MSIE 7 version can not furthermore support CSS2, DOM2 properties and
methods without underlying changes and major adjustments in the
operating system. This is the conclusion reached by Peter-Paul Koch in
his article
"Browser Wars II: The Saga Continues."
http://www.evolt.org/article/Browser...nues/25/60181/

"The famous talk show transcript says: 'Further improvements to IE will
require enhancements to the underlying OS.' I tentatively translate this
line as 'We cannot improve IE any more' because it fits with an idea
I've had in the back of my mind for two years now.
Why is Microsoft unwilling to fix the CSS bugs that everyone's been
asking it to fix for ages? I think it's not unwilling but unable to do
so. Explorer's code engine cannot be updated any more.
Sooner or later, browser makers run into the limitations of their
programs. Their large libraries have a tendency to grow fat and hard to
change, especially when they must incorporate functionalities that
weren't foreseen when the original program was written. (...)"

I think this is exactly what happened to Netscape and Opera: Netscape 6
was a complete rewrite of the Netscape software and so was Opera 7. They
had to rewrite the software entirely in order to meet the requirements
of CSS2, DOM2... and we can suspect or deduce that XSLT is furthermore
requiring from an os.

MSIE 7 for Windows is now expected for 2005. Until it is released with
Windows Longhorn, Mozilla 1.4+ will definitively be the most W3C web
standards compliant and most advanced browser available.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/

[Phil N]

DU wrote:

I think this is exactly what happened to Netscape and Opera: Netscape 6
was a complete rewrite of the Netscape software and so was Opera 7. They
had to rewrite the software entirely in order to meet the requirements
of CSS2, DOM2... and we can suspect or deduce that XSLT is furthermore
requiring from an os.

MSIE 7 for Windows is now expected for 2005. Until it is released with
Windows Longhorn, Mozilla 1.4+ will definitively be the most W3C web
standards compliant and most advanced browser available.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/

I'm no expert, obviously, but I am thinking the rewrite was also to include new
technology where the code involves plenty of xul and related stuff. I got the
impression that it is kind of written in xml (or something related) allowing
'on-the-fly' updates - kind of like updating your browser by downloading a web
page, a-la xpi.

As far as accessibility - that's a personal point - kind of like saying when you
write an application you should first write it in dos because some people still
use it. Then port it to every other os imaginable so everybody else can use it too.

(And 'inflammation' is all in the mind, like boredom - one man's inflammatory
comment is another man's truth. But that's ot.)
--
Phil Newcombe - philn?telus?net
http://www3.telus.net/bikim

Netscape/Gecko/Mozilla - standards conformance and cooperation
Internet Explorer - standards obfuscation and divergence
Linux += 30,000/Germany + 80,000/Spain + tomorrow