Thursday, December 02, 2010
Blog Entry #198
Two other complaints:
(2) If Joe is going to use the word "standalone" to describe a Java application, then he should briefly discuss running Java on the command line, but he doesn't. Relatedly, Joe says,
Java applets run independent of the HTML document that is calling for them; this is true in the sense that the browser reads a page's HTML whereas it hands any applets off to a plug-in, but as <object>-type elements go, applets are really not so "independent": unlike embedded images and (iframe) documents, applets cannot be rendered outside of a document context - you can't double-click an applet .class file on the desktop and run it like a C executable, for example.
"From DHTML to DOM Scripting [Part 1]" and Part 2
The articles' title posits a false distinction between DHTML and the DOM: when you mutate a document on the fly via a DOM 'setter' operation, you are definitely engaging in DHTML. But don't take my word for it. Consider the append-a-link-to-a-parent-element code that appears in Part 2: the createElement( ), setAttribute( ), appendChild( ), and createTextNode( ) DOM Core methods employed by this code are all listed on Microsoft's DHTML Methods page.
"Browser Detect Script"
Credited to Dan Ragle and imported from WebReference.com, this tutorial presents a colossal, annotated browser-sniffing script - a script that is Exhibit A as to why everybody should code to the W3C's standards, and that's as much as I'm going to say about it.
*BTW, upon throwing out the navigator.appVersion and navigator.appName tests, the rest of the openAndCenterWindow( ) code works just fine with MSIE 4.5 in the SheepShaver environment.
(1) a forms.html opener document;
(2) a style.css style sheet that applies various styles to the forms.html document; and
(3) a help.html remote control document.
A files2 folder containing these documents can be downloaded via the zip file link at the end of the Conclusion section on the tutorial's third page.
Deconstruction-wise, the author doesn't discuss the forms.html and style.css code at all but provides a reasonably detailed analysis of the help.html code. We ourselves will not go through all of the code line by line but rather will paint a general picture, fill in some blanks, and perhaps suggest some coding alternatives. And as that might take a while, we are probably better off putting it off until the next entry.