Wäre eine Möglichkeit gewesen, aber ich hab d_o noch nicht erreicht und er hatte ja bereits einen Accoutn für mich eingerichtet.
Ich habs nebenbei auch in einem XHTML-Forum gepostet, aber nur wenig resonanz erhalten, ist wohl auch sehr viel Text geworden..
Wenn du die umformatierung übernimmst, so dass es ins Dev-Comm passt, können wir gerne weiterreden^^
Allerdings fällt mir auf, dass Dev-Comm ebenfalls giftiges XHTML verwendet.
Geändert von mitaki (12.12.2007 um 00:22 Uhr)
Den Account hab ich angelegt. Das Passwort kann ich dir gerne per PN schicken. Und die Formatierung unterscheidet sich eigentlich nur unwesentlich von der im Forum. Der einzige Unterschied ist, dass Größenangaben anders funktionieren und dass es für Überschriften [h1], [h2] usw. gibt.
--
Danke für diesen wie gewohnt guten Artikel
Ich habe glaube ich einiges Neues über XHTML gelernt und werde diesen Artikel in Zukunft als Referenz heranziehen, wenn ich mal wieder XHTML verbreche. Kritik fällt mir eigentlich keine ein, der Artikel ist gut strukturiert und vollständig.
Mal schauen, ob ich demnächst den XHTML Code von Dev-Comm überarbeite
--
Danke, dabei ist's nur ein Entwurf. An anderer stelle wurde mir Ungenauigkeit vorgeworfen. Aber da gibts ja auch tatsächlich ein paar Stellen, die ich noch überarbeiten werde.Zitat von Manni
Danke für diesen wie gewohnt guten Artikel
Und wenn ich nur einem einizgen was beibringen konnte ist es Genugtuung^^
Ich habe meinen ganzen XHTML-Enthusiasmus verloren, auch aufgrund dieser ganzen Richtlinien, die beachtet werden müssen. Dafür nur einen Vorteil zu erhalten ist mir zu wenig. Strengere Validierung ist auch bei HTML möglich und den Rest der möglichen Fehler kann man als guter Autor vermeiden.Mal schauen, ob ich demnächst den XHTML Code von Dev-Comm überarbeite
Inzwischen überzeugt mich HTML 5 mehr und mehr. Witzigerweise wäre HTML 5 auch eine gute Wahl für Dev-Comm. Schade, dass es noch ein paar Jahre dauert bis man damit vernünftig arbeiten kann...
Nebenbei zu Dev-Comm. Es wäre toll, wenn ein paar der Links zu Webdesign gelöscht werden könnten. Dokumente ohne Doctype und Frames sollten nur in berechtigten Fällen gelehrt werden. Niemals als Einstieg für Anfänger. Das oder ein Bewertungssystem für die Einträge.
Wenn ich die Zeit hätte müsste ich wohl auch mal einen HTML-Kurs schreiben. ^^
Such uns raus, was weg muss und wir schmeißens raus. Wir hatten nur bei der Masse an Material nicht die Zeit, alles durchzuschaun.
--
gebookmarkt! gut gemacht und wieder hast du verhindert dass ich nach solchen inhalten erst googeln muss ^^
Hab mir jetzt auch mal die Zeit genommen, den kompletten Artikel durchzulesen. Ist ja nicht ganz wenig. ^^
Auf jeden Fall hat er mir sehr gut gefallen. Gut geschrieben und genauso informativ wie deine anderen Artikel.
Da ich mich sowieso mal mit diesem Thema auseinandersetzen wollte, hast du mir echt geholfen. =)
Könntest du mir vielleicht einen Tipp geben, welche Spezifikation man verwenden sollte? HTML 4.01 in der Strict-Variante ist ja glaube ich immer noch eine gute Wahl, soweit ich das jetzt aus deinen Artikeln herauslesen konnte.
Bleibt mir eigentlich nurnoch zu sagen, dass ich auf weitere gute Artikel von dir gespannt bin. ^^
Schön zu Wissen, dass der Text dem ein und anderen hilfreich erscheint
Ja, HTML 4.01 Strict ist die Wahl fürs Web! Allerdings dazu ein paar Hinweise von mir.
- Wenn du das start-Attribut im ol-Element oder das value-Attribut des li-Elements benötigst: Verwende Strict, obwohl es nicht konform ist. Die beiden Attribute können durchaus von Bedeutung für den Inhalt sein. Aber deswegen einen schlechteren Darstellungsmodus im Browser zu aktivieren lohnt sich nicht.
- In Strict dürfen Inline-Elemente nicht lose stehen sondern müssen in Blockelementen stehen. Verwende dazu bitte nicht das div-Element. Das wäre nichts anderes als Tabellen für das Layot zu missbrauchen.
- Verwende David Hammonds Good Practice Checker, damit wird der Quelltext gegen eine strengere DTD geprüft und Spielereien wie optionale Endtags fallen weg. Die Unterschiede zur normalen DTD kann man in einem Blog-Eintrag nachlesen.
Ich selbst würde aber wieder gegen den letzten Punkt verstoßen, die richtige Zeichenkodierung für HTML zu setzen ist kein Problem (Zum HTTP-Header passende Metaangabe als erstes Kind des head-Elements). Auch das b- und das i-Element würde ich in der Not gelten lassen (span@class=bold ist nicht wirklich besser).
Hammonds Werkzeug erkennt nicht alle möglichen Fehler, aber einen Großteil. Wer auf die drakonische Fehlertoleranz von XML nicht verzichten möchte sollte meiner Meiung nach die Inhalte als XML speichern, diese aber in HTML umtransformieren, bevor diese den Browser erreichen. Das beste aus beiden Varianten nehmen also
--
Die Wespe, der Fuchs und der Vogel gehen erst in die Oper und dann auf Safari. 8)
Nützliche Adressen (HTML, CSS, PHP, MySQL, Werkzeuge) für Webgestalter.
-> Übersicht meiner Artikel (HTML Strict verstehen Teil 1-8 und weitere interessante Themen).
Was soll man denn sonst verwenden? Ok, dass man für ein Menü z.b. Listen verwendet, ist klar, aber einen Header? Oder wenn man eine Zentrierte Box haben will, die in zwei Spalten unterteilt wird? Für sowas braucht man schon mal 3 oder mehr Divs, wie willst du es denn anders realisieren?
Man kann ja statt <b> beispielsweise auch <strong> nehmen, das wäre sowieso besser. Ob man <i> durch <em> ersetzen sollte, weiß ich gerade nicht, da ich die Bedeutung von <em> jetzt nicht auswendig weiß - von der Anzeige her sollte es zumindest klappen (und ist <em> nicht für betonte Textteile? Dann wäre es funktionell gesehen auch richtig!)
Glaube hier hast du mich falsch verstanden.
In Strict ist nicht erlaubt, dass Inlineelemente lose herumstehen, z.B im body-Element. Nun könnte man mit dem div-Element eine Brücke bauen...
Das verändert aber die Bedeutung nicht bzw. dichtet dem div-Element ein unpassende Bedeutung zu.
Das div-Element dient zur Gruppierung mehrerer Elemente, aber nicht um Inlinelemente dort zu erlauben, wo sie eigentlich nicht hingehören. Das hat mit der Zugänglichkeit usw. zu tun.
Die von dir genannten Fälle scheinen diese Regel nicht zu brechen und sind daher natürlich erlaubt.
Das kann man grundsätzlich nicht sagen und muss im Einzelfall entschieden werden. Daher wurden diese 4 Elemente in HTML 5 neu definiert bzw. ihre Bedeutung verändert.
<b> und <i> stellen nun Satzteile/Namen/etc. dar, die in der Regel mit dieser Formatierung geschrieben werden. Beispielsweise eine andere Stimmlage bei <i> oder Produktnamen für <b>.
<em> steht zwar weiterhin für Betonung, allerdings wird diese betonung nicht durch <strong> verstärkt sondern durch verschachtelte <em>. Je mehr <em> umso stärker die Betonung.
<strong> dagegen wird für wichtige Abschnitte verwendet, wozu beispielsweise aus Wörter wie „Achtung“ und „Fehler“ gehören.
Ja, stimmt - jetzt verstehe ich, was du gemeint hast. :-)
Ich nehme an, bei der Umsetzung der Regeln ist das aber noch nicht durchgedrungen, oder? Systeme für Sprachausgabe interpretieren kein <b> und <i>, oder irre ich mich da?
Das einzige, das ich hier weis ist, dass z.B. Lynx <b> und <i> ebeneso farbig darstellt wie <em> und <strong>. Bei der Anzahl der verwendeten Elemente würde es mich aber nicht wundern, wenn Sprachbrowser sich hier ebenfalls schon angepasst hätten.
Berechtigungen
Zitieren
