 |
 |
On 11 Apr 2002 at 16:24, H.E.Ayestaran wrote: > Hi, > > I've been following the debate about the use of DHTML, and I > thought that there are a few points that ought to be clarified. > The problem with JavaScript, or most client scripting languages > for that matter, is not so much the language itself (which is > usually standard, although different versions may include > different functionality, such as the 'try' and 'catch' keywords > which actually create problems for older browsers), but the way Variations in the core language can be controlled by specifying the language attribute in the SCRIPT tag. This allows a very modular approach to be taken to supporting different versions of the language so that various flavours can exist side-by-side. > in which it interacts with the client browser. This is done via > the Document Object Model (DOM) which acts as an interface > between the scripting language and the browser. So far so good, > except for the VERY PROBLEMATIC FACT that the DOM changes from > browser to browser, and from version to version (IE5.0, IE5.5, > IE6.0, Netscape, etc). This creates SERIOUS compatibility > problems, but most importantly, serious future-proofing > obstacles, which in my view are just too great for these types > of projects. As we have discussed previously in this thread, an excellent way to combat DOM changes is to test for support for the particular part of the DOM that you wish to manipulate. There are some superb object-oriented approaches to creating neutral code to handle this kind of thing: if you are technically inclined I would very much recommend you de-construct some of Thomas Brattli's scripts at www.dhtmlcentral.com. > > As an alternative I would suggest the use of a very basic > interface (pure HTML), AS WELL AS an extra interface that uses > one of two approaches: either Java (for the computationally > unchallenged :-) or Macromedia Flash (for an easy way to create > fairly interactive and impressive pages). In fact, Flash allows > a fair amount of more serious programming if necessary, but most > tasks can be easily achieved. Both these approaches provide a > large level of compatibility, and a fair level of future-proofing > (Java would seem better at this, although Flash is now is widely > accepted). Finally, I would have to say that from experience, Flash > cuts down development time very significantly, and reduces a lot of > the effort in making sure that it works across all browsers (the > plug-in does this for you). It is pretty apparent these days that the original write-once-run-anywhere dream of Java is not going to be a reality. There is now a fragmented code base for Java where support for code is reliant on the version of the Java Virtual Machine installed on the client, where neutral support across platform is not consistent and where backward compatibility of the JVM is not assured for all parts of the language. Java deployments on the web are also likely to encounter more browsers where Java is disabled as a security measure then is the case for javascript, which means that unless the java applet is being provided purely for decorative reasons and can be ignored, a completely separate set of pages will likely have to be produced to allow access to non-java enabled browsers. One advantage of javascript is that the script can be used to enhance a page without blocking the core content from non-javascript browsers. With regard to Flash, your comments regarding development time and power are valid. However, for public access projects it is important to understand that the proprietary nature of the format means that there is no guarantee of free access to the format into the future Further issues include: that there are no possibilities for parsing the file structure to draw out information for indexing purposes within the flash file, that there is little scope for repurposing the content within the file (basically a binary compilation), it is not possible to create external links to some point within the structure of the file. And further more, the development of the plug-in is prone to version problems too, and the nature of the .fla -> .swf process of creating a flash file means that the loss of the source (.fla) can make future updating a huge problem. Unless care is taken to store the fla file in a methodical manner alongside the web content, maintenance can become impossible. So in conclusion, I would say that your basic premise of "SERIOUS compatibility problems" and "serious future-proofing obstacles" apply just as much to java and flash as to javascript applications, with the additional problems as discussed above to deal with too. Peter Dowdell NOF-digitise Technical Advisory Service > > Just my grain of sand... > > Horacio > > --------------------------------------------------- > Horacio E. Ayestaran ([log in to unmask]) > SINE Project ICT Manager > Rm 2.21 Bruce Building > University of Newcastle-Upon-Tyne > United Kingdom > Tel: (+44)(191) 222-3654 > > > > -----Original Message----- > > From: This list is for people who are receiving New > > Opportunities Fund Digitisation funding. > > [mailto:[log in to unmask]] On Behalf Of Tony Crockford > > Sent: 09 April 2002 18:39 > > To: [log in to unmask] > > Subject: Re: DHTML & Javascript > > > > > > >Can any tell me if DHTML and JavaScript are acceptable within a NOF > > >project. I can't seem to find any mention of them with the > > guidelines. > > > > > >Thank you > > > > > >Tony Brindle > > > > > > > From the FAQ: > > (http://www.ukoln.ac.uk/nof/support/help/faqs.htm#DHTML) > > > > <quote> > > 9. Can we use Javascript and DHTML on our NOF-digitise Web site? > > > > The use of client-side scripting (including javascript and DHTML > > techniques) is acceptable, however please take note of the following > > points: > > > > 1) The site must still be accessible to browsers which are > > not scriptable. Use <noscript>< tags and "sniffer" routines > > to determine the client capabilities and provide > > content-equivalent pages to non-scriptable browsers. > > > > 2) Thoroughly test your pages for functionality under a wide > > range of browser / platform configurations. > > > > </quote> > > > > > > Seems fairly straightforward. > > > > Good info on sniffer routines can be found here: > > > <http://www.webreference.com/tools/browser/links.html> > > Note that most client side routines use Javascript (sort of a > catch-22 possibility) and this is the ultimate: > > <http://www.mozilla.org/docs/web-developer/sniffer/browser_type.html> > > Hope you find this useful. > > Tony > > > > > > -- > If you're suffering from email overload, check out NEO: > http://www.caelo.com/a/rl.php3?i=3NTVV