- From: Scott Luebking <phoenixl@netcom.com>
- Date: Tue, 30 Mar 1999 13:11:23 -0800 (PST)
- To: charles@w3.org, phoenixl@netcom.com
- Cc: kbradow@ece.eng.wayne.edu, rerlands@ece.eng.wayne.edu, w3c-wai-ig@w3.org
Hi, Just a clarification. Server-side scripting can have some limitations depending on the application. A very general one is that creaters of web pages may not have access to servers which provide the facilities needed. For example, may ISP's won't let a user create their own CGI scripts because of security issues, etc. A second problem is that the changes in the display could be more interactive than server-side scripting can be provide. For example, a page which uses element movement to convey information cannot be as easily done with server-side scripts. Another interaction problem is that the application may require faster response than provided by server-side scripts responding via a network. As with many things, there are trade-offs between server-side scripting and client-side scripting. Scott > In general, server-side scripting is more friendly that client-side > scripting. So-called DHTML (it isn't a particular thing, just the name > given to HTML that has client-sided active elements, included by means of > some script) tends to be pretty browser-specific. Netscape and Explorer, > the two browsers which implement lots of scripting, do a pretty poor job > of compaitibility. > > Using asp pages (for those who use Microsoft webservers - the rest of the > world achieves the results with php, CGI interfaces, Cold Fusion, Domino, > etc etc) allows the creation of "pure" HTML, which can be reliably used by > all users. It also, of course, allows the creation of something that > nobody can use - it is only when itis done right that it helps anyone. > (Likewise it is possible to write client-side scripting which transforms > gracefully in browsers which do not interpret scripts.) > > Charles
Received on Tuesday, 30 March 1999 16:11:37 UTC