On 9/4/05 (10:31 ) Bob Hanson wrote: >Tim, I think the strongest case for using Jmol.js generally, and not >just for fancy applications is durability. By this I mean, when the >time comes and browsers change and functions work differently on >different browsers (say IE really drops the APPLET tag, for >example). I've been through the Netscape 3,4,6,7 years, as I think >you have. I was lucky, because early on I learned to put everything >browser dependent in a separate .js file and call functions like >divWrite() and divFind() and such. Well, of course, when >document.getElementById() came in and I can't even remember now what >went out, I didn't have to go rewrite all my hundreds of pages. I >just updated a file called "divs.js" in a bunch of directories (I >wasn't THAT lucky, to have just one single divs.js), and I was off >and running. >
hi Bob, ironically, if you had not used js to write your div tags, you would not have had to do anything at all, since it was javascript that changed and not the div tag. external stylesheets accomplish the same for css, and DOCTYPE/DTDs are (presumably) a way to ensure that your html/xml code will not be pulled out from under you. javascript is not the panacea against language evolution, since it too evolves (as your example illustrates). all you do is trade one set of changes for another, at the expense of simplicty and clarity IMO. sorry, but I don't accept the argument that javascript makes the code more durable. good code writing practices do. > ><applet> is probably the next to go. > what was the last major html tag to be dropped (not deprecated; dropped altogether)? applet has been on the chopping block since 1999 at least; about as long as font <http://www.w3.org/TR/REC-html40/present/graphics.html#h-15.2.2>. yet both are still supported, even in the newest browsers (Firefox, Safari, Opera?). even if the major browsers decided to stop supporting a tag as widespread as applet (and I seriously doubt this will happen soon), site management tools make keeping up with these changes straightforward. even a simple grep can do it without much thought. >In fact, seriously, if one wanted to, one could just always load >http://jmol.sourceforge.net/jmol/Jmol.js directly > I would never argue against using well-formed, shared libraries of javascript functions. this is good code writing practice. but they should do things that javascript does best: initializing, screening, changing elements in response to user input, etc. I do not see the need to use javascript for writing static html or css code. too much glue. tim -- Timothy Driscoll molvisions - see, grasp, learn. <http://www.molvisions.com/> earth:usa:virginia:blacksburg "To give anything less than your best is to sacrifice the gift." - Steve Prefontaine ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
