Diskussion:Websiteentwicklung: XHTML

XHTML Kompendien, Bücher und andere Nachschlagewerke

Wollte nur mal erwähnen dasses schon einen Anfang zum Thema XHTML gibt. Gruss --Moolsan 13:32, 17. Jan 2005 (UTC)

Sorry, aber das Buch ist Dreck. Im Web gibt es tausende Dokumentationen zu XHTML (bspw. SelfHTML), die um Längen besser sind das das hier. Gibt es irgendeinen Grund, diesen Mist zu behalten? --Matthias

Aller Anfang ist hart. Sicher wird es eine Ewigkeit dauern, bis das "Buch" hier auch nur annähernd die Qualität der SelfHTML erreicht.--212.114.250.70 20:43, 7. Apr 2005 (UTC)

Eben. Schau dir mal die alten Version von SelfHTML an. Du kannst sie hier finden.-- Daniel B 20:03, 14. Apr 2005 (UTC)

Schön und gut, aber wozu sollte man XHTML nochmal dokumentieren, wenn es schon Dutzende sehr gute Dokumentationen dazu gibt? --Matthias

Soweit ich weiß gibt es noch keine XHTML Dokumentation unter einer freien Lizenz. -- Daniel B 20:03, 14. Apr 2005 (UTC)

SelfHTML und Konsorten haben vor allen Dingen das Problem, dass sie nicht aktuell sind. In Thema Webdesign/Webprogrammierung hat sich in den letzten Jahren einiges getan, was in den entsprechenden Werken keinen oder kaum Anschlag findet: inline-SVG, diverse Stylesheet "Neuigkeiten" etc. pp. In einer gemeinsam bearbeiteten Dokumentation wäre eine "aktuelle" Version möglich. --Nightware 17:07, 9. Mär. 2009 (CET)

Konventionen

Mir ist sofort aufgefallen, dass das Buch mehrere Probleme hat:

• Die Bücher XHTML (alt), Websiteentwicklung: XHTML (neu) und HTML (alt) sind vermischt - mit fatalen Folgen. Die Vor- und Zurück-Links zeigen teilweise auf alte Bücher / Kapitel.
• Das Buch heißt "Websiteentwicklung: XHTML", verwendet jedoch meist HTML statt XHTML.

Daher sollten sich die Autoren über ein paar Konventionen innerhalb des Buches einig werden:

• Ich glaube, es macht wenig Sinn, die alten Bücher beizubehalten. Sobald sämtliche Kapitel und Informationen in die neuen integriert sind, sollten die alten Bücher ganz gelöscht werden.
• Die Kapitel sollten ausschließlich innerhalb des neuen Buches verlinken.
• Mit Ausnahme expliziter HTML-Beispiele in einem Kapitel über das alte HTML sollte konsequent XHTML verwendet werden. Ich schlage vor, XHTML 1.1 zu verwenden, da dies nachwievor große Kompatibilität mit HTML 4.01 besitzt.
• An vielen Stellen ist sachlich falsch von "Tag" die Rede, wenn eigentlich "Element" gemeint ist. Ich finde, ein Buch sollte mit gutem Beispiel vorangehen und die korrekte Terminologie verwenden. Auf die falsche Terminologie kann man ja in der Einführung eingehen.
• Das Buch sollte in zwei Teile gegliedert werden. Ein Einführungsteil, der ohne zu tief gehende technische Details den Leser möglichst schnell zu praktischen Ergebnissen und Erfolgserlebnissen führt, sowie einen Hauptteil, der sämtliche Details erklärt, wie z.B. auch jene XML-Grundlagen, die ein XHTML-Entwickler benötigt, um selbständig sowohl wohl-geformtes als auch gültiges X(HT)ML zu schreiben.

Wie gesagt, nur ein paar Vorschläge für Konventionen und Richtlinien, wie man das Buch auf einen guten Weg bringen könnte, sicherlich ergänzungs- und diskussionswürdig, aber mal ein Anfang. --212.114.250.70 20:43, 7. Apr 2005 (UTC)

XHTML 1.1 hat nicht mehr die Zielstellung der Kompatibilität mit HTML 4.01. Bspw. darf man ein XHTML 1.1-Dokument nicht mehr mit dem MIME-Typ text/html verwenden, sondern man muss z. B. application/xhtml+xml verwenden, text/xml ist auch noch erlaubt. Desweiteren ist mir nach wie vor die Zielstellung unklar: was soll dieses Buch bieten, was es nicht schon dutzendmal woanders gibt? --Matthias

Zur Zielstellung von XHTML 1.1: Das ist nicht 100% korrekt.

http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/ sagt über die Auslieferung von XHTML 1.1 als text/html "SHOULD NOT", nicht "MUST NOT". Gemäß der klassischen Lesart von "SHOULD NOT" gemäß dem von der Note referenzierten RFC 2119 bedeutet es, dass man XHTML 1.1 unter Umständen durchaus als text/html liefern darf, wenn man sich darüber im Klaren ist, was und warum man das tut. Eine Recommendation, die eine Auslieferung von XHTML 1.1 als text/html verbietet, gibt es nicht. Das RFC über text/html verbietet eine Auslieferung indirekt, allerdings sind in diesem Bereich sowieso viele Diskrepanzen zwischen den Dokumenten des W3C und denen der IETF historisch entstanden. Eine Verwendung von XHTML 1.1 bei Verzicht auf nicht in XHTML 1.0 Strict vorhandener Features resultiert in einem lediglich eine andere DTD referenzierende, aber ansonsten aus dem selben Infoset bestehenden X(HT)ML-Dokument, das auch von solchen Browsern verarbeitet wird, die mit XHTML 1.0 Strict als text/html zurecht kommen. Im Wesentlichen bedeutet dies, beim Ruby Module darauf hinzuweisen, dass XHTML 1.1 Dokumente, die dieses Modul verwenden, eigentlich nicht mehr als text/html gesendet werden sollten.

Die Formulierung, XHTML 1.1 hat nicht mehr die Zielstellung der Kompatibilität möchte ich dahingehend ergänzen, dass das W3C nicht mehr eine zwanghaft weitmöglichste Kompatibilität zu erreichen suchte, wie es vorher bei XHTML 1.0 war, jedoch die bestehenden (X)HTML-Elemente durchaus zwecks Kompatibilität unverändert übernommen wurden, was bei XHTML 2.0 definitiv nicht mehr der Fall sein wird.--ChristianHujer 19:38, 15. Apr 2005 (UTC)

Zur Zielstellung des Buches: Hier hätte es mal die Chance, ein tatsächlich 100% korrektes Buch zur allgemeinen freien Verfügung zu stellen - langfristig, versteht sich, im jetzigen Zustand ist das Buch eine große Katastrophe, aber jeder ist in der Lage, einen Beitrag zur Besserung zu leisten :) --ChristianHujer 19:38, 15. Apr 2005 (UTC)

Auch beim W3C steht, daß XHTML 1.1 nicht als text/html ausgeliefert werden *darf*

http://www.w3.org/MarkUp/2004/xhtml-faq#mime11

Zur leichten Verständlichkeit

Die leichte Verständlichtkeit halte ich für einen sehr wichtigen Teil eines solchen Buches. Damit könnten wir viele andere XHTML-Bücher übertrumpfen, denn es gibt einfach zu viele komplizierte (X)HTML-Werke. Denen allen hätten wir durch besondere Einfachheit und Didaktik dann etwas vorraus.

Dazu erstmal grundsätzlich ein Beispiel, wo man dass verbessern könnte: Im aktuellen Zustand gefallen mir die drei Kapitel Syntax, Aufbau einer XHTML Seite und Kommentare nicht, weil sie für den Laien meiner Meinung nach unverständlich sind.

Mit der Seite "Syntax" kann niemand etwas anfangen, der noch nie HTML gemacht hat, deswegen würde ich sie entweder ganz raus nehmen oder in den Anhang tun. Ich finde man sollte grundsätzlich XHTML verwenden und zwar von Anfang an, sodass der Leser vielleicht sogar gar nicht mitbekommt, dass man in normalem HTML bswp. <br> anstatt <br /> schreibt.

Das Kapitel "Aufbau einer XHTML-Seite" finde ich auch ein bisschen unpassend, weil der Leser ein zu komplexes Beispiel an den Anfang einfach direkt vor die Füße geworfen bekommt. Man sollte zuerst locker vorgehen und erklären, wie das überhaupt mit den Elementen läuft, dann das <html>-Element erklären, danach die beiden <body> und <head> und dann noch <p> und schwupps hat man schon ein erstes HTML-Dokument. Später im Kapitel kann dann ja noch die !DOCTYPE-Anweisung erklärt werden, man muss ja nicht während der ersten Schritte auf Teufel komm raus umbedingt 100% valide sein. Natürlich soll das Ergebnis, nachdem man über die Grundlagenkapitel raus ist, dann 100% valides XHTML sein. Die komplette History aller HTML-Versionen finde ich unnötig, die würde m.E. dann eh überlesen.

Das Kommentare-Kapitel halte ich für viel zu überladen. Spätestens bei der Backus-Naur-Form unten hört es dann auf, dass jemand, der vorher noch nichts mit HTML zu tun hatte, noch mitkommt. Man sollte einfach erstmal nur kurz Kommentare anreißen und die Funktion erklären, die ganz detailierte Anleitung zu Kommentaren könnte dann, wenn umbedingt benötigt, in das XML-Buch rein.

Ich denke auch, dass das Inhaltsverzeichnis noch ein wenig unstrukturiert ist, und bin der Meinung, dass es noch mehr Planung braucht.

Meine Zielsetzung ist es, ein Buch zu schaffen, dass sehr verständlich -- auch für Zwölfjährige -- ist und bei der man es von Anfang an richtig lernt, also ohne Umweg über font-Tags und Co. Ich habe selber jetzt einige Änderungen hier lokal gemacht, und wollte nun erstmal gucken, inwieweit ihr meine o.g. Vorschläge bzw. die Zielsetzung zur guten Verständlichkeit teilt, bevor ich sie ins Wiki reinstelle. --aleχ 08:55, 7. Mai 2005 (UTC)

Viel zu viele unverständliche Details und Abkürzungen schon in den ersten Sätzen. Was bedeutet beispielsweise "Auszeichnung von Texten"? Glaubt etwa jemand, ein XHTML-Neuling würde nach Lesen des letzten Absatzes von Websiteentwicklung: XHTML: Beschreibung noch weiterlesen? Schreibt hier jeder Mitautor für eine andere Zielgruppe? -- Worker 18:50, 25. Dez 2005 (UTC)

Inhaltsverzeichnis

Ich schaute mir soeben seit langem wieder diese Seite an. Sie wirkte auf mich irgendwie abschreckend. Es ist das ganze Inhaltsverzeichnis ohne Erklärungen vorhanden. Als Unerfahrener und neuer Benutzer des Internets würde ich diese Seite sofort wieder verlassen, ich würde mich nicht zurechtfinden und wüsste nicht, um was es hier genau geht....
Aus diesem Grund habe ich ein kurzes Vorwort eingefügt. Vielleicht ist es auch noch eine gute Idee, jedes Kapitel mit einem oder zwei Sätzen noch kurz zu Beschreiben um beim Leser Interesse zu wecken und das Ganze etwas lockerer zu gestalten.
Was haltet ihr davon?? --Swissgenie 20:49, 4. Sep 2005 (UTC)

Ich schlage vor einen Abschnitt "Vorbereitungen" oder "Vorraussetzungen" als ersten Teil des Kapitels "Grundlagen" einzuführen, um die Trennung von der Erstellung einer Seite von der dazu notwendigen Software abzugrenzen. --Nightware

Dieses Buch ist Nachfolger von XHTML. Ich kann nicht einschätzen ob dass andere Buch schon vollständig hier aufgegangen ist - deshalb sicherheitshalber der Link hier. --Bastie 09:51, 9. Mai 2005 (UTC)

Aktuell zeigen die beiden Lemma XHTML und Websiteentwicklung: XHTML auf dieses Buch, es ist also mittlerweile eins… --Feeela 01:49, 14. Okt. 2011 (CEST)

Platz gesucht für folgende Elemente

Wo kommt der Abschnitt über die Elemente b, big, hr, i, small, sub, sup, tt??? --Swissgenie 17:22, 30. Dez 2005 (UTC)

ich würde sagen nach Websiteentwicklung: XHTML: Textformatierung, das wird aber bis dato nicht in der Übersicht aufgeführt. --mt ^話し 14:17, 15. Apr 2006 (UTC)

Das sich das Buch anscheinend auf XHTML 1.0 STRICT bzw. XHTML 1.1 bezieht, kommen diese Elemente gar nicht vor --Feeela 01:29, 14. Okt. 2011 (CEST)

Frames, Handbuch Webdesign

Fehlt hier nicht noch ein Artikel über Frames?
Und wie ist es mit der Einbindung des Handbuch Webdesign?
--Kato-cha 14:43, 31. Mär. 2009 (CEST)

Also das Handbuch Webdesign sieht richtig gut, wenn nicht sogar fertig, aus. Ich wär ja dagegen das wieder auseinander zu nehmen um es hier einzubauen. Und wenn ein Kapitel fehlt, dann schreib das doch? ;) --Borstel 15:03, 31. Mär. 2009 (CEST)

Man muss es ja nicht außeinandernehmen: ich dachte eher daran, Teile zu übernehmen.

Zum zweiten bin ich eigentlich gekommen, um etwas über Frames zu erfahren, aber das Buch hier ist schon etwas ungeeignet dafür. Aber ich werde mich jetzt mit CSS auseinander zu setzen, dann sind Frames nicht mehr nötig.

--Kato-cha 16:12, 31. Mär. 2009 (CEST)

Dann wünsch ich dir viel Erfolg! Wenn du Fragen hast, kannst du gerne auf mich zurück kommen. :) --Borstel 08:53, 2. Apr. 2009 (CEST)

Okay, danke.

--Kato-cha 12:21, 3. Apr. 2009 (CEST)

Allgemeine Anmerkungen (am Beispiel: "Absätze, Element p")

Ich stieß auf dieses Wikibook, als ich eine Einführung zu XHTML suchte. Mir ist nicht ganz klar, welche verschiedenen Ziele die Autoren mit den einzelnen Beschreibungen verfolgten, es müssen jedoch mehrere gewesen sein. Anders lassen sich die mitunter unnötig langen Texte, die noch dazu mehrere Randgedanken aufnehmen, nicht erklären.
Am Beipiel "Absätze, Element p" lässt sich das gut zeigen:
Hätte es nicht gereicht zu schreiben: "Ein Absatz wird so erzeugt: p Text /p" (< und > inbegriffen)

Wieso über die Ausgabe in Darstellungsprogrammen etwas verfasst wird, ist mir rätselhaft. Vom Charakter her erscheint dieses Wikibook doch als Lehrbuch, die Ausgabe betrifft doch aber letztlich nur den Anwender.
Für einen Einsteiger ist der Satz über "Blockelement" und "inzellige Elemente" eher verwirrend und lädt nicht sehr zum Weiterlesen ein.

Was ist das nun? Ein Lehrbuch?
Konzept überdenken!

Meiner Meinung nach ist im Moment die Struktur der Kapitel noch ziemlich suboptimal und inhaltlich fehlt noch vieles, zudem ist bislang noch nicht mal definiert, welche Versionen von XHTML hier schwerpunktmäßig behandelt werden. Von daher ist da einiges verbesserungswürdig. Und weil einige Sachen hin- und hergeschoben werden, ist derzeit auch einiges doppelt oder dreifach vorhanden, an einigen Stellen also redundant - sollte aufgeräumt werden, wenn die Kapitelstruktur irgendwann mal schlüssig und sinnvoll ist.

Was den Absatz anbelangt - der hat ja inhaltlich eine Bedeutung. Da ist es für viele Autoren schon eine Hilfe zu wissen, wie Darstellungsprogramme das typisch umsetzen - denn viele Elemente sind bei der nachherigen Darstellung ja gar nicht so auffällig - und falls man das dann auch noch per CSS dekorieren will, bekommt man so natürlich auch ein besseres Gefühl dafür, was in den browser-Stilvorlagen ungefähr stehen wird, was man dann bei Bedarf überschreiben kann. Ausführlichere Spezifikationen wie HTML4 haben sogar Musterstilvorlagen für browser, damit die Elemente zumindest ähnlich dargestellt werden. Beim p ist dadurch etwa die europäische Variante mit dem vertikalen Platz vor einem Absatz üblich geworden, statt einer anderen, ebenfalls gängigen Variante, den Text zu Beginn der ersten Zeile etwas einzurücken. Autoren oder Leser, die das bevorzugen, müssen ihre Stilvorlagen dann entsprechend anpassen, um die browser-Stilvorlagen zu überschreiben.

Ob Blockelement oder inzeilig ist schon wichtig, weil man nicht jedes Element in einem anderen notieren darf. Richtig ist natürlich, daß da vorne noch ein Kapitel oder Abschnitt fehlt, der das erklärt. Derzeit steht der deplatziert noch viel weiter hinten, ist eben im Fluß. Die Alternative der Erwähnung im Fließtext wäre jeweils pro Element ein formales Kästchen, in welchem man mit geeigneten Abkürzungen notiert, welche Attribute verwendet werden können und wie das minimale Modell für den Inhalt ist - glaube aber nicht, daß das inhaltlich besser ist. Für p sieht das etwa so aus:

p: Attribute 'Common'; Inhalt: (PCDATA | Inline)*

Damit kann ich jede Elementbeschreibung auf einen Einzeiler reduzieren und das Buch auf ein Kapitel mit ein paar Listen - hat dann mit einem Lehrbuch aber auch nicht mehr viel zu tun ;o)

Die nächste Alternative wäre, jedesmal statt der Abkürzungen alle Attribute und Elemente immer wieder aufzuführen - gibt dann für jedes Elemente eine relativ eintönige Liste, zudem noch mit Elementen, die an der Stelle noch gar nicht behandelt wurden. Zum Lehrbuch gehört ja auch, daß man nachschlagen kann, was man mit so einem Element nun eigentlich anstellen kann - und läßt man weg, was erlaubt ist, ist der Leser genauso schlau wie zuvor und weiß nicht, was er nun mit dem Element anfangen kann und was nicht.

Doktorchen 17:45, 14. Okt. 2011 (CEST)

Was vermittelt dieses Buch?

Die Idee ist grundsätzlich nicht verkehrt, nur ist dies hier IMHO dann kein praxisnahes Lehrbuch für angehende Webhandwerker, sondern die Beschreibung eines Standards. Das mag ein hehres Ziel sein, ist aber im beruflichen Alltag nicht gefragt und auch der Hobby-Webdesigner wird damit eher ausgebremst. Klar ist HTML5 erst in der Entwurfsphase – das wird voraussichtlich aber auch noch mindestens fünf Jahre so bleiben, dennoch wird es eben bereits seit zwei Jahren auf mehr Webseiten eingesetzt, als dies für wohlgeformtes XHTML jemals der Fall war! --Feeela 02:45, 18. Okt. 2011 (CEST)

Wie in dem Abschnitt bereits erwähnt, sollen Wikibooks ja gesichertes Wissen vermitteln - und ein bloßer Arbeitsentwurf, der sich praktisch täglich ändert, ist nunmal keine Grundlage für ein Wikibook im Allgemeinen und erst recht nicht für ein Lehrbuch. Von Opera habe ich zu Weihnachten ein Buch über HTML5 geschenkt bekommen ('Introducing HTML5', Bruce Lawson, Remy Sharp). Da stehen jetzt schon einige Sachen drin, die inzwischen schon wieder anders im Arbeitsentwurf stehen. Prinzipiell kann man solche Lehrbücher online mit genug Leuten schon auf dem aktuellen Stand halten, nur bei diesem Buch hier ist es seit der Entstehung ja nicht einmal gelungen, es halbwegs vollständig hinsichtlich bestehender Standards zu realisieren. Von daher scheint es mir nicht realistisch zu sein, auf die HTML5-Versuche genauer einzugehen. Wer das heute als Autor nicht nur auf Testseiten einsetzt, sondern im normalen Betrieb, ist extrem experimentierfreudig und kümmert sich wohl auch recht wenig darum, ob das nun bei allen Nutzern der Seite funktioniert oder nicht - denn hinsichtlich Zugänglichkeit und Barrierefreiheit sind da viele Sachen bei HTML5 (noch?) im Argen. Gerade in der Hinsicht ist da Vieles einfach nicht brauchbar, was auf den ersten Blick wie eine Verbesserung aussieht. Hinzu kommt noch, daß es zwar möglich ist, irgendwelche Seiten als HTML5 zu interpretieren, es ist aber derzeit formal gar nicht möglich, HTML5-Dokumente zu schreiben, weil man sie formal nicht als solche kennzeichnen kann.

Wenn das Buch nur etwas über Markierungssuppe für Hobby-Bastler vermitteln soll, dann verstehe ich andererseits dein Bemühen um semantisch gut realisierte Dokumente nicht ;o) Und es gibt ja nun auch Hobby-Bastler, die wissen möchten, wie man es richtig macht - und den anderen kann es ja auch nicht schaden, wenn sie lernen, korrekte und definierte Dokumente zu schreiben. Vielleicht gelingt es dann ja irgendwann, wenn das viele Lehrbücher machen würden, die Menge an Markierungssuppe unter 90% zu drücken.

Hinsichtlich der praktischen Anwendbarkeit habe ich vor einiger Zeit mal für die neuen semantischen Elemente eine kleine Testseite geschrieben - ohne Hilfe per CSS war die Anzeige in gängigen browsers gruselig bis unbrauchbar, was auch daran liegen mag, daß die Vorschläge für browser-Stilvorlagen im Arbeitsentwurf zu praktisch komplett unleserlichen Resultaten führen, wenn man nicht zusätzliche div-Elemente reinbastelt, die das einigermaßen wieder hinbiegen. Also alltagstauglich ist das bislang keinesfalls, gerade nicht in den aktuellen gängigen browsern - wobei ich mir den Arbeitsentwurf und die Tests irgendwann mal wieder angucken muß, ob sich daran irgendwas geändert hat ;o)

Doktorchen 10:43, 18. Okt. 2011 (CEST)

Ok, jetzt habe ich die Intention verstanden. Dauerte wohl etwas länger diesmal. ;-) Nach dieser Argumentation kann ich da voll mitgehen. --Feeela 13:02, 18. Okt. 2011 (CEST)