DHTML steht wörtlich für "dynamisches HTML". DHTML bedeutet jedoch wirklich, JavaScript zu verwenden, um Stylesheets zu manipulieren, d.h. mit JavaScript Ebenen zu verstecken, anzuzeigen oder zu verschieben oder die Schriftart eines Textes zu ändern, wenn ein Benutzer mit der Maus darüber fährt. Das ist es wirklich. Hier ist eine andere Art, darüber nachzudenken: Du kannst JavaScript verwenden, um HTML zu manipulieren, oder? Denken Sie an Bildprofile und das Platzieren von Text in Formularfeldern - das heißt, Sie verwenden JavaScript, um zu ändern, was sich auf der Webseite befindet. DHMTL ist genau das: JavaScript verwenden, um zu ändern, was sich auf einer Seite befindet. Wenn Sie etwas ändern, das in einem Stylesheet festgelegt wurde, wie Ebenen oder Schriften, tun Sie plötzlich DHTML anstelle von einfachem altem JavaScript. "DHTML" ist nur ein Marketingbegriff, der für eine bestimmte Art der JavaScript-Nutzung steht. Wenn das im Moment nicht klar ist, mach dir keine Sorgen. Das wird es sein. Ich werde das nächste Kapitel damit verbringen, Stylesheets zu betrachten, und der Rest des Buches wird sich mit der Verwendung von JavaScript befassen.

Was kann DHTML bewirken?

  DHTML kann alle Arten von wirklich interessanten und lustigen Dingen machen. Sie können kleine Spiele, verschiebbare Popup-Menüs, verschiebbare Bilder, interaktive Tests und dergleichen erstellen. Internet Explorer (IE), vor allem, hat alle Arten von großen Erweiterungen, die Sie ziemlich kreativ werden lassen. Es gibt kein Ende für die Dinge, die man tun kann.

Die Grenzen von DHTML

Die einzige wirkliche Einschränkung von DHTML ist die sehr unterschiedliche Behandlung von JavaScript in den verschiedenen Browsern. Das ist eine große, fette, haarige Einschränkung. Beispielsweise habe ich einmal ein scrollendes mehrzeiliges Textfeld in DHTML erstellt. Es hatte Pfeile, einen Schieberegler, alles. Es dauerte länger, bis dieses kleine Scrolling-Ding gebaut war, so dass es auf allen Browsern und Plattformen funktionierte, als es dauerte, bis der Rest der Website (einschließlich des Back-End-Datenbankzeugs) erstellt war. Es für einen Browser und eine Plattform zu entwickeln, war nicht allzu schwierig, aber als ich anfing, mir die anderen Browser und Plattformen anzusehen, nahm die Entwicklungszeit enorm zu. Unnötig zu sagen, dass ich es gerne bei der nächsten Überarbeitung der Website ausgegeben habe - es hat einfach zu lange gedauert. Ich erwähne diese Geschichte als eine mögliche Warnung: Wenn Sie mit DHTML wirklich Lust auf etwas haben, werden Sie dafür bezahlen. Die Entwicklungszeit, damit Ihr Code auf den verschiedenen Browsern und Plattformen funktioniert, wird viel länger dauern, als es sollte. Wenn Sie denken, dass Sie fertig sind, schauen Sie sich Ihre Seite auf einem Macintosh mit IE 4.5 an. Alles in diesem Buch ist vollständig browser- und plattformübergreifend. Tatsächlich ignoriere ich alles, was Netscape- oder IE-spezifisch ist. Zum Zeitpunkt dieses Schreibens hat Netscape den Browser-Krieg noch nicht ganz verloren, so dass Netscape-Nutzer noch berücksichtigt werden müssen. Außerdem ist Netscape 6 weniger beliebt als erwartet, so dass Netscape 4.x-Benutzer weiterhin berücksichtigt und kodiert werden müssen.

Wann Sie DHTML verwenden sollten

Um ehrlich zu sein, benutze ich DHTML nur, um Ebenen erscheinen und verschwinden zu lassen und für einfache Animationen. Allerdings hat nicht jeder Fußgänger solche Ambitionen für sein DHTML, so dass Sie in diesem Buch Beispiele finden werden, die über diese wenigen Anwendungen hinausgehen. Tatsächlich erwarte ich, dass bald viel mehr DHTML im Web zu sehen ist, da fast jeder Netscape 4.7+ und IE 5.x hat. Alle Browsermetriken, die ich gesehen habe, deuten darauf hin, dass mindestens 95% der Websurfer einen Browser 4.0+ haben. Wenn Sie anfangen, Ihr eigenes DHTML zu kodieren, beginnen Sie klein und einfach. Es ist einfach, einem Kunden große Versprechungen zu machen, und als brillanter Programmierer bin ich sicher, dass Sie diese einhalten werden, aber Sie sparen sich viel Kummer und späte Nächte, wenn Sie Ihre Seiten in inkrementellen Phasen erstellen.

Der Trend geht weiter, wo ich mit Kunden, Verkäufern, jungen Entwicklern, die gerade erst ihr Studium beendet haben, und sogar mit den Lehrern/Professoren spreche, die sie unterrichten, und sie verstehen nicht, dass HTML5 und CSS3 nicht die gleiche Spezifikation sind. Ich habe wiederholt eine HTML 4.01-Seite mit CSS3 gezeigt, um zu erklären, dass es sich jeweils um unterschiedliche Spezifikationen handelt, die in verschiedenen Kombinationen von verschiedenen Versionen angewendet werden können. Dies ist noch komplizierter, wenn JavaScript in den Mix gefaltet wird - einige Leute denken sogar, dass jQuery Teil der HTML5-Spezifikation ist. Es ist wahr: In jeder Hinsicht ist "HTML5" zu einem bedeutungslosen Marketingbegriff geworden, der eher eine Plattform als eine Spezifikation definiert. Es ist "DHTML" von neuem.1 Das alles begann wahrscheinlich damit, dass "HTML5" als Spezifikation immer mehr als eine Auszeichnungssprache war. Schon von Anfang an bei der WHATWG (bevor sie sich entschieden haben, versionslos zu werden und es einfach "HTML" zu nennen) war "HTML5" eine Markup-Sprache, eine aktualisierte DOM-Schnittstelle und eine Reihe neuer APIs für die Interaktion mit Browsern und Geräten. Einige von uns hatten Probleme damit, das Ganze als "HTML5" zu klassifizieren, aber es ist nicht so, dass jemand Hixie sagen kann, was er tun soll. Also ja, von Anfang an war "HTML5" ein bisschen falsch, aber der letzte Schlag gegen den Nutzen von HTML5 als Begriff - zumindest für mich - kam in Form von Apples "HTML5 Showcase". Es erregte eine Menge Aufmerksamkeit in der Presse und brachte wirklich den Begriff "HTML5" heraus.... merkwürdigerweise, während es hauptsächlich CSS3-Features demonstrierte und wenig bis gar keinen Versuch unternahm, die eingesetzten Technologien zu disambiguieren. Ok, also, was ist das Problem mit all dem hier? Einige argumentieren, dass es kein Problem gibt, dass die Begeisterung der Öffentlichkeit für "HTML5" nur positive Veränderungen im Web bewirken kann. Ich bin damit nicht einverstanden, aber ich glaube auch fest daran, dass Semantik wichtig ist. Chris Mills hat meine Gefühle im letzten Jahr um diese Zeit auf dem WaSP-Blog ziemlich gut zusammengefasst: Das ist wirklich nicht gut - ich schätze, dass es gut ist, einen Oberbegriff für eine Gruppe verwandter Technologien und Techniken zu haben, über die man sonst nur schwer im Gespräch sprechen kann. "Ajax" und "Web 2.0" erfüllen diesen Zweck gut. Und es ist in Ordnung, über eng verwandte Spezifikationen wie Geolokalisierung und Web Sockets zu sprechen, als wären sie unter dem HTML5-Dach, solange man sie irgendwo klärt (ein gutes Beispiel finden Sie in Get familiar with HTML5!). Aber das ist anders - HTML5 und CSS3 zum Beispiel sind zwei deutlich unterschiedliche Technologien und sollten nicht miteinander verwechselt werden. Dies wird das Lernen behindern und Probleme mit der Entwicklung, Dokumentation und vielen anderen Dingen verursachen. Das ist der Punkt. Wenn wir uns an Gesprächen beteiligen, müssen wir auch wissen, welches "HTML5" diskutiert wird. Persönlich, wenn ich über HTML5 spreche, mache ich immer einen Unterschied zwischen "HTML5" dem Marketingbegriff und "HTML5" der Spezifikation, auch wenn ich mehrdeutige Fragen zu HTML5 habe. Ich sage nicht, dass jeder die genauen Unterschiede zwischen den beiden Verwendungen des Begriffs kennen muss, aber es ist unsere Pflicht, sie darüber aufzuklären, dass es einen Unterschied gibt, auch wenn sie die Einzelheiten nicht ergründen können. DHTML, wie Sie sich vielleicht erinnern, war ein Schlagwort, das die gemeinsame Verwendung von HTML, CSS und JavaScript bedeutete, aber einige Leute dachten, es sei eine eigenständige Technologie. Danke an die Marketingabteilung!