Richtiger Einstieg in (X)HTML-Entwicklung

In den nächsten Tagen möchte ich einen guten Bekannten in die (X)HTML-Entwicklung einführen. Wichtig dabei ist mir der richtige Einstieg in Zugänglichkeit, Benutzerfreundlichkeit, sowie Barrierefreiheit. Ich plane, dass wir zuerst eine Website nur mit (X)HTML entwickeln. Dadurch verspreche ich mir, ihm ein Auge und Gefühl für Semantik zu verleihen.

Die Arbeitsumgebung

Für mich kommen schon lange keine WYSIWYG-Editoren mehr in Frage. Für mich sind gute Text-Editoren mit (X)HTML-, CSS- und PHP-Syntax-Unterstützung die richtige Wahl. Da wäre z.B. Zend Developer Environment. Mit diesen Text-Editoren lernt man wenigstens noch die tiefe Materie von (X)HTML und CSS kennen.

Der Beginn

Ich denke, ich werde nicht lange erklären müssen, was Dokumententypen sind. Auswendig könnte ich auch keinen schreiben. Sie sind einfach da und haben da zu sein. Die Wahl des Dokumententyps ist auch nicht so schwer. Ich werde ihm wahrscheinlich XHTML beibringen. Die Syntax ist logischer und somit - meiner Meinung nach - einfacher.

Kurzer Leitsatz: Jedes Element wird geschlossen, so auch img, br, hr und meta

Bevor wir aber irgendwo mittendrin einsteigen, habe ich vor, dass wir uns eine Website genau anschauen. Dabei meine ich aber nur die Ausgabe, nicht den Code. Ich erkläre oder erfrage ihn, was einige Elemente auf der Website sind und in welchen Beziehungen sie stehen. Also Absätze, Überschriften, Listen, Betonungen, Links usw. Danach bestimmen wir die groben Bereiche der Website. Diese werden später wahrscheinlich mit div realisiert.

Nachdem wir die Bereiche und Elemente genauer definiert haben, nenne ich ihm die Tags, die dafür in Frage kommen. Für Listenpunkte z.B. li. Haben wir uns alle Bezeichnungen notiert, beginnen wir damit, die Website nachzubauen.

Zuerst konzentrieren wir uns dabei auf den Dokumentenkörper, also alles im body-Element. Die Kopfangaben kommen später. Wahrscheinlich kommen dabei folgende Fragen auf:

  • Ist die von mir verwendete Syntax richtig?
  • Sind die von mir verwendeten Elemente sematisch richtig gewählt?
  • Muss ich irgendetwas beachten, damit ich später die Website mit CSS versehen kann?
  • Gibt es Referenzen, auf die ich zurückgreifen kann, wenn ich kein wirklich passendes Element aus dem Kopf weiß?

Hier die Antworten:

Ist die von mir verwendete Syntax richtig?

Das kann mit dem W3C Validator überprüfen. Er gibt logische, meist leicht verständliche Fehlerangaben aus. Dazu kann man am besten die Webdeveloper Toolbar installieren. Sie bietet eine Schaltfläche um die aktuelle Seite zu prüfen. Außerdem bietet diese Erweiterung für Firefox noch eine ganze Menge anderer guter Tools für die Webentwicklung.

Meist kann auch Zend eine falsche Syntax erkennen. Die Anwendung markiert wahrscheinliche Syntaxfehler rot. Dadurch sieht man schon vor dem Speichern und validieren eines Dokuments eventl. Fehler.

Eine live-Überprüfung von Websites bietet auch HTML Validator/HTML Tidy. Die Firefox Erweiterung zeigt in der Statusleiste die Fehler und Warnungen an, die sie erkennt. Die Quelltextansicht von Firefox wird durch die Erweiterung um einiges erweitert. Sie zeigt Fehler in einer Übersicht an, markiert diese im Quelltext und gibt Verbesserungsvorschläge vor. Die Warnstufem lassen sich auch einstellen, von eher tolerant bis sehr streng. Die Einstellung nennt sich Hinweise zur Barrierefreiheit. Meine Einstellung ist normal und die Hinweise reichen mir völlig aus.

Sind die von mir verwendeten Elemente semantisch richtig gewählt?

Wenn du jede Verwendung der Elemente befriedigend begründen kannst, ohne auf visuelle Aspekte zurückzugreifen – ja.

Muss ich irgendetwas beachten, damit ich später die Website mit CSS versehen kann?

Es ist sinnvoll, wichtige Bereiche und wiederkehrende Einheiten erkennbar zu benennen. Damit meine ich die Identifizierungen, wie class oder id.

Wichtige Bereiche sind beispielsweise die Container, die später das Layout ergeben. Dazu gehören meist Header, Inhalt, Sidebar und Footer.

Mit wiederkehrenden Einheiten meine ich zum Beispiel Auflistungen für Weblog-Einträge. Sie sind Listen, meist ohne Listenpunkte, enthalten Überschrift, Meta-Daten und Einleitung und tauchen im Archiv, auf der Startseite und bei der Suche häufig auf.

Gibt es Referenzen, auf die ich zurückgreifen kann, wenn ich kein wirklich passendes Element aus dem Kopf weiß?

Ja, SelfHTML ist ganz gut. Dort werden Elemente übersichtlich nach Sinn eingeteilt und ausführlich erklärt. Anwendungsbeispiele und Versionshinweise sind dort auch aufgeführt.

Fortsetzung

Hab ich vielleicht etwas vergessen oder eventl. eine seltsame Reihenfolge gewählt?

Im nächsten Teil geht es um die Kopfdaten, Verlinkung und weitere Bergifflichkeiten und Weiteres, was man für den richtigen Einstieg in die (X)HTML-Entwicklung wissen muss. Außerdem wird es eine grobe Einführung in CSS geben.

veröffentlicht am 05.06.2006 um 22:00 von Martin Labuschin in ,


"Doctypes sind einfach da und haben da zu sein." - Klingt für mich so als wär es völlig bums, welchen Doctype ich denn nun verwende. Isses aber nich. Denn nur durch den Doctype entscheidet sich zum Beispiel ob du deinem guten Bekannten XHTML in der Transitional oder Strict Variante beibringen wirst (oder es versuchst).


Und wie jetzt, die kannst du nicht auswendig? Tsstsstss... die sind mein Gutenachtgebet :)

Hi,
recht gut, aber in einem Punkt Blödsinn: Ob HTML oder XHTML, das hat absolut keinen Einfluß darauf, ob man die Prinzipien des semantic markup versteht. XHTML ist logischer aufgebaut, und man kann damit besser, weil logischer, wohlgeformtes xml erstellen. Korrekte Syntax ist damit leichter zu erlernen. Korrekte Syntax und korrekte Semantik korrelieren allerdings nur sehr lose.

Ich habe folgende Erfahrung gemacht: Arbeite von Anfang an mit "alternate stylesheets". Man braucht halt Firefox oder Opera dazu, um das zu nutzen. Der Vorteil: Der Nutzer kann das Aussehen selber bestimmen. Zumindest die diversen Klassennamen können damit schon von vornherein Nichts mehr mit dem Aussehen zu tun haben, denn mit dem einen Stylesheet sieht diese Klasse nun mal anders aus als mit dem anderen Stylesheet. Nicht nur die Farben können variieren, auch die Position und die Form. Der Webdesigner ist daher von Anfang an dazu gezwungen, sich Klassennamen zu überlegen, die mit der Funktion resp. der Bedeutung der entsprechenden Container zu tun haben, anstatt das gesamte gedankliche Konzept anhand einer konkreten visuellen Darstellung aufzubauen. Diese funktionelle Sichtweise ist der erste Schritt hin zu einem semantischen Markup und öffnet die Augen auch für z.B. die korrekte weil semantisch angemessene Verwendung der jeweiligen html-Tags.
Die Koppelung von Aussehen und Markup muß einfach aufgebrochen werden. Das kann man nicht erreichen, wenn man einfach html und css trennt (auch, wenn das erstmal Voraussetzung dafür ist). Dieses Aufbrechen muß im Kopf passieren. Diese alternate stylesheets können dazu eine sehr gute Erziehungshilfe sein.

Huch, ganz vergessen. Ich werds mit XHTML 1.1 versuchen. Da gibt es aber keine Varianten mehr.

zuerst einmal solltest du deinem bekannten erklären, was html bzw. xhtml eigentlich ist. und dann solltest du ihm erklären wie es aufgebaut ist (tags, elemente, attribute, ?). dann folgt eine erläuterung über die funktionsweise von html im netz (http, server-grundlagen, ?). UND DANN kannst du die hier beschriebenen sachen erklären.


xhtml 1.1 ist übrigens die ungünstigste wahl für einen anfänger. html wäre die richtige, denn xhtml setzt wissen über xml voraus, insbesondere xhtml 1.1.

nunja, jeder kann nur das vermitteln, wass er selbst weiß. gib ihm doch ein gutes buch in die hand.

Vielen Dank für eure Verbesserungsvorschläge. Besonderen Dank an ML, denn dein Anfang ist geeigneter als meiner. Ich werde deine Vorschläge berücksichtigen. Jedoch finde ich XHTML 1.1 doch die bessere Wahl. Vorwissen über XML besaß ich damals selbst kaum und kam damit trotzdem zurecht. Aber diese Website ist in den Augen von XHTML-Freaks eh nur eine Tag-Soup, jedoch begründet.

Hi,
recht gut, aber in einem Punkt Blödsinn: Ob HTML oder XHTML, das hat absolut keinen Einfluß darauf, ob man die Prinzipien des semantic markup versteht. XHTML ist logischer aufgebaut, und man kann damit besser, weil logischer, wohlgeformtes xml erstellen. Korrekte Syntax ist damit leichter zu erlernen. Korrekte Syntax und korrekte Semantik korrelieren allerdings nur sehr lose.
Ich habe folgende Erfahrung gemacht: Arbeite von Anfang an mit "alternate stylesheets". Man braucht halt Firefox oder Opera dazu, um das zu nutzen. Der Vorteil: Der Nutzer kann das Aussehen selber bestimmen. Zumindest die diversen Klassennamen können damit schon von vornherein Nichts mehr mit dem Aussehen zu tun haben, denn mit dem einen Stylesheet sieht diese Klasse nun mal anders aus als mit dem anderen Stylesheet. Nicht nur die Farben können variieren, auch die Position und die Form. Der Webdesigner ist daher von Anfang an dazu gezwungen, sich Klassennamen zu überlegen, die mit der Funktion resp. der Bedeutung der entsprechenden Container zu tun haben, anstatt das gesamte gedankliche Konzept anhand einer konkreten visuellen Darstellung aufzubauen. Diese funktionelle Sichtweise ist der erste Schritt hin zu einem semantischen Markup und öffnet die Augen auch für z.B. die korrekte weil semantisch angemessene Verwendung der jeweiligen html-Tags.

Die Koppelung von Aussehen und Markup muß einfach aufgebrochen werden. Das kann man nicht erreichen, wenn man einfach html und css trennt (auch, wenn das erstmal Voraussetzung dafür ist). Dieses Aufbrechen muß im Kopf passieren. Diese alternate stylesheets können dazu eine sehr gute Erziehungshilfe sein.

xhtml 1.1 ist die falsche wahl. niemand steigt direkt in die bundesliga ein. xhtml 1.1 ist was für profis, und selbst die würden es nicht einsetzen, da sie wissen das es keine vorteile hat.
lesestoff: http://lachy.id.au/log/2005/12/xhtml-beginners

html ist die richtige wahl, vorallem weil es die grundlage für xhtml ist. in ein paar jahren werden die meisten seiten sowieso in html5 geschrieben werden. denn das konzept ist logischer und praktikabler als das von xhtml.


und was björn da schreibt ist keine begründung. der zweite satz sagt schon alles: "Hierfür gibt es technisch keinen Grund, vielmehr macht es eigentlich gar keinen Sinn." alle argumente die er anbringt haben nichts mit dem thema "html oder xhtml" zutun, sondern mit "guter code oder schlechter code".

Hey Leute,
Was ist an (X)HTML so schwer? Das höre ich immer wieder aber ich komme damit zurecht obwohl ich keine Ahnung von xml habe

Mit XHTML 1.1 hatte meiner blassen Ahnung nach doch gewisse Internet Explorer-Versionen zu kämpfen. Stichwort "Quirksmode"? Jedenfalls hatte ich bei Beginn meiner CSS-2 Phase (und meiner Site) gleich auf XHTML 1.0 gesetzt. Muss hier nochmal grundsätzlich geklärt werden!

blog comments powered by Disqus
The Ruby on Rails Link Library Spanning Sync SEO-Dokumentation Gowalla
ProWebApps WellDone (β) Pinboard (α) Netzwerk Münsterland
Blogs Bücher Frameworks iPhone Mac Web-Apps