TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: CSS with Netscape From:"Wing, Michael J" <mjwing -at- INGR -dot- COM> Date:Thu, 25 Mar 1999 14:46:25 -0600
> No, Mike, it isn't. There was nothing at all stopping MS from
> implementing CSS fully *in addition* to the extras. They chose
> to ignore the standards and create a product that will instead
> lock a web developer into using their own proprietary product.
>
> VBScript is a good example. They have purposely made their
> "Jscript" non-compliant with the ECMA standard, and are routing
> developers towards their proprietary scripting language. They
> *could* have chosen to do a standard scripting language, but
> that would have meant that people would have had a choice between
> their tools and someone else's. That's heresy in Redmond.
>
>
> Have fun,
> Arlen
>
"Standard" scripting will not create objects. "Standard" scripting will not
return a programmable object for a currently running application.
"Standard" scripting will not manipulate ActiveX controls. These require
things like the CreateObject or the GetObject method. JavaScript does not
have these.
Browsers are quickly becoming more than a text and picture viewer. They are
progressing toward being an application interface. It is my opinion that in
the near future applications will be built and run server-side and
manipulated client-side. Most users will have a terminal, a mouse, a
keyboard, and an internet connection (but the computer is at the server).
They (the users) will run the application through a browser (a "thin
client"). No more "every station has a copy of the application on it".
The client will receive a collection of applets and/or ActiveX objects that
construct the application interface in the browser when they connect to the
server. As the application grows and is modified, the client receives
new/replacement applets/ActiveX controls which automatically upgrade the
interface.
Okay, what does this have to do with browsers? Well, everything. The
client will need browser that can manipulate a variety of applets and
ActiveX controls. It may have to be able to handle various scripting
languages. I fully expect to see IE use VBA instead of VBScript soon.
Because the browser becomes a mutable application interface, it must be
robust in its model. Netscape is not.
Evil empire or not, they (MS) are the only ones that "appear" to be
progressing toward a browser that is suited for web applications. It is my
dream that all browsers become strong interfaces, handle a variety of
scripting, and respond to the same syntax. It is not my dream to tie down
the ones who at least are making an attempt at making web browsers the front
end of an application (while others twiddle their thumbs).
Mike
Michael Wing (mailto:mjwing -at- ingr -dot- com)
Staff Writer/ Web Applications Developer
Intergraph Corporation; Huntsville, Alabama http://maps.intergraph.com
