Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Dynamic HTML: The Definitive Reference (2nd Ed.) 263

honestpuck writes "Many years ago I learnt my AppleScript skills from a book by a gentleman by the name of Danny Goodman and I was happy to find him tackling the subject of dynamic HTML in "Dynamic HTML: The Definitive Reference". Indeed this is the second edition and seems supremely up to date." Read on for the rest of honestpuck's review.
Dynamic HTML: The Definitive Reference (2nd Ed.)
author Danny Goodman
pages 1343
publisher O'Reilly
rating 9
reviewer Tony Williams
ISBN 0596003161
summary Truly definitive reference for a huge topic

Goodman has tackled a complex subject. With changing standards and even quicker changing browser compatibility it can be a nightmare trying to get a dynamic web site working across disparate browsers and operating systems. A guide that tells you exact syntax and exact compatibility can be invaluable, but is only as good as the research behind it, an area where I cannot fault Goodman.

This volume covers XHTML, CSS and DOM with a large smidgeon of JavaScript. It's not an easy book to get into and consume in large chunks as it does little hand holding but as I was prepared to knuckle down and work at the topics (with much help from various web sites such as CSS Zen Garden) I found it perfect for me. Goodman has recently released JavaScript & DHTML Cookbook which I have found to be a marvelous volume to assist the process of understanding these technologies, though I am still looking for a good, up to date tutorial on CSS (recommendations welcome).

The target audience would be best summed up as those who have done a fair amount of HTML hand coding and some work in dynamic HTML. The book also adds that you should have "the basics of client-side scripting in JavaScript" and I would agree, when I first acquired this book my JavaScript skills were exceptionally primitive (mainly at the 'plug in example' stage) and found the latter sections of this book heavy going and not much help; now that I am a better JavaScript programmer I find these parts much easier to understand and use.

The book is divided into four parts, 'Applying Dynamic HTML,' 'Dynamic HTML Reference,' 'Cross References,' and 'Appendixes'. I found the first part particularly helpful when converting my old site across to a more dynamic CSS-based site as it helps with various strategies for making sure your content works across browsers and various methods for making sure that visitors with older browsers and search engines can still retrieve valid pages. Goodman's approach of increasing complexity through this part also suited a movement from a straight HTML site to one using XHTML and CSS. This is also where Goodman's writing can shine: it's an excellent guide to all the technologies and acronym soup. The appendices are marvelous, from 'A,' a list of colour names with their RGB value, through a list of character entities to a 50-page list of all HTML tags, their attributes and if they are supported in the two HTML 4 and three XHTML 1 standards.

The reference parts are well structured with extensive notes on browser support and which particular standard (DOM 1, DOM 2, CSS 1, CSS 2, or none) the tag or attribute comes from. For example, in the DOM section the reference gives you the object name, which versions of Navigator and Explorer support it, the DOM version (if any), a short explanation, then an object reference example, list of properties, methods and event handlers. For each of the properties it gives an example, the type and if it is read-only or read/write. For methods it gives the return value and parameters. This sort of attention to fine detail is taken throughout the book. You end up with a book 1343 pages long and a 51 page index. Goodman mentions in his preface that the book now encompasses 'more than 15,000 unique instances of properties, methods and event handlers,' a figure I'd believe.

O'Reilly have their usual page for this book that includes a sample chapter in PDF, the Index, Table of Contents and an Errata page. There are few Errata and only one in the code examples. Speaking of examples, you can download the complete set of code examples from the book.

There is also a page at O'Reilly for the author, Danny Goodman with links to some excellent articles and book excerpts on dynamic HTML and JavaScript.

I found this a hard book to review, as are most references. The questions I asked were: one, Does the book cover all the material?; two, Is it correct?; three, Is it easy to find the entry you want? and four, Are the entries laid out in an easy to understand manner? In these criteria this volume rates well, with the added bonus of some good material in the first section for understanding the nuances of dynamic HTML in a multiple browser, multiple operating system world.

If you are doing a lot of work in dynamic HTML then this book is probably an essential. While I don't consult it every time I start working on HTML when I run into trouble it is the first place I turn to make sure my syntax and browser compatibility are straight. This book ain't cheap, and it ain't small but I'd recommend it for your desk if you're working with web sites.


You can purchase the Dynamic HTML: The Definitive Reference (2nd Ed.) from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Dynamic HTML: The Definitive Reference (2nd Ed.)

Comments Filter:
  • by Anonymous Coward on Wednesday June 18, 2003 @01:07PM (#6234726)
    When will Opera actually support the meatier parts of DHTML?

    Waiting around for everyone to start writing fully standards-compliant DOM-based DHTML is like waiting for the world to learn Esperanto.

    • When will Opera actually support the meatier parts of DHTML?

      A year ago. The more important question is when MSIE will do the same. My new site [utoronto.ca] currently looks like shit in MSIE even though I even made a separate CSS that did widths differently and forced alpha transparency on the logo.
      • by cheese_wallet ( 88279 ) on Wednesday June 18, 2003 @01:15PM (#6234812) Journal
        My new site currently looks like shit in MSIE even though I even made a separate CSS that did widths differently and forced alpha transparency on the logo.

        You can't polish a turd.

        • You can't polish a turd.

          LOL you bastard!!! I just got in trouble for laughing at that little comment! Two bosses came over and gave me the TPS-ish speech right in a row. Seriously though, grandparent has worse problems than IE compatability with that site.

    • Likewise, when do both IE and Opera get decent support for debugging JavaScript? Even NS 4 has Javascript console, where one can see error messages. IE can display some error messages, but only one by one, and messes up line numbers when including JS sources. As to Opera, I don't know how one is supposed to find problems occuring... I don't need a JS debugger, just seeing error messages would be a good start. :-/

      I tried a while ago to make a simple javascript app (spreadsheet) to work not only on NS4, Moz

  • by mahdi13 ( 660205 ) <icarus.lnx@gmail.com> on Wednesday June 18, 2003 @01:07PM (#6234730) Journal
    I guess the First Edition was not Definitive enough
    • Re:2nd Edition? (Score:5, Insightful)

      by el-spectre ( 668104 ) on Wednesday June 18, 2003 @01:10PM (#6234760) Journal
      Heh, it was for its time, but with the new browser versions, the 2nd edition is about twice the size as the old ones. 'tis the problem with client side web stuff, new browsers don't mean that you can stop supporting the older ones.

      I have this book, and it's neither cheap nor light, but definitely worth having as a reference.
      • Costs 50% more, too... from $40 to $60. Eeep!
      • Re:2nd Edition? (Score:3, Interesting)

        by pmz ( 462998 )
        ... the 2nd edition is about twice the size as the old ones.

        Whatever happened to the WWW simplifying things? :/

        The complexity of software development is certainly no less than it was ten or fifteen years ago...I think it has actually gone up significantly. The addition of hundreds of new buzzwords and embryonic toolsets has not helped at all.

        In many cases, customers or managers strive for gigamegagigantic things like .NET or J2EE, when all they really need is good 'ol CGI with a bell or a whistle here
      • the problem with client side web stuff, new browsers don't mean that you can stop supporting the older ones.

        Not strictly true (for DHTML at any rate). Most people with any sense stopped bothering with Netscape 4 long ago. If you keep creating ugly hacks to make otherwise standards compliant code work for a broken browser, you just encourage the unwashed masses to keep on using the damned thing...
        • Due to gov. regulations/business requirements/ international considerations, many projects have to work on Netscrape and Exploder 4+. Calling the users unwashed rarely goes over well with the business folks.
  • Bah... (Score:5, Funny)

    by BiteMeFanboy ( 680905 ) on Wednesday June 18, 2003 @01:08PM (#6234743)
    ... you haven't written dynamic html until you've written javascript that generates perl that generates html that generates javascript that builds perl code to filter the html. Heh, sometimes I miss the dot-com days.
  • Slashdot book review (Score:4, Interesting)

    by rkz ( 667993 ) on Wednesday June 18, 2003 @01:09PM (#6234750) Homepage Journal
    This one is a great addition to the book shelf,, you all know how to do certain things in HTML/DHTML but this book clarifies nicely why you are actually doing it. Also, it introduces nice DOM concepts which WYSIWYG web designers might not have come across before
    • I haven't seen this new edition, but the last edition is sitting right there on my "most frequently used books" shelf right in front of me.

      And those WYSIWYG web designers - coding is not something they're willing to do, or even think about. Except of course if its in Flash, which is somehow OK.

  • Re: (Score:2, Funny)

    Comment removed based on user account deletion
  • Good web source (Score:5, Informative)

    by (54)T-Dub ( 642521 ) * <[tpaine] [at] [gmail.com]> on Wednesday June 18, 2003 @01:11PM (#6234770) Journal
    If you need a good web site, I find these guys [devguru.com] have a very good reference for JS, HTML, ASP, vbScript, CSS, XHTML etc, etc
  • Anachronism (Score:3, Insightful)

    by jabbadabbadoo ( 599681 ) on Wednesday June 18, 2003 @01:16PM (#6234821)
    "For example, in the DOM section the reference gives you the object name, which versions of Navigator and Explorer support it,"

    Navigator is dead. So why the effort?

    No, I would rather see a book covering Explorer, Mozilla and Opera.

  • Dynamic HTML (Score:2, Insightful)

    OK, you web "coders", listen up. We, the general surfing public, are sick of Java, Flash, Javascript, CSS and "dynamic" anything. HTML was good enough for our grandparents and parents, HTML is good enough for us. It's a content description language, not a layout engine. We want data. When we click a link, we don't expect to see spinning globes or slowly assembling menus--we just want the next piece of data. Recent studies have found that up to 95% of bandwidth is wasted through over-designed websites.
    • Enough trolling for mod points, okay? Odds are, you dont know what the fuck you are talking about. CSS used properly is the best thing that ever happened to web sites. It makes sites smaller Idiot, by replacing tables with div tags. The gratuitous plug for /. is so fucking phony you should be banned.
      • Markup for a basic table layout is less than that used by the CSS in most cases. Feel free to prove otherwise.

        CSS is great for applying styles. It's layout mechanism sucks ass.

        • CSS is great for applying styles. It's layout mechanism sucks ass.

          Uhm... you obviously don't have any experience with CSS. DIV layers provide the best positioning system possible within a webpage.

          Just because you don't know how to do it, doesn't mean it sucks ass.
          • Except that I have plenty of experience with CSS, and I don't like it. It sucks ass. It's overly verbose (which is fine, but it makes me want to smack every person who says that using CSS will make your markup smaller). It's awkward to dynamically position elements relative to other elements, unless they are both absolutly positioned. Absolute positioning is lame, so that sucks. Even something as relatively common as "This element should fill the rest of the visible screen, wrapping or clipping where necces
            • <quote>It's overly verbose (which is fine, but it makes me want to smack every person who says that using CSS will make your markup smaller)</quote>

              That's why you should use a "Cascade" of style sheets, and not just one, or (horrors) in-line styles.

              This way, most of your css is in a default sheet, and any per-page or per-area customizations can be pretty small files, instead of including all the rules.

              The same applies to the javascript used for dynamic effects, validation, etc. Common functi

            • Funny... I have very limited exposure to CSS and I don't have any issues with what you are talking about. Dynamic positioning (Relative, I think is what you are saying) makes sense if you just think about math for a bit, and absolute positioning is good for a lot of things (headers, iconboxes, etc.) and I think you miss the whole point of cascading.

              I've built about 3 full-scale apps with web-interfaces to them as well, and they all have used CSS and all work just fine. PEBCAK...
        • <quote> Markup for a basic table layout is less than that used by the CSS in most cases. Feel free to prove otherwise.</quote>

          And markup for a table with individual cells with links to all sort of info, on a row-by-row or cell-by-cell basis, is more efficiently generated by a script, especially if you can offload the script generation onto the client's machine with a few lines of javascript.

          And then there's the side benefit of having the page dynamically generated, so all those links can be up

          • server side content generation doesn't really have anything to do with CSS. Client side creation of tables is a tossup - I go with generating the HTML (and the CSS for styling, and the javascript) on the server, because then my pages work without requiring Javascript. And it's a cleaner interface to the user, and faster rendering on the browser.
            • Well, we weren't talking about server-side generation, which is off-topic (the discussion is about DHTML). For that I use php :-)

              but think of it - any time you can get the client to do the work, you've taken a load off the server. For a 10-line table, we're not talking any difference, but for a 200-line table with each cell being clickable, and a different url for each row (to contain the necessary data and user info), we're talking a significant lessening of the load on the server.

    • damn tootin, bruddah --

      recent studies have shown that 99.51% of the viewing populace prefers a constant stream of raw binary! down with unicode! we shall destroy the micromacroadobeaolsoft running dogs like the craven infidels they are!

      --brought to you courtesy the Binary Liberation Front
    • Re:Dynamic HTML (Score:5, Insightful)

      by ceeze ( 631251 ) on Wednesday June 18, 2003 @01:35PM (#6235007)
      I agree that most web sites do not need extensive client-side scripting to be effective (slashdot is an excellent example). However, believe it or not, many businesses want to buy *Applications* that run in web browsers. They don't want the hassle and expense of deploying traditional client-server apps, but still want the functionality and usability of them.

      Standard HTML doesn't do that.

      Taking your example, even something as providing feedback in the form of an hourglass cursor while a lengthy operation is taking place has a measurable effect on the usability of these applications, especially for our target users (which is clearly not you). The browser is much more of an application platform than a simple layout engine.

    • Re:Dynamic HTML (Score:5, Informative)

      by Mr_Silver ( 213637 ) on Wednesday June 18, 2003 @01:52PM (#6235182)
      OK, you web "coders", listen up. We, the general surfing public, are sick of Java, Flash, Javascript, CSS and "dynamic" anything. HTML was good enough for our grandparents and parents, HTML is good enough for us.
      [snip]
      Look at Slashdot.

      Yes, look at Slashdot [w3.org]. The geek site that is so ashamed of it's HTML, it blocks the validator.

      If you try a different validator site, you find there are over a hundred errors [htmlhelp.com] on the front page.

      Lead by example?

    • Re:Dynamic HTML (Score:3, Insightful)

      Take your queue from these guys, web monkey.

      Oh, well, thank god it's just the web monkey's that fuck it all up. It's like the engineers that fucked up the roads by building massive SUVs and the musicians who fucked up the music industry. Now we know who to blame, we can tell them all to just fix it, right?

      Wrong.

      The reality is that web monkeys are just that, web monkeys. There are very, very few web gurus out there. In almost every case, they're working for managers who don't really understand the web bu
    • Hmm... methinks your handle "PhysicsGenius" gives the lie to your comment. My feeling, based on a lot of up-close examination of web usability tests, is that your emphasis on "just give me the data" is not shared by the majority of Web users. ;-)

      But seriously, the web design community has learned a lot over the years about usability. Ultimately the issue for the *real* general public is that they want sites that look good, are easy to navigate, and provide them with helpful information and/or transactiona

    • No Funny Mods on parent yet? Seriously though,

      Recent studies have found that up to 95% of bandwidth is wasted through over-designed websites.

      What's interesting is that 67% of statistics are made up on the spot. I'd also like to note that HTML was apparently NOT good enough for my grandparents.
      • <quote>Recent studies have found that up to 95% of bandwidth is wasted through over-designed websites. </quote>

        1. and another 50% is used up by spam
        2. and another 35% by people using Microsoft Update
        3. and another 40% by people downloading videos and mp3's (but because they're doing it over broadband, the **AA wants to count that as 245%)
        4. and another 20% is being used by worms, trojans, etc
        No wonder the net's so slow sometimes :-)
    • No, you listen up.

      All your servers are belong to us. We write the code, we control all the doors, we hold all the keys. You will take what we decide to give you, and you will bloody well like it.

    • Re:Dynamic HTML (Score:4, Insightful)

      by Superfreaker ( 581067 ) on Wednesday June 18, 2003 @02:42PM (#6235664) Homepage Journal
      "Look at Slashdot. With just a few lines of elegant Perl, Taco et al have created a slick, funcational, speedy, high-reliability site that eschews beauty in favor of pure information. Take your queue from these guys, web monkey."

      Anyone who tries to use slashdot on a wireless device knows that slashdot is one of the heaviest, ill-formed sites around.
      The homepage weighs 120K.
    • I know this is just flamebait. But I'll reply anyway, since there are still quite a few others out there.

      The truth is, without Javacript and DHTML, many complex web apps would be horrible to use. One example where DHTML is used a lot is in forms, for changing menus, dissabling or enabling controls, validation, etc etc. Without these, pages would have to be reloaded each time something had to be done. While this is OK sometimes, other times it can be terribly counter-intuitive and slow.

      As for slashdot, i

    • Look at Slashdot. With just a few lines of elegant Perl, Taco et al have created a slick, funcational, speedy, high-reliability site that eschews beauty in favor of pure information. Take your queue from these guys, web monkey.

      So? Slashdot has its needs, which are fairly simple. Allow viewing threaded discussions, send comments, set up preferences. Fine. That does not need necessarily need DHTML or applets.

      But you are making an assumption whole web is just a big Slashdot. It is not. Companies generall

  • Duplicate article (Score:5, Informative)

    by Jack William Bell ( 84469 ) on Wednesday June 18, 2003 @01:17PM (#6234828) Homepage Journal
    This book was already reviewed for /. here [slashdot.org]. Yeesh, can't anyone be troubled to do a quick search before posting?

    For what its worth, I owned a copy of the first edition and liked it so much I bought a copy of the second edition before the review mentiond above.
  • My first one is all dog-eared and out of date, but it still sits on my shelf and I occasionally refer back to it. Great book for learning and as a reference.

    Sadly, the only book I ever use these days is the Dynamic HTML Reference and SDK from Micro$oft (basically the same info you can get for free from msdn). If you're only supporting IE and just need a quick reference, that book is the bomb. Oh, am I not supposed to use the word bomb anymore? It is the bawm.

    I don't have a signature.
  • by rf0 ( 159958 )
    But does it show how to make gratuitous use of the tag :)

    Rus
  • by Anonymous Coward on Wednesday June 18, 2003 @01:25PM (#6234914)
    This book covers a huge amount of material. After all, DHTML is just a name used for the interaction of a bunch of different things, and this book seems to try to cover all of them. I wonder whether Goodman is really an expert on all of it (or whether anyone can be). I'd be a lot more comfortable trusting a book like this if it were written by a group of authors with different areas of expertise.

    Looking at what I can find about the book's coverage of CSS (which I know a lot about), I'm not optimistic. He seems to make up his own terminology, which can cause significant confusion in any public discussions. He uses the word "attributes" instead of "properties" (e.g., the CSS 'position' property) in the sample chapter available at O'Reilly. This is a mistake that's become very common these days, perhaps due to earlier editions of this book, and causes lots of confusion when people really need to discuss attributes (in HTML). The table of contents also shows sections titled by terms that he seems to have made up: "Common Subgroup Selectors" and "Advanced Subgroup Selectors".

    It could be that he's decided he doesn't like the terminology used by the CSS specification so he's making new terminology. Such a decision has significant costs for communication between and among web developers and standards organizations. However, I fear it may not even be a conscious decision, but rather than he just doesn't know enough about CSS to know the correct terminology. (Not that I would expect any one person to be able to learn enough about all the topics covered in this book to be an authority on all of them.)

    (If you want a good book on CSS, look for Eric Meyer's books on CSS, one of which is also published by O'Reilly.)
  • FYI: This book has been reviewed on Slashdot before [slashdot.org].
  • There's nothing dynamic about HTML. It's a flat staid format, which while often has bits and pieces added to it, is anything but dynamic.

    When we say DHTML or 'Dynamic HTML', aren't we really referring to the OTHER non-HTML technologies which make Web pages 'come alive'? For example, JavaScript and CSS. Without these the whole concept of 'DHTML' can't even be entertained.

    DHTML really doesn't exist in a concrete sense. It's just a vague concept. If you're going to write a book about JavaScript and CSS, then
    • HTML might be static, but since browsers (IE6+ and Mozilla) support Javascript, DOM, and CSS directly (no plugin), we might as well call HTML "Dynamic HTML".

      If you are careful to stick to APIs supported by both browsers, you can program DHTML interfaces that *are* dynamic and don't require plugins.

      IMHO, HTML 4.0 is yesterday's technology. Sites (and full applications) of the future will be built with very complex DHTML.

      See my other post to this article on using DHTML to create fully-dynamic applications
    • Hmm, have you actually seen this book? I don't care what precisely the title is - 'Dynamic HTML' is as good as any - but it's simply a superb reference and one of the top half dozen most commonly used books on my shelf. A more accurate title might be 'every single damm specification for HTML, DHTML, Javascript, CSS and evertying else connected with client-side browser behaviour exhaustively referenced, dereferenced and cross-referenced' - but that would be a bit long to fit on the cover.

      I've had the seco
  • though I am still looking for a good, up to date tutorial on CSS (recommendations welcome).

    Good thing I held off on my purchase at B&N earlier today. I literally had this book on Cascading Style Sheets [barnesandnoble.com]in my hand before I decided to hold off and get Definitive HTTP [barnesandnoble.com] instead (because of the recent review on this site. I didn't even notice that the copyright on the Style Sheets book is like from the Year 2000! Weren't we still carving TCP/IP packets byte for byte in stone and using the seeing stones of A
  • by conan_albrecht ( 446296 ) on Wednesday June 18, 2003 @01:33PM (#6234993)
    I'm wondering if DHTML could be the next GUI platform. We always hear that the "browser is the next platform", but DHTML could really make it happen.

    I recently programmed a groupware application with DHTML. Not the "little javascript trinket on my web site", but user interfaces created entirely by accessing the DOM, document, and window. There is no static HTML sent to the browser at all. It is entirely created in Javascript. A hidden window refreshes ever 5 seconds to pull GUI events from the server, and a client-side, DHTML event system processes the events to change the screen.

    The result is a fully dynamic, non-refreshing (at least to the user) GUI that approximates traditional applications. Except it runs within the browser with no plugins and no installation. I didn't even realize how powerful it could be until the application was done.

    For example, using a DOM/Javascript-based graphics library, we could create a diagramming application that ran fully within DHTML and the browser. No Flash, no Java, no extra plugins.

    There's a lot of problems to overcome. I had to be extremely careful so it worked in Mozilla and IE6+. It's not *truly* real time, but it sure looks like it. The components aren't as powerful as traditional components.

    Despite the problems, though, the benefits that it is pure web, no install, and standard browser can't be overstated. DHTML is really a powerful GUI language.

    BTW, the reviewed book was invaluable to my creating the program. It is a must have for any DHTML developer.
    • The browser is not suited for traditional applications in many realms. It can be leveraged into one - it's what I do all day at work - but it's just not suited for somethings. Complex GUIs are one of those things (drag & drop, for example, is a hassle to implement and looks crappy in a browser. Integeration with other applications is basically impossible).

      Oh, and if you're going to write thin client apps like that, IE is a far superior platform to Mozilla (assuming that it's a closed environment and no

      • You've raised the d-n-d issue, which seems to come up every time this topic is discussed. How big of an issue is this really? I can't think of a single app that I use regularly (Win2k - PhotoShop, UltraEdit, SQL Enterprise Mgr, Linux - Sun 1 Studio, Mozilla, Krusader, OpenOffice) that I use dnd in. Granted that's not many apps, and it may just be my usage style doesn't include it, so I'd like to hear any comments.

        I take that back about PhotoShop, I do drag stuff from one image to another occasionally.
        • Depends on your users, I suppose. One of the specs for my current project is that use of the keyboard is to be minimized at all costs, and the mouse should be the primary interface. All the desktop applications use drag and drop pretty much exclusivly. In my personal life, I don't use DnD much either, but apparently some people think it's really important.
      • The browser is not suited for traditional applications in many realms. It can be leveraged into one - it's what I do all day at work - but it's just not suited for somethings. Complex GUIs are one of those things (drag & drop, for example, is a hassle to implement and looks crappy in a browser. Integeration with other applications is basically impossible).

        Absolutely correct! Please stop trying to build fancy-pants GUIs on the web. It just is the Wrong Thing. Unfortunately there really isn't a good
      • <quote>HTML behaviors and extensions make obnoxious tricks like your hidden window totally unneccesary,&lt/quote>

        My guess is that he's using the hidden window to communicate w. the server, then manipulate the DOM in the visible window. This way, he's free to define all sorts of windows, opening and closing them at will, without having to worry that the "main" window accidently gets closed by the user and his app just disappears.

        Think of it, if he's specifying various target windows by name an

        • Yeah, I know, you don't need to do that with IE. IE's HTML behavoirs specify a "download" behavior that you can use to retrieve the HTML from an arbitrary URL, then call a callback function with the HTML retrieved passed as an argument. IE has alot of this sort of functionality which is great for thin client developers but not the sort of thing you'd want on a general purpose web page document.showModal, for example. No more accidently clicking next to the popup window and sticking it behind the main one! A
      • For that matter, you can embed ActiveX components in HTML pages rendered by IE. But may you rot in hell if you do. I've worked for months trying to automate (via screen-scraping) a web front-end for a third-party application that's built using embedded ActiveX controls *and* an out-of-process server on the client to store state, and it's the biggest heap of bloated crap you ever saw. "Thin client" my ass.
        • If it makes you feel any better, I only write REAL thin clients :P Anything of mine you'd want to use you can screen-scrape just by writing an IE plugin to parse the DOM. ActiveX controls of of the devil.
  • Actually... (Score:2, Insightful)

    by Anonymous Coward
    the definitive reference for HTML is located at the W3C.
  • Safari (Score:4, Informative)

    by enkafan ( 604078 ) on Wednesday June 18, 2003 @01:36PM (#6235030)
    This book is also available on Safari [informit.com]. Heck, three months membership covers the cost of the book :)
  • by sepluv ( 641107 ) <<moc.liamg> <ta> <yelsekalb>> on Wednesday June 18, 2003 @01:44PM (#6235105)

    IMO "Dynamic HTML" is a vague term which is usually used by people who do not know about the subject. However, not letting that put me off, I think that this book might be useful to a professional web hacker; although they might be better off with the individual O'Reilly books on the different subjects (e.g.: DOM, CSS, HTML, XHTML, ECMAScript) (or just tree-killed standards (while learning techniques by example on the good ol' WWW or in tutorials) for those of us that can understand standards &c or cannot afford the books).

    I looked at the first edition of this book in a shop and considered buying it, but decided against it due to its high price, the fact that I did not like the style (unlike most of the publisher's books which are IMO written excelently), and, mainly, my conclusion that HTML & XHTML: The Definitive Guide would be best for everyday design (as it has a little on other technologies (which are secondary to (X)HTML itself), and I can find about the details of these when I need them), though I'm not a professional.

    I bought HTML & XHTML: The Defintive Guide, 5th Ed [oreilly.com] and it was a good read (as O'Reilly books always are), although I was a little dissapointed with a few aspects: quite a few mistakes (not just typos or such like, but the authors not actually understanding (X)HTML and giving false information in contradiction to the W3C standards), the attitude the authors took of saying "you should do foo but here is how to do bar instead", and the lack of many real-world tips, tricks and tutorials (the kind of stuff that you cannot get from the W3C). However, I found that much of the content (like extensions to HTML, browsers and history) was useful to some extent. The HTML & XHTML book is probably a good book for non-professionals and those who do not want to shell out for Dynamic HTML: The Definitive Reference [oreilly.com], but still want a book. Maybe, there is an argument that to learn something well, it is best not using a book.

    I am considering buying the CSS guide [oreilly.com] (and just bought XML in a Nutshell [oreilly.com] which is very comprehensive (yet reasonably concise) and well written so I it recommend highly).

  • DHTML apps (Score:4, Interesting)

    by Luveno ( 575425 ) on Wednesday June 18, 2003 @02:14PM (#6235414)
    We've pretty much given up on DHTML-driven apps - they are too hard to modify and maintain. Use some Javascript to do some form validation and light stuff like that, but at some point you really are better off just repainting the darn screen instead of delving into DOM madness trying to hide table rows and the like. Being a Microsoft shop, we've pushed hard to move to using .NET web forms, and we've been able to forget that we are writing for web browsers. =)
    • And soon we J2EE developers will be doing similar with JavaServerFaces [jsfcentral.com]. It seems like a much nicer level to work in.

    • <quote> Use some Javascript to do some form validation </quote>

      ... but don't forget not to trust what your form returns, just because you validate it with some script. There's nothing to stop people from modifying your form to submit bad values (I know, many already know this, but there are still a lot of people who don't, or forget it).

      The only purpose of form validation on the client is to prevent useless round trips to the server.

  • CSS References (Score:5, Informative)

    by foo fighter ( 151863 ) on Wednesday June 18, 2003 @02:33PM (#6235568) Homepage
    I am still looking for a good, up to date tutorial on CSS (recommendations welcome).


    I use two references for CSS.

    The first is the book Cascading Style Sheets- 2nd ed: Designing for The Web by Hakon Wium Lie and Bert Bos. From what I understand, these two guys basically invented CSS. You can find it on Amazon [amazon.com] and at the publisher, Addison-Wesley [awprofessional.com].

    (BTW, I've never been disappointed by an AW book. They're up there with O'Reilly in my mind.)

    The other resource is on the web, the ZVON.org CSS1 Reference [zvon.org] and CSS2 Reference [zvon.org].

    The book has a couple minor shortcomings (you can read about them in Amazon's customer reviews). Those shortcomings are overwhelmed by 1) the authority of the authors, 2) the functional organization, and 3) the readability.

    The authors know their stuff. They invented the technology for crying out loud.

    The book is organized by function meaning typography control is one chapter, positioning is another, and so on regardless of which standard the property comes from or which browser supports it. This book is where you go when you can't remember, or need to learn, how to do something.

    (There are notes for each property on browser support, but they are outdated. For that quickly changing information I recommend The Noodle Incident's CSS Panic Guide Browser Reference [thenoodleincident.com].)

    The author's use a very readible voice. The examples are a bit simplistic but functional and they express the concept.

    I like ZVON.org because it offers a no nonsencse reference. It's basically a clean cut dictionary of CSS. No other site I've seen is as quick to provide the answer for which you are looking. Use it when you need to refresh yourself on the exact order of values for shortcut properties (like background [zvon.org], font [zvon.org], etc.).
  • This would be an EXCELLENT reference... I've had the first for a few years, and use it to help train my employees on (and remind myself about) proper use and functionality.

    It was much better than "Cats".
  • This book sits on my shelf along with Thomas A. Powell's HTML: The Complete Reference, Second Edition. These are 2 of the best reference books I've ever seen. I pick up so-called "reference" books all the time that are nothing more than product walk-throughs, case studies, or vague overviews. A good reference book is hard to find and invaluable once found.

  • a good, up to date tutorial on CSS

    I second the AC's recommendation of anything by Eric Meyer, especially Cascading Style Sheets: The Definitive Guide (O'Reilly). His latest, Eric Meyer on CSS, is a hands-on tutorial/workbook.

  • Does it have an object->CSS cross reference yet? Although I use the 1st edition a lot, it lacks a way of quickly checking which css styles an element supports in which browsers.

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Working...