What DHTML is

Jim Ley sputtered:

<http://lists.w3.org/Archives/Public/w3c-wai-ig/2004JanMar/0138.html>

(And it was Dave Shea writing immediately below, not me, but Jim's 
mailer couldn't know that)
>>>4.  Graceful transformations into lists etc. where the browser 
>>>does not or is set not to support scripts and/or css.
>
>>Richard's menus do this. The DHTML menus don't have a chance.
>
>What a ridiculous assertion, there are lots of DHTML menus that 
>degrade to lists.
>
>>So in summary, counting the various 'almosts' as halves, that's a 
>>score of 5.5/7 (disregarding point 8) for Richard's, and 1.5 or 
>>2/7for the DHTML menus. Clearly we're on the right path.
>
>Except of course you've got a very peculiar definition of "DHTML menus"...

So I ran this by an expert. Longtime readers will be aware that I 
tend to do that. (And tend to know the experts.) Steven Champeon, 
coauthor of _Building Dynamic HTML GUIs_ <http://dhtml-guis.com/>, 
take it away!


>Traditional DHTML consists of HTML, JavaScript, and CSS working in 
>tandem or simply HTML and scripting with no CSS (though that's less 
>common nowadays). Alternate definitions include JSSS and Netscape's 
>layers model as necessary components; some simply refer to "CSS-P", 
>the precursor to CSS positioning that represented a compromise 
>between MS and NS. Microsoft tends to refer to it as "anything that 
>uses the IE DOM". My book tried to use "cross-browser DHTML" as a 
>term of trade to distinguish my approach (also used to a lesser 
>extent by Shelley Powers and Danny Goodman, and from whom I drew 
>many of my ideas) from the more common "so? it works in my browser" 
>attitude then common among developers (especially IE-centric ones). 
>There were lots of xbrowser libraries out there, and most of them 
>were more popular than mine ;) I was more interested in using DHTML 
>to build applications; most of the other folks who used DHTML just 
>wanted whiz-bang glitzy but useless and annoying stuff, like clouds 
>of stars that followed your cursor around, or what have you.
>
>If you go by the traditional definition, which in many circles has 
>been discredited - if it uses IEDOM or NSDOM, it's "DHTML", whereas 
>if it uses W3C DOM it's not DHTML proper - this tack draws the DHTML 
>line at NS4/IE4, which is why nobody will ever see the 1000pp DHTML 
>Bible I and Scott Lepera wrote for Hungry Minds/Wiley; nobody wants 
>anything to do with DHTML, because that's seen as an obsolete 
>technology. Sad but true, at least as far as the market is 
>concerned. But DOM? Scripting? CSS to make dynamic stuff? That's 
>great! Bring it on. It's a weird industry.
>
>As far as menus go, there are three characteristics they should exhibit:
>
>  - they can be shown/hidden (usually, but not always, by CSS 'display'
>    or 'visibility', modified by way of some scripting logic) and may
>    or may not "fly out", unfold, or something else relatively useless
>    but seen as desirable eye candy by people who should know better;
>    or have submenus and the like.
>
>  - they consist of HTML markup, usually but not always included in the
>    document body (some of the worse examples use JS to dynamically
>    create the markup and insert it into the document flow).
>
>  - they contain some form of navigation or more traditional application
>    UI logic (e.g., "File->Save"); the basic nav is usually just anchors
>    and so is supported natively, whereas anything more complex than that
>    is more dependent on scripting.
>
>But if you prefer to think of "DHTML menus" as "navigation that 
>changes in some way in response to user input", then you open the 
>field up to stuff like Eric Meyer's "pure css menus":
>
>	<http://www.meyerweb.com/eric/css/edge/menus/demo.html>
>
>I wouldn't call these "DHTML menus", though. The big problem is that 
>"dynamic HTML" has a lot wider definition than "DHTML", which was 
>used (and beaten to death) by Microsoft and Netscape during the 4.x 
>browser wars and has the added associations of obsolescence, 
>non-compliance with Web standards, and general clunkiness, along 
>with being a truly inspiring pain in the neck to work with. But the 
>folks who think of "dynamic HTML" in the broad sense often use the 
>abbreviation "DHTML" to describe anything that responds dynamically 
>to user input, which includes stuff like CSS hover. So, yeah, it's a 
>mess.
>
>I wrote my first book on "traditional DHTML" and tried like hell to 
>get people to abandon the association between NS4/IE4 DOMs and DHTML 
>as a moniker, but haven't had much luck. So nowadays, I guess I use 
>the term to describe anything that involves scripting /and/ CSS 
>/and/ markup. I tried to get DXHTML adopted as a trade term, as a 
>way to drum up some interest in getting the DHTML Bible published, 
>but no luck there, either.
>
>I don't know if this helps. It's difficult to understand exactly 
>what everyone is referring to in the messages you sent; for example, 
>note the several references to various Netscape browsers as 
>"Netscape", which is apparently either "dead" or "modern"; not 
>helpful if you don't specify the version numbers. Shrug.
>
>Steve
>
>--
>hesketh.com/inc. v: (919) 834-2552 f: (919) 834-2554 w: http://hesketh.com
>Book publishing is second only to furniture delivery in slowness. -b. schneier

-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Expect criticism if you top-post

Received on Tuesday, 20 January 2004 18:49:44 UTC