Dynamic HTML The Definitive Reference (2nd edition) 243
| Dynamic HTML The Definitive Reference (2nd edition) | |
| author | Danny Goodman |
| pages | 1400 |
| publisher | O'Reilly |
| rating | 10 |
| reviewer | TheThinMan |
| ISBN | 0596003161 |
| summary | The most complete reference work for HTML, DOM, CSS and Javascript, cross referenced for all the major browsers and standards. |
What's in the book?
The book is not an introduction to DHTML but it does have an 183-page section on Applying DHTML that covers not only the current state of the art but also gives clear guidance in making use of all the features. The guidance is of a good enough standard that a firm's Quality program could simply cite this book as the basis for the web development standards that a team adopts. Goodman makes it very clear that he is not going to discuss the DHTML that Navigator 4 introduced, the <layer> tag and JavaScript style rules, but points out that they are covered in the first edition should you really need to know.
The layout of the book is the same as the first edition, with the reference sections divided into HTML, DOM (Document Object Model), CSS (Cascading Style Sheet) and JavaScript. A new section for Events also makes an appearance. The reference sections on HTML and DOM have sub-sections that precede them on the shared attributes of all elements. These are particularly useful and I think should be committed to memory.
There is also a very curious Cross Reference section that has an HTML/XHTML attribute index and a DOM property, method and event handler index. It takes each HTML/XHTML attribute and shows which elements support it and then each DOM scriptable object property, method and event and which objects support it. I'll confess I've never had any call to use this section but I can see how it could come in handy -- and it hardly takes up much dead tree.
The upper limit of standards coverage is HTML 4.01, XHTML 1.1, CSS Level 2, DOM Level 2, and JavaScript (or ECMAScript) 1.5. The browsers considered are IE6 (Windows), IE 5.1 (Mac), Netscape Navigator 6 and 7 and Mozilla 1.0. Opera is also mentioned in the section on Applying DHTML in that it mostly follows the IE DOM. The timeline for any element can go back as far as HTML 3.2, Navigator 2 or IE 3.
As you would expect, there are some useful appendices: Color Names and RGB Values, which I expect to be using more now as sites are required to meet Accessibility guidelines; HTML Character Entities, for when you don't have a copy of Macromedia Dreamweaver or when your favourite HTML editor doesn't have a complete list; Keyboard Event Character Values, for your scripts when you want to catch all those key presses; Internet Explorer Commands, which along with the MSHTML.dll can allow the creation of a very neat content editor quite quickly and easily; and finally, an HTML/XHTML DTD Support cross-reference that may help catch validation errors as you move from an HTML 4.01 Transitional DTD to a full-on XHTML 1.0 Strict DTD.
What makes it worth having?
The quality of Danny Goodman's writing is both technically accurate and easy to read. The clarity and lack of fluff is good, but there is no skimping on detail where such is needed to illuminate a point. Let's face it: web development is not as complex as most software engineering or systems development tasks, but it is a discipline with quite a wide base, reflected in the 1400 pages of this tome. I wouldn't trim any of it, however, and I expect that after about a year of use I will have referred to a good proportion of the contents. Take, for instance, Goodman's estimate that there are more than 15,000 unique instances of properties, methods, and event handlers supported by numerous document objects and you get an good impression of the size of the documentation required.
The book could be regarded as two books in one: There is the Applying DHTML book and the Reference book. The best things about the reference sections are the excellent descriptions, the clear little examples, and especially the quick summary of where you can expect these things to be supported. Referring to this book is the simplest way to avoid going down the proprietary browser extension cul de sac.
The Applying DHTML section is worth reading all the way through. It is great for getting yourself into the various technologies and seeing how they are meant to work. There are interesting points made on how each of the technologies are evolving. There's material contrasting the various DOM implementations and there are chapters on style sheets, positioning in CSS, making the content dynamic (of course, this is what DHTML is all about, after all) and scripting events.
There is a very useful cross-platform API for DHTML (which can be downloaded as a zip file along with the other examples from the book on O'Reilly's web site). I've used the version from the first edition quite a lot, and I've used the new version in my most recent work. It doesn't rely on browser version sniffing, but rather on object detection, which is explained with some examples, and can be easily extended to handle any DOM call you may wish to make. The API is especially useful for any CSS positioning tasks you may have. Goodman also goes over other strategies you can adopt to make your sites cross-platform, such as page branching, designing for a common denominator, and some other, neater, solutions.
There isn't anything on Accessibility other than a single paragraph drawing your attention to the Web Accessibility Initiative (WAI). DHTML and Accessibility could be considered inimical but that isn't the case and I'd perhaps have liked to see this elaborated on with some suggestions on how to achieve an Accessible site while still using DHTML. In practice, however, I've found it easy to meet the Priority 1 checkpoints (or A rating) set by the WAI even with a complete DHTML site so perhaps this is not really an issue.
I find this book really useful. I can't imagine any web developer doing without this book and managing to produce a good cross-platform solution, and I also can't imagine that developer needing any other texts on any of the technologies covered here. I certainly don't have any others on my desk today.
The O'Reilly web site has a complete Table of Contents available. You can purchase Dynamic HTML The Definitive Reference from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
books are too much money, but.. (Score:3, Interesting)
Re:books are too much money, but.. (Score:2, Informative)
If you're going to spend the money... (Score:2, Insightful)
Beginner Book (Score:5, Informative)
-Pete
Re:Beginner Book (Score:2, Informative)
I also used this book as a quick reference. But I'm afraid I didn't like it at all. The sample code didn't work most of the time. I found myself writing code just to test a feature that was suposed to work.
Other help (Score:2, Informative)
tag- Why don't most girls like programming?
Re:Beginner Book (Score:2, Informative)
-DG
First Edition was great... (Score:3, Informative)
Re:First Edition was great... (Score:2)
I dunno about that. A fair few of the corner case ORA books are pretty mediocre. Some of them are great -its these that create the reputation that other volumes just use, rather than expand.
To be fair, the great:good:mediocre ratio for oreilly is better than most other publishers.
I don't mean this as a troll, but... (Score:3, Insightful)
duh (Score:2, Insightful)
Re:duh (Score:2)
In DHTML there are seven different ways of doing everything. Five will work in IE. One will crash IE. Three will work in Nutscrape. Three will crash Nutscrape. There is an overlap of one.
Finding that one is harder than a very hard thing that's been starched to make it harder.
Re:I don't mean this as a troll, but... (Score:2, Insightful)
Re:I don't mean this as a troll, but... (Score:4, Insightful)
One of the problems with the way most people used to learn HTML is that they picked apart other people's examples, trying to figure out how things worked, with no formal guide. The end result was most people knew a <p> tag worked fine on its own but had no understanding of what it was really doing, why you may want to use a </p> tag or any of the other issues.
This book [1st ed. not 2nd - I'll admit, I've not seen the 2nd yet] works by giving a very clear introduction to the concepts and then simply laying out exactly the information you need, with a quick explanation and a short example.
Can that replace all of the experience you'd gain through working? Of course not. But it really does save the time spent acquiring a vast amount of it: All of those additional parameters that you'd need to chance upon seeing somewhere else are laid out, giving you the inspiration; the complete specifications are laid out (so things like regexps that I'd never seen in JavaScript were covered; "pure" examples are given so you're not hacking apart an example hacked apart from someone else's hacked apart example; the clear layout and concise explanations mean you understand how everything fits together that much more easily, giving you a head start on the whole "common sense" side.
So no, no one anything can give you a complete grounding: The perfect knowledge of HCI, the perfect knowledge of photoshop, the perfect knowledge of HTML structure and tags, none of those things alone make you a well balanced expert. But, for the price (~$45) and the speed (how quickly you can find exactly the information you're after in this well laid out book), it's a better (more efficient) investment than anything else I've come across.
It really is that good.
Re:I don't mean this as a troll, but... (Score:2)
Right?
:P
DHTML standard? (Score:2, Interesting)
Re:DHTML standard? (Score:5, Interesting)
Re:DHTML standard? (Score:2)
Well, that's certainly a pretty low denominator! But let me ask you this. If you were commissioned to design a new 8-lane, divided highway, would you set the speed limit at 30 mph, to ensure that those who choose to drive around in Model T's can keep up with traffic?
Re:DHTML standard? (Score:3, Insightful)
This isn't a very good analogy. When you go to a non-dhtml web page, are you dissapointed, or othwise negatively affected specifically because they aren't using DHTML? Your analogy states that everyone would be negatively affected by someone's choice not to use the latest and greatest.
I will counter your analogy with another bad/wrong analogy:
If you were commissioned to design a new 8-lane, divided highway, would you make all the road signs fly from one side of the road to the other? Would you have "Hit the Monkey and Win $20" interactive highway advertisements? Would you make drivers have to drive over a certain spot to see certain signs?
It all depends. Most of the things in my bad analogy wouldn't be good ideas. It just depends on the audience, and what you are trying to convey. Not using the latest and greatest isn't a 100% sure sign that a site will be a bad experience. That depends on the skill and intent of the designers/programmers, not on the technology they use.
Re:DHTML standard? (Score:2)
Of course not, but I would have stoplights here and there that occassionally need to change, and possibly some railway crossings that need to flash, with gates that rise and fall, and ...
Believe it or not, but dynamic content on the web is USEFUL when not abused.
Re:DHTML standard? (Score:2)
Well, yeah, I'd really like the filtering and sorting and thread grouping and so forth to be client-side on slashdot. Never gonna happen, because it ain't DHTML. Screwdriver? Damn newfangled inventions, why can't people be happy with this here hammer. Works for me every time, good old hammer.
Re:DHTML standard? (Score:4, Insightful)
Arrrgh I'm sick of people arguing with metaphors! Feels like I'm watching an old episode of Star Trek!
There are reasons to not rely 100% on the imagery of your site. For example: I went on a business trip, the modem connection was awful. I turned off images in Opera so that I could browse the web in a reasonable amount of time. The reason why that works is because most of the sites I went to had documented what each of the images are.
It's a matter of accessibility, not speed. If you support blind people, for example, then your website doesn't suddely slow down to 30mph as your poorly chosen metaphor suggests.
Re:DHTML standard? (Score:2, Interesting)
DHTML standards set by W3C and ECMA (Score:5, Informative)
figure out if any DHTML techniques have become standards.
DHTML means manipulation of the HTML DOM [w3.org] through ECMAScript [www.ecma.ch]. The HTML DOM is a W3C Recommendation, and ECMAScript is a European international standard.
Re:DHTML standards set by W3C and ECMA (Score:2)
Re:DHTML standard? (Score:4, Informative)
Besides the major two browsers, Opera does in fact implement a great deal of DOM Level 1. I'm not up to date on Konqueror but last I checked it supported a good chunk of DOM Level 1. DHTML on Macs is relegated mostly to IE for Mac, but beware, it acts differently from IE for Win. You need to test them as two separate browsers. I haven't checked iCab lately, but last year it was beyond hope. There's also Chimera, a Gecko port, which should act the same as other Gecko engine browsers. Some people are still using Netscape 4 and you're stuck with a layers DOM there, totally different from any other DOM.
So it really depends on what browsers you are targetting and what kind of things you want to do. DOM Level 1 is about as close a standard as you can get, but you're still going to have some browser-specific code.
Re:DHTML standard? (Score:2)
All the current major browsers support DHTML, which is nothing more than manipulating the DOM through scripting. This includes MSIE, Opera, Mozilla-based browsers, and possibly others. The DOM is a W3C standard, thus any browsers which complies to that standard should be DHML-compatible.
Nice troll.
First Edition is Great (Score:2)
The war is over? (Score:5, Funny)
To borrow a quote from my friend, "John 'Bluto' Blutarski" who spent most of his college career on double secret probation.
Was it over when the Nazi's bombed Pearl Harbor?
Well it ain't over now!!!!!!
The browser wars won't be over until Mozilla stomps IE.
Other than that, the book sounds excellent!
Re:The war is over? (Score:2, Funny)
JM
Re:The war is over? (Score:3, Informative)
Perhaps you should watch Animal House.
Re:Moron Advice (Score:2, Funny)
Over? (Score:3, Flamebait)
Oh, that's right, you only have to design for IE now. Silly me, I forgot that all [mozilla.org] the [opera.com] other [broswer.org] browsers [sourceforge.net] are [w3.org] dead. [handspring.com] That, or maybe, they all render DHTML exactly the same now? (HAHAHA)
(Well, maybe Lynx is dead, it's web page seems to be down...)
Re:Over? (Score:2, Interesting)
While you're at it, you better make sure it works with Mozilla 1.0 and 1.1. You better also make sure it still works with Netscape 6 (6.x) and 7. Then how about Opera 5 and 6. Then there is also Konqueror.
So I say make sure it works under IE 5+ and then do a quick check with the Mozilla 1.0. Then later make sure it works completely with Mozilla 1.0 and Netscape 6. Then start branching out.
I use Linux and Konqueror every day. I also sometimes use Mozilla or Opera because some sites render differently or the browsers crash or hang on various web pages -- probably nsplugins shitty under *nix. But when I have to develop some web page or web application, I make sure it works with IE and do a run through with Mozilla 1.0. If I have time I start branching out.
Re:Over? (Score:3, Interesting)
The browser war is certainly not as bad as it once was. Increasing standards support makes it possible to design a site that uses only the subsets of CSS/HTML/whatever that all the major browsers use. You don't need to use the non-standard IE and Netscape extensions that were introduced during the browser war proper.
Corrollary: If you design a site that works only using well-documented standards, such as the W3 ones, and it works on a selection of browsers, then anything it doesn't work quite right on only needs to improve its standards support.
Re:Over? (Score:2, Informative)
Looking at the most recent quarter, however, things are a bit more dire, with various flavors of IE accounting for 80% of the visits. Various flavors of Netscape account for only 9.8%, with Googlebot, Ask Jeeves, etc, taking up the rest.
The war may not be over, but I wouldn't get too cocky about who's winning just yet.
Re:Over? (Score:2)
(its all in the "heh" folks)
Re:Over? (Score:2)
Doh.
And second, the sourceforge link in my original post is for Links :)
10 Rating? (Score:2, Interesting)
I liked the 1st edition too, so I'm not suprised that the 2nd got such a rave rating, but 10? I would have liked to see more information on why it's better than the first edition. Not mentioning much in the way of accessibility is a big minus for me working on corporate sites since Section 508 compliance required.
Amazon [amazon.com] has it cheaper ($41.97) then B&N by the way.
Section 508 Link (Score:2, Informative)
Re:10 Rating? (Score:4, Informative)
-Gabe
Can one person be expert on all of these topics? (Score:5, Interesting)
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.)
Re:Can one person be expert on all of these topics (Score:2, Insightful)
You get plenty of bang for your buck with HTML or XHTML with CSS. If you need business rules, stick 'em on the server.
And don't waste time learning JavaScript! Your time is better spent learning PHP, Java, Python, you name it. You can't use JavaScript anywhere else.
-Ed
Re:Can one person be expert on all of these topics (Score:4, Interesting)
UI? We don't need no stinkin' UI! (Score:3, Interesting)
click (wait)... click (wait)... click(wait)...
One example of thousands of times where client-side scripting is useful. Is server-side scripting more useful? Certainly. Should server-side scripting be learned first? Probably. But any web developer that isn't familiar with client-side scripting is a mediocre web developer.
Re:Can one person be expert on all of these topics (Score:2)
I think it is/was also used for server-side stuff in netscape's webserver
Re:Can one person be expert on all of these topics (Score:2)
I realize you're mainly being facetious, but my knee is jerking...
Although it's "tuned for" server-side web applications, PHP has quite a lot of useful capabilities built into it. Think of it as "PERL lite", with an easier-to-follow syntax.
I find myself using the command-line version of the interpreter frequently. It doesn't have nearly as "broad" of a range of capabilities as, say, PERL does, but it's hard to beat for the sorts of things that it's tuned for - internet communications, text-handling, simple on-the-fly graphics, and talking to database servers, for example, whether you use it within a web page or at the command line as a cron job...
Ah, there, got my knee to stop...
At any rate, I agree completely with the point of your post - just because some people abuse javascript for fluff and nonsense doesn't discount the real usefulness it has. As an earlier poster pointed out, a combination of client-side javascript and server-side PHP can generate some really kick-butt web-based applications...
Re:Can one person be expert on all of these topics (Score:2)
You couldn't be more wrong. I'm a consultant, and when I need to write a server-side ASP script, I do it in JavaScript. IIS supports server-side JavaScript* out of the box.
* Note: for purposes of the above message, JavaScript = JScript = ECMAScript
Danny Goodman as a web guru (Score:3, Informative)
Other authors may do more for back end programming in your specific back end platforms and tools of choice, but you won't do much better than these two for front end browser programming.
DHTML in Mozilla? (Score:3, Interesting)
Is this an issue of actual support, or just "IE standards" where people don't want to use real standards, just whatever "standard" Microsoft supports?
* The site I'm thinking of is Citibank's credit card management section. here [citibank.com]. Of course, if you don't have a card with them, you can't log in to check it out.
Re:DHTML in Mozilla? (Score:5, Insightful)
IE supports both the "right" way and an M$ only way of doing things.
So it's quite easy to write one set of code that ie5+ and Mozilla use to dothe same thing. However, thanks to certain organizations promoting the other way of doing things, some web devs write code that only works in IE.... which then perpetuates taht "all other browsers but IE suck" because "wow, look how good it works in IE but it breaks in _____."
Re:DHTML in Mozilla? (Score:2, Informative)
I develop DHTML applications for a living (never read a book by Goodman either lol) and I find Mozilla to actually be superior to IE when it comes to DHTML.
The problem is that many people use the DOM that Internet explorer has or mixes up old Netscape 4 DOM in Netscape 6/Mozilla instead of the standard set by the W3C. Try putting a honda key in a ford see if that works.
Truth is if you stick to w3c standards Internet Explorer gives you headaches.
Re:DHTML in Mozilla? (Score:2)
WRONG.
> Some fucking W3C solution Mozilla is.
Indeed it is.
Re:DHTML in Mozilla? (Score:5, Insightful)
Not as long as you follow the current standards (DOM). If you do that, both IE and Mozilla has rather good "DHTML" support. It's funny that there's a way to write decent cross-browser pages that's dynamic and all that and that this way is even standardized, while many web developers *still* refuse to realize facts and continues to struggle with Microsoft's document.all model, having to disable parts of pages to make them cross-browser, etc. Is it lack of education? Brainwashing?
The site I'm thinking of is Citibank's credit card management section
Yeah, and just by looking at the source code at their login screen I see tons of non-standard DHTML code so it's no surprise it isn't working well at other browsers than IE.
I'm talking about this:See that frm.USERNAME rubbish?
If they had just changed that fragment to this:.. and it might have worked a lot better on Mozilla (while still maintaining 100% compatibility with IE! *gasp*). Look above at the incredible effort spent too.
Re:DHTML in Mozilla? (Score:2)
Plus, your example is simply wrong. getElementByID scans the "id" attribute, not the name attribute, the latter being a necessary part of a form element. There's often multiple forms on a page that have elements with the same name (search forms with multiple search methods, for example). Basically, you need XPath to return a useful node with minimal syntax for scanning, and while I love the hell out of xpath, it isn't well supported because it's brand spanking new in DOM.
So you want people to use more syntax with less functionality to do the exact same thing. Huh.
Re:DHTML in Mozilla? (Score:2)
Whether or not it makes sense to you, it's the W3C standard, so I'd say you should hold your nose and follow it.
How about doing it declaratively? (Score:2)
<model>
<instance>
<login>
<username/>
<password/>
</login>
</instance>
<bind nodeset="username" required="true()"/>
<bind nodeset="password" require="true()"/>
</model>
<input ref="username">
<label>Username</label>
</input >
<secret ref="password">
<label>Password</label>
</secret>
See http://www.w3.org/MarkUp/forms [w3.org] -- and there's already an IE plugin that does it.
Re:DHTML in Mozilla? (Score:2)
> to a collection and an element. It provides
> direct access to the contained input elements
> as well as the attributes of the form element
That just sounds like form.containedElement is ok. What I was going for is that "form" where "form" is the ID of a tag isn't part of the DOM standard. That's where getElementById comes into play.
> Finding a better example of vendor-specific
> DOM code should be easy.
Yes, I admit I didn't try hard since the general look of the code wasn't pleasant. Go ahead and give us a better example if you wish instead of:
> Nothing worse than a web nazi when he's up his
> own ass.
Re:DHTML in Mozilla? (Score:2)
Aah, oops, missed that.
My DHTML book, FREE (full text in post): (Score:5, Funny)
Don't use DHTML. It's pain in the ass. If you want "cool" stuff that makes Web sites non-accessable, use Flash. You only have to write one set of code then.
Re: Troll??? Huh??? (Score:2)
Funny, sure, Informative, really... why muck around with the various browser compatability issues when even Netscape 4 supports the same Flash plugin that Opera/IE/Mozilla/You Name It supports??
Maybe Danny himself modded me down to boost sales =)
Re:why Yet Another Syntax? (Score:2)
CSS was designed to be simple and easy for a human to read and write.
The entire point of CSS was to remove presentational attributed from HTML; moving them to somewhere else in it would be counter-productive. The HTML specification would be bloated significantly, not to mention how messy it would almost certainly be.
CSS is also designed to style arbitary XML documents, not just HTML, so it would have to be generalised; so HTML becomes XML, and before you know it, you've got XSL:FO.
They did:Not much better than <font>, though.
Re:why Yet Another Syntax? (Score:2)
I don't recall any such claims. It's certainly not true for markup-heavy tasks such as the specification of a stylesheet, as XSL plainly shows.
Well, if you want an analogy to help you understand, it's like saying "Instead of making our range of cars, trucks, busses, lorries, tanks and bikes amphibious in whatever way we can hack into them, let's just build a boat they will all fit into, along with anything else we or others might make in future along the same lines".
If you think it's syntax is what makes CSS "complex", you can't have used it much
Re:why Yet Another Syntax? (Score:2)
HTML is one example of an SGML (and now XML) document type which you might want to style. A stylesheet language must be generalised, ergo you can *not* just base it on HTML and let all the other document types do their own thing. Better to make one centralised standard which encompasses them all.
The fact that XML didn't exist when CSS level 1 was recommended kinda made it unsuitable, yes
HTML is not a standalone language; HTML is an SGML doctype. The only sane way to do what you suggest at the time would be therefore to make a new SGML doctype for CSS.
I imagine this was concidered, but given how complex SGML is and how simple CSS is, it's quite easy to see why it wasn't actually done, especially concidering the quality of the browsers at the time. I'll bet the thought of retargeting speghettified tag-soup parsers to a stylesheet language which really didn't need anything close to a DOM wasn't terribly attractive.
Anyway, it was a good decision, XML or no, XML rapidly turns into a mess of tags which would make the
Complexity (Score:5, Insightful)
You obviously never had to cope with developing a complex web application. When done right, it's a task far more complex than "conventional" software engineering.
Rich client-side interface doesn't mean a mouse-cursor tracker or validating your form on the client-side. It means letting the client side do ALL your application logic and interface, seperately. And let the server do the dumb job of validating, saving and returning raw data that can be handled by client-side custom components or logic-flow.
Not as complex? No, even more complex, if you're doing anything worthy.
Re:Complexity (Score:2)
Re:Complexity (Score:2)
Re:Complexity (Score:2)
DHTML vs Server Side scripting (Score:3, Interesting)
Is DHTML still as relevant as it used to be? Aren't people using server side scripting (perl, php, asp, etc) for truly interactive sites and things like DHTML are little more than nice HTML enhancements for doing the odd neat thing?
I just wondered what the perception was? I'm not anti-DHTML by any means, I'm just interested in where the general trend of web development is going.
Re:DHTML vs Server Side scripting (Score:5, Informative)
DHTML was relevant when it appeared with the advent of 4.0 browsers and it is even more today because there is more coherance
A truly interactive site will require server side processing of information if it wants to be of any value. DHTML allows you to present information in a way someone can interact with it (sorting a table of data on the client side, form validation, having mutliple layers of information on a page).
DHTML becomes essential in web applications like a billing software that doesn't require software to be installed on the client side.
Something going against the usage of DHTML is the browser war and support for standards still not being as respected as Mozilla. Netscape 4 is the worst thing that happened to DHTML. It made lots of things impossible to do or hard to do. Anyone still using NS4 should upgrade to allow developers to create real web sites. Another thing going against DHTML is the fact that lots of people begin programming with it and too many beginners try useless flashy things that hurt the people that can actually do nice things in DHTML.
The last web application I did for www.b-process.com processes bills eletronically and uses a web interface compatible with IE4 and up and Mozilla/NS6+. Lots of features like attaching a note to a bill are achieved through the usage of DHTML. Another interesting thing was that we save download time by sending only bill data instead and let the DHTML layer format the information on the client side saving up to 80% of bandwith.
DHTML is relevant today and will be more once NS4 is dropped completely. I'm glad I could answer your question! :)
Re:DHTML vs Server Side scripting (Score:2)
You'll need to live with NS4 users for another few years most likely. In the meantime, might I suggest KISS?
(This message posted with lynx, by the way.)
Re:DHTML vs Server Side scripting (Score:4, Informative)
As an example, I've recently created a page that allows the creation of price structures. Price structures have a start date, an end date (which may be null), 0 or more surcharges (name and $)and 1 or more price breaks (min qty, max qty, unit cost). Also, each price break may have 0 or more surcharges (name and $)
Building this with static HTML and server side scripting could require many trips back and forth to the server... this isn't very good from a users perspective.
Instead, I used dynamic HTML to do it all in one page... the form is created on the fly, and modal dialogs are used when entering data to keep the interface clean. Clicking a button to add a price break opens a modal, fetches the details back from the modal, creates another table row, fills it with text showing what you've added, hidden input fields holding the data, an "add surcharge" button, and a "remove" button that deletes the table row (along with the hidden inputs it contains)
You can easily add, edit and remove as many items from this form as you wish, and once you've tweaked the price structure the way you want it, the server breaks it all down and salts it away in the database.
The whole thing is very usable, reusable, and efficient, and could not have been made without DHTML and JavaScript.
Klez me once, shame on you. Klez me twice.... (Score:2, Insightful)
I use IE6 to cruise the web. Given the all the security holes and patches, I'll be damned if I say yes to "Scripts are usually hamless. Ok to run?"
Even a site like the NYtimes runs under lockdown on my machine. Though I trust the web designers at the Times not to be malicious, I don't think they can secure their site against an attack that sneaks a malicious script onto their site. Same thing is true of internal web pages.
Re:Klez me once, shame on you. Klez me twice.... (Score:4, Funny)
adam
Re:Klez me once, shame on you. Klez me twice.... (Score:3, Interesting)
Wow, well it's good to see that you're very progressive and open-minded. Why don't you try broadening your scope a bit? Sure, no one needs Java, Javascript, Flash, CSS, or DHTML to punch up a few news stories or your resume. But what about sites that let you dynamically monitor distributed processes? Or how about a little thing you've obviously never heard of called "e-commerce?" There are plenty of real, useful ways in which scripting makes things a lot easier, both for the visitor and the author.
It says a lot that you couldn't see that. Period.
Re:Klez me once, shame on you. Klez me twice.... (Score:3, Interesting)
Well I used to run with all the bells and whistles enabled. Unfortunately, I stumbled across a website whose author was more interested in causing havoc on my machine than in providing content.
It's true that well-intentioned scripting features can make things easier. It's also true that, in the wrong hands, those features can cause havoc. To me, it's not worth it.
As to your last comment, E-commerce doesn't require DHTML, Flash, CSS, java or javascript. In fact, if you ever read the W3 specs, they make a point of saying that web sites shouldn't require any of those technologies to function properly. If you want animated pictures of butterfly-costumed men obscuring your screen, be my guest. Just don't insist that I watch them too.
Re:Klez me once, shame on you. Klez me twice.... (Score:2)
What do application-specific used-by-ten-people websites have to do with the WWW? The WWW is intended to be public and accessible, just like the public library or a local department store. Would you go to a store that denied you access because of the brand of shoes you happend to be wearing (even though shoes are a standard interface used in moving about the store)? What if you need to use an elevator but the only way to the second floor is a spinning neon escalator?
Or how about a little thing you've obviously never heard of called "e-commerce?"
The absolute best e-commerce sites are very light on DHTML. They follow a "Just the facts, Mam" philosophy of well-organized data entry (forms) and an intuitive work flow from beginning to end. They don't need DHTML for efficiently browsing catalogs, nor do they need DHTML for data entry, nor do they need DHTML for actually performing the transaction.
Re:Klez me once, shame on you. Klez me twice.... (Score:2)
Large menus. By implementing them as a dynamic, client-side tree control, very large document structures can be displayed in a very compressed space, reducing client-server communications, and allowing the user to navigate directly to the topic they're interested in, in a much large pool than would otherwise be possible (practical) without scripting.
Re:Klez me once, shame on you. Klez me twice.... (Score:2, Insightful)
Maybe you should try using a browser that doesn't have so many security problems. I suppose if the lock on your door was easy to pick then you would get rid of your possessions rather then getting a better lock.
The scripts are not the problem. IE is the problem.
Why this book? (Score:2)
Honest question: there seems to be a lot of overlap between this book and other O'Reilly titles. Can anyone tell me why I would want this one rather than "HTML/XHTML, The Definitive Reference" and/or "Javascript, the Definitve Reference"?
If this is the second edition.... (Score:2, Informative)
Dynamic Duo (Score:4, Informative)
I'm not so up to date what's the current state of the art, but some years ago, when I was applying DHTML, I always found Dan Steinman's Tutorial Dynamic Duo [dansteinman.com] very helpful (thanks Dan!).
It has been continued as DynAPI [sourceforge.net]
Re:Dynamic Duo (Score:4, Insightful)
Then they have to suggest using something like this:Can you see the maintenance you'd need to do to make it cross-browser compatible?
The alternative is DOM where you can use common code for all browsers that support DOM. Considering that the standard has been around for years and is supported rather good by all current browsers, it's surprising that there's enormous amounts of sites around that teach the aging "version 4" coding philosophy. It's the philosophy behind those hideous IE-specific pages that might have *some* Netscape support in but break when you use a browser/browser version the coder didn't expect or didn't exist at the time the page was coded.
Against JavaScript (Score:2, Interesting)
If you want eye candy, use Flash, which does a much better job of it.
Comparison to Flanagan's JavaScript book. (Score:2)
Anyone own both? How do they compare to one another?
shouldn't be called dhtml refference (Score:2)
The reason I like the book so much is because it's not soley limited to DHTML. The first couple hundred pages talk about DHTML and it's uses in browsers, etc. All very great writing, but stuff I already know.
The great part about the book is the other 1000+ pages of syntax references for everything, HTML, JS, CSS, DOM, everything. Basically it's a book that tells you everything you can possibly do in a browser, not just DHTML.
I've used it for looking up CSS properties, or HTML attributes, or Javascript functions. I don't know how many times I've thought of and idea of something to do in a browser, looked in the book, and found some method to do it. Sure beats trying to find info on the W3C site.
Best book I've ever owned, bar none.
Hands down, the best web-book I've owned (Score:2)
It's a great combination of HTML/Javascript/DHTML/CSS etc.
Well worth the money.
forgot my point... (Score:2, Funny)
Re:forgot my point... (Score:2)
I diagree. IMHO this is not an advanced book; I hardly what a was before I picked up the first edition (aka "The WebDev Bible") and with this book at my side I learned to do everything that was ever asked of me--including some very complex pages--and around my (still running) dot-com, they soon gave me the dubious honor of being called "the javascript king".
The book helps you to do very advanced things if you (feel the) need to, but I think it is an excellent introduction to HTML/DHTML as well. And for those who pick up new things fairly quickly, the reference section is where you'll spend most of your time, only looking at the well-written and easy-to-read earlier chapters when you're trying to understand some subtelties of CSS or something.
When learning any new language, I always look for a good reference rather than some 'please hold my hand' sort of book. I was very happy to have found it in (the first edition of) this book.
And as far as studying the source code of other web sites, yes, that can be helpful, but considering the poor coding skills of most people out there (particularly web developers, or am I being unfair?), it can also be a very bad idea. Learning by example is really only a good idea when you [know you have] have good examples.
Even with a well-thumbed copy of this book on your desk you will still find yourself looking at the source for many web pages, but only for a quick glance to figure out how something someone else wrote works (or why it doesn't).
I saw the 2nd Edition in the store the other day, and was tempted to get it but I still haven't really found the 1st Edition lacking. If I bought I'm sure I'd agree with the author of this review, however.
If you are a web developer, this should be your bible.
P.S.: Please pay attention to the bits about cross-browser compatibility.
Thanks!
Re:Little market for this book.... (Score:4, Informative)
Re:Little market for this book.... (Score:4, Insightful)
I would say the vast majority of sites I have personally ever worked on have been internal projects. Using web standards to create a front end for an application is a very appealing idea. After all, if one decides to turn the application into a distributed app, there is a lot less work.
This is where I see the advanced topics of DHTML and JavaScript being used, not in the latest homepage of some stranger. Probably not even in the latest shopping site, which was probably designed years ago for ultimate compatibility.
As an aside, with Mozilla (the engine) gaining in popularity as an application framework, I can only see these topics gaining even more relevance.
Intranets, not internet (Score:4, Informative)
Cheers,
Ian
Re:Little market for this book.... (Score:3, Funny)
First off, the article misleads you into believing that there are only four or five web browsers. The truth is, there is only one--Internet Explorer.
Really? Let's find out. Everyone out there who is not using Internet Explorer, raise your mouse hand.
[Earth's orbit changes infinitesimally]
Thank you
Don't be an idiot (Score:5, Insightful)
Re:Don't be an idiot (Score:2)
What if one of the users is blind or can't use a mouse, but, otherwise, is a perfectly competent and valuable employee? Would you suggest this person be dismissed as human scrap just because you like to make everything "appealing and easy to use"?
Re:Don't be an idiot (Score:2)
It wouldn't. Even I will admit that there are totally legitimate uses for DHTML. Select lists are self-contained on the web page and updating it behind the scenes isn't a big deal. Form validation and text-field updates are also not a big deal. However, many intranet websites push all this all way too far.
The WWW is really going through an adolesence right now, where very very many web developer simply don't get it. I have seen full-blown GUIs generated in my browser on-the-fly with JavaScript, and these websites (intranet ones, too) were obviously developed with pretty much no regard to anyone who: 1) uses something other than IE, 2) can't move a mouse around to see all the fancy-shmancy pop-ups, dialogs, and menus drawn directly into the browser window. Given that these sites are barely accessible to me (they are annoying as hell), I can't imagine how a person disabled in some manner would deal with them. And this comes back to my original question about intranets not fully accomidating otherwise totally valuable employees. It'll be another several years before the Public really understands what the WWW is about and what it always has been about: information sharing in a platform-agnostic and accessible (both browsers and people) manner.
Re:Little market for this book.... (Score:5, Interesting)
Well-used Javascript and DHTML is harder to recognize than the obvious stuff you come across as popups and various ad-schemes. Apparently, you pull stats ("99.9999%") out of your ass and try to pass your opinions as facts. Are you in the industry, or is your main experience that as a surfer ?
There is tremendous power to DHTML and Javascript, and it is widely used in commercial sites. It allows the user to interact with the otherwise dead html in ways that help the user and the site.
For a great example, look at International Herald Tribune [iht.com]. You can select articles from the frontpage and put them in a "clippings" folder - no you don't have to login - and then you can read them all later on. No more "open in a new window". For individual articles you can select how it will presented; font size, colums per page etc. This is an example of a site that is usable and intuitive thanks to Javascript, in this case.
So, get a clue to what you are talking about.
from 4, Interesting to 0, Flamebait (Score:4, Interesting)
I agree. I guess DHTML and JavaScript have excellent tools for intranets, for instance for services like accessing Novell GropWise through the web browser. I think you're right, that there are good uses for DHTML.
I don't mind useful applications, but it seems that the internet is more annoying now it was in 1996 and DHTML is one of the reasons no doubt. It does have good purposes, but no thank you 99% of the time, when I'm accessing the internet and not intranets.
Thank you to people who enlightened us all about intranet usefulness. I posted my opinion, it went to 4, Interesting, and generated a few explanations of how DHTML is useful. Now that my perspective had a counterpoint, my moderation quickly went down to zero. I ask, are we not all enlightened from the discussion that took place? How can something that entices useful information be devalued once moderators judge that a 'better' opinion appears, all stemming from this? And flamebait, of all things...
Re:Don't click on Slashdots book link (Score:3, Informative)
Re:Don't click on Slashdots book link (Score:2)