nicht angemeldet Felix Riesterer
Gunnar Bittersmann
Gunnar Bittersmann
Ulysses
Ulysses
Gunnar Bittersmann
Ulysses
at
Tim Tepaße
Sollte ich wenn ich ein Projekt aufziehe weiterhin XHTML 1.0 Trans nehmen oder kann ich schon auf HTML 5 zählen? Wie sieht es da mit der Browserkompatiblität aus und Was ist mit XHTML 5? gibt es das?
Gruß, Friend
Lieber Friend,
Sollte ich wenn ich ein Projekt aufziehe weiterhin XHTML 1.0 Trans nehmen oder kann ich schon auf HTML 5 zählen?
nimm XHTML1.0 strict. Strict ist immer gut, da es Dich zwingt, anständigen Code zu schreiben.
Wie sieht es da mit der Browserkompatiblität aus
Die meisten User haben noch keinen HTML5-fähigen Browser. Beantwortet das Deine Frage?
und Was ist mit XHTML 5? gibt es das?
Was hat Google Dir dazu gesagt?
Liebe Grüße,
Felix Riesterer.
Hi Felix.
Ja aber es ist sooo verlockend.
Ich schreibe ein Forum und es ist perfekt dafür Elemente wie: article, dialog, figure usw. zu benutzen..
=/ Menno..
Ja XHTMl strict habe ich früher immer genutzt aber mich frusted es wenn der Validator rot statt grün zeigt und das nur weil ich keine Alternative zu target="" kenne.
Gruß,
Friend
@@Friend:
nuqneH
mich frusted es wenn der Validator rot statt grün zeigt und das nur weil ich keine Alternative zu target="" kenne.
Und wie es erst den Nutzer frustet.
“Don't pollute my screen with any more windows, thanks […]” (Top Ten Mistakes in Web Design, Punkt 9 [Nielsen]) S.a. Diskussion im Thread Internetseitenlink im neuen Fenster öffnen
Die Alternative ist klar: kein @target.
Qapla'
Aber wenn ich von meiner Seite auf YouTube verlinken möchte, dann sollte ein neuer Tab im Browser geöffnet werden..
@@Friend:
nuqneH
Aber wenn ich von meiner Seite auf YouTube verlinken möchte, dann sollte ein neuer Tab im Browser geöffnet werden..
Wenn der Nutzer es will und deshalb von _sich aus_ YouTube in einem neuen Tab öffnet, ja.
Ansonsten: nein.
Qapla'
Hallo,
Wenn der Nutzer es will und deshalb von _sich aus_ YouTube in einem neuen Tab öffnet, ja.
Ansonsten: nein.
oder wenn der Kunde es unbedingt will
@@Grog:
nuqneH
oder wenn der Kunde es unbedingt will
Dann ist es dein Job zu versuchen, es ihm auszureden. Nicht dein Kunde ist der König, sondern dessen Kunden – die Nutzer seiner Website. Was wollen diese unbedingt?
Qapla'
hi,
Aber wenn ich von meiner Seite auf YouTube verlinken möchte, dann sollte ein neuer Tab im Browser geöffnet werden..
Du könntest, so wie hier im Forum, eine Option anbieten, in der jeder User für sich selbst einstellen kann, ob er Links in einem neuen Tab/Fenster öffnen möchte oder nicht.
Wenn ja, mittels Javascript allen Externen Links ein target zuweisen.
mfg
Hi,
Aber wenn ich von meiner Seite auf YouTube verlinken möchte, dann sollte ein neuer Tab im Browser geöffnet werden..
Also wenn ich ein Ziel im neuen Fenster oder Tab aufmachen möchte, dann mache ich das schon selbst. Danke. Wenn man mir nicht dabei in die Quere kommt, es bei Wunsch wie üblich auch im gleichen Fenster/Tab anzeigen zu lassen, dann finde ich das "Gut" (eher: selbstverständlich) - für den Fall, daß ich mal vorm Browser ohne "Target-Killer" sitze. Positiv kann ich es noch werten, wenn eine bestimmte Gattung Links aus einem nachvollziehbaren Grund vorzugsweise nur in einem bestimmten Fenster/Tab aufgeht.
Gruß, Cybaer
hi,
Ja XHTMl strict habe ich früher immer genutzt aber mich frusted es wenn der Validator rot statt grün zeigt und das nur weil ich keine Alternative zu target="" kenne.
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fdj-tut.de%2F
Rechts über die Bookmark-Buttons hovern und im eingeblendeten Text auf das „X“ klicken.
mfg
Hi!
Rechts über die Bookmark-Buttons hovern und im eingeblendeten Text auf das „X“ klicken.
Da muss man aber erst auf due Idee kommen, dass das „X“ für „in einem neuen Fenster öffnen“ steht.
Übrigens: Im FF 2.0, vor dem ich gerade sitze, ist das „X“ unerreichbar!
FG Ulysses
hi,
Da muss man aber erst auf due Idee kommen, dass das „X“ für „in einem neuen Fenster öffnen“ steht.
Die Idee ist noch nicht zu ende entwickelt; ich wollte es einfach nur mal antesten.
Übrigens kam mir die Idee dazu hier im Thread.
Übrigens: Im FF 2.0, vor dem ich gerade sitze, ist das „X“ unerreichbar!
Was meinst du mit unerreichbar? Die Box, in der diese Links stecken zu klein und dementsprechend abgeschnitten?
mfg
Hi!
Was meinst du mit unerreichbar? Die Box, in der diese Links stecken zu klein und dementsprechend abgeschnitten?
Nein, aber sobald ich mit der Maus von einer Box runterfahre verschwindet das „X“ wieder...
FG Ulysses
hi,
Was meinst du mit unerreichbar? Die Box, in der diese Links stecken zu klein und dementsprechend abgeschnitten?
Nein, aber sobald ich mit der Maus von einer Box runterfahre verschwindet das „X“ wieder...
Das werde ich heute Abend fixen; da fehlt nur ein bisschen Höhe/padding für das durch hovern eingeblendete Element.
Danke für den Hinweis.
mfg
@@Ulysses:
nuqneH
Nein, aber sobald ich mit der Maus von einer Box runterfahre verschwindet das „X“ wieder...
https://forum.selfhtml.org/?t=188750&m=1256920
Dieses Problem sollte wohl in jenem Thread weiterdiskutiert werden, nicht hier.
Qapla'
Hi!
@@Ulysses:
nuqneH
Nein, aber sobald ich mit der Maus von einer Box runterfahre verschwindet das „X“ wieder...
https://forum.selfhtml.org/?t=188750&m=1256920
Dieses Problem sollte wohl in jenem Thread weiterdiskutiert werden, nicht hier.
Den hab ich erst später gelesen udn auf das „X“ hat mich schließlich ja dieser Thread hier gebracht...
jener Thread ist laut Malcolm Beck´s eine andere Baustelle und die Diskussion darüber auch schon wieder beendet...
FG Ulysses
Hallo.
Ja XHTMl strict habe ich früher immer genutzt aber mich frusted es wenn der Validator rot statt grün zeigt und das nur weil ich keine Alternative zu target="" kenne.
Alternativ solltest du den angeführten Attributwert als Attribut verwenden.
MfG, at
Hi,
kleines Contra:
nimm XHTML1.0 strict. Strict ist immer gut, da es Dich zwingt, anständigen Code zu schreiben.
Ist validierter (X)HTML5-Code (oder der eine sonstigen (X)HTML-Variante) "unanständig"?
Entweder man macht sich Gedanken, *warum* der Code einer Seite so sein sollte, wie er sein sollte, oder man vertraut einfach darauf, daß schon alles OK sein wird, wenn das "grüne Lämpchen" leuchtet.
Letzteres kann auch schiefgehen. Und daß "strict" "immer" "gut" sein soll, wage ich auch nachhaltig zu bezweifeln ...
Die meisten User haben noch keinen HTML5-fähigen Browser. Beantwortet das Deine Frage?
Viele User haben auch noch keinen XHTML-fähigen Browser. (Nein, keine neue Diskussion, ob man das "Downgrade-XHTML" der IEs per Definitionem "XHTML" ist ;->).
Aber ganz allgemein: Aufgrund der bewußten Anwärts- und Aufwärtskompatibilität von HTML, ist es theoretisch (praktisch sowieso) kein Problem, wenn man bewußt dennoch HTML-5-Elemente benutzt - selbst wenn noch überhaupt kein Browser das Element unterstützt. Problematisch ist doch einzig, daß sich bei HTML 5 noch Änderungen ergeben könnten. Ob man dieses "Risiko" eingeht, mag dann noch vom Einzelfall abhängen.
Gruß, Cybaer
Ist validierter (X)HTML5-Code (oder der eine sonstigen (X)HTML-Variante) "unanständig"?
XHTML 5 ist nicht für die Praxis geeignet und HTML 5 erlaubt viele Inkonsistenzen und Kurzschreibweisen. HTML 4 Transitional / XHTML 1 Transitional erlaubt Markup, das man i.d.R. vermeiden sollte und kann, und erlaubt Verschachtelungen, die zu schlechtem Stil führen können. HTML 4.01 Strict und XHTML 1.0 Strict sind immer noch gute Empfehlungen für Leute, die eine Vorgabe und Anleitung haben wollen.
Entweder man macht sich Gedanken, *warum* der Code einer Seite so sein sollte, wie er sein sollte
Gerade das rät man einem Anfänger aber nicht - dann müsste er nämlich damit anfangen, dicke SGML-Bücher aus den frühen 90ern zu wälzen.
oder man vertraut einfach darauf, daß schon alles OK sein wird, wenn das "grüne Lämpchen" leuchtet.
Wenn man nicht in die Syntax-Abgründe von HTML-4-SGML und HTML-5-Parsing absteigen will - dann kann man, wie z.B. Michael Jendryschiks Einführung es jedem nahelegt, einfach XHTML 1.0 Strict verwenden und dann ist tatsächlich schon vieles in Ordnung, wenn das grüne Lämpchen (am besten beim Schema-Validator!) leuchtet.
Letzteres kann auch schiefgehen. Und daß "strict" "immer" "gut" sein soll, wage ich auch nachhaltig zu bezweifeln ...
Es ist eine Faustregel, die 99% abdeckt.
Mathias
Hallo.
Anwärts- und Aufwärtskompatibilität
Erstere war mir bislang nicht geläufig. Vielen Dank für diese Bereicherung.
MfG, at
Hi,
Anwärts- und Aufwärtskompatibilität
Erstere war mir bislang nicht geläufig. Vielen Dank für diese Bereicherung.
Hat, gemäß Beschluß des W3Cs vom 1.4.2009, die "Seitwärtskompatibilität" abgelöst.
Das war ja auch schon lang überfällig ...
Gruß, Cybaer
Hallo.
Anwärts- und Aufwärtskompatibilität
Erstere war mir bislang nicht geläufig. Vielen Dank für diese Bereicherung.Hat, gemäß Beschluß des W3Cs vom 1.4.2009, die "Seitwärtskompatibilität" abgelöst.
Das war ja auch schon lang überfällig ...
Ach ja, richtig. Anwärts statt seitwärts, ich erinnere mich. Das ist ja seit diesem Frühling Bestandteil der Rabbit Approach Markup Language, kurz RAML.
MfG, at
Hallo,
Sollte ich wenn ich ein Projekt aufziehe weiterhin XHTML 1.0 Trans nehmen oder kann ich schon auf HTML 5 zählen? Wie sieht es da mit der Browserkompatiblität aus und Was ist mit XHTML 5? gibt es das?
(X)HTML 5 ist bislang nur in kleinen Stücken in Browsern implementiert. Es geht da schließlich nicht nur um einzelne neue Elemente, sondern um Javascript-APIs und größere neuere Modelle. Strukturelle Elemente sind in dem Sinne kein Aufwand und „funktionieren“. Größtenteils.
Der Internet Explorer hat Probleme, ihm unbekannte Elemente zu rendern. Allerdings gibt es eine Merkwürdigkeit: erstellt man solche unbekannten Elemente mittels in Javascript mittels document.createElement("article"); dann kann der IE diese Elemente nutzen und rendern. In allem Browsern gilt, dass die neuen Elemente noch keine Default-Darstellungsregeln im Browser-Stylesheet besitzen. display:block; und vernünftige Regeln für den margin sind also notwendig.
Elemente, die nicht nur strukturieren, sondern, die auch ein spezielles Rendering und Handling besitzen wie <video>, <canvas> oder <datagrid> sind nicht so leicht browser-übergreifend zu nutzen. Teilweise gibt es Skript-Lösungen, die mit versucen Funktionalität in minderen Browsern wie dem IE nachzubilden, teilweise (schon fast absurde) Verschachtelungen von Fallback-Varianten wie hier für <video>.
Ich würde Dir raten, wenn Du unbedingt willst, die strukturierenden Elemente mit obiger Starthilfe zu nutzen, dazu noch den Doctype und <meta charset="...">. Was darüber hinaus geht, ist browserübergreifend noch nicht wirklich nutzbar, höchstens, wenn man sehr genau weiß, was man tut. Die in der HTML 5 Galerie verlinkten Webseiten beschränken sich meist auch nur auf diese kleine Teilmenge.
•••
XHTML 5 ist HTML 5 nur in XML formuliert, mehr nicht. Es gibt aber einen großen Unterschied zu XHTML 1.x; es soll immer als XML versendet und verarbeitet werden. Das soll heissen, es wird mit dem MIME-Typ „application/xhtml+xml“ versandt, der Browser wirft darauf hin seinen XML-Parser an und verarbeitet es als XML, nicht mit dem SGML-ähnlichen HTML-Parser. Letzterer wird verwandt, wenn eine Resource mit dem MIME-Typ „text/html“ versendet wird. Das Problem ist wieder einmal der Internet Explorer; dieser verarbeitet „application/xhtml+xml“-Dokumente nicht als Webseite sondern als potentiellen Download. In der Realität ist „application/xhtml+xml“ also leider nicht nutzbar. Dazu gibt es das Problem, dass als XML verarbeitete XHTML-Dokumente bei nur einem (Flüchtigkeits)-Fehler im Browser die Verarbeitung abbrechen. Das will man oft nicht. Effektiv ist XHTML im Web heutzutage kein wirkliches XHTML sondern nur HTML mit XHTML-Syntax.
XHTML-Syntax ist jedoch in HTML-5-Syntax zu Teilen erlaubt, Dinge wie <br /> und ähnliches. Dies ist dafür da, dass die derzeit fälschlich mit „text/html“ versendeten XHTML-Dokumente auch als richtiges HTML 5 gelten - man will nicht einen Großteil des Webs vor den Kopf stoßen. Die Frage für den Webseiten-Ersteller ist nun, ob man trotzdem XHTML-Syntax verwenden, das Dokument aber als „text/html“ versenden will. Dazu gibt es zwei Gedankengänge. Der eine wird hier im Forum von molily ausgedrückt: Man kann das X(HTML)-Dokument in der Erstellung oder in der Erarbeitung auf seine Qualität kontrollieren, z.B. durch Validierung mit XML Schema, das nach sehr viel mehr testen kann, als der normale HTML-4-Validator. Dazu kommt damit die Einhaltung von strengeren Syntax-Standards. Für ihn ist also nicht die Übertragung und die Webseite im Browser relevant, sondern das auch sehr wichtige „davor“. (Hier schildet molily die Beweggründe ausführlicher; hier gibt es ein Beispiel.) Die andere Position, die zum Teil ich auch einnehme ist, dass das nicht unbedingt so wichtig ist. Zum einen, weil ein guter Web-Entwickler Qualitätsstandards automatisch einhält, schon allein, weil ihr im Laufe der Jahre Postel's Law verinnerlicht hat. Zum anderen, weil der HMTL-5-Validator immer besser wird. Aber beides ist eine Einschätzung, die aus der persönlichen Erfahrung kommt: molily hat nach eigener Aussage ständig mit diversen HTML-Code aus den unterschiedlichsten Quellen zu tun; ich weniger. Dass da ein Bedürfnis nach automatischer Qualitätssicherung besteht, ist sehr leicht nachzuvollziehen.
Die serverseitige Verarbeitung und Qualitätskontrolle ist der wesentliche Punkt, wo man einen Vorteil durch das XML in XHTML erhält. Wenn man das nicht hat, braucht man auch nicht unbedingt XHTML zu nutzen. Aber andererseits hat man dadurch auch keine Nachteile.
•••
(Und nebenbei würde ich auch dringends von @target abraten. Ich bin eigentlich recht entspannt, bei Webseiten, die anders sind, als ich sie in einer perfekten Welt machen wollen würde. Das target-Attribut ist jedoch nur nervig; dies, weil es nicht nur in die Webseite im Viewport eingreift, sondern in meine private Organisation von Tabs und Fenstern. Und da gehören Aktionen einer Webseite m.E. nicht hin.)
Tim
Zum einen, weil ein guter Web-Entwickler Qualitätsstandards automatisch einhält, schon allein, weil ihr im Laufe der Jahre Postel's Law verinnerlicht hat.
Ja, ein guter Webentwickler tut das. Diesen Qualitätsstandard hat ironischerweise der kritikwürdige XHTML-Hype etabliert, in dessen Zuge Webstandards-Verfechter allen Webautoren valides XHTML 1 auf die Nase gebunden haben (1, 2).
Doch diese Regeln bleiben nicht für immer und ewig im kollektiven Gedächtnis, wenn sie nicht aktualisiert werden. Gerade erleben wir den entsprechenden Backlash. XHTML wird zu Grabe getragen und prominente Stellen, die sich witzigerweise Quality Assurance und Maintainance auf die Fahnen geschrieben haben, empfehlen, doch bitte alle weglassbaren End-Tags wegzulassen. Dadurch würde angeblich alles einfacher: »Leaving out optional tags will make your pages a lot smaller and easier to understand.« LOL.
Zum anderen, weil der HMTL-5-Validator immer besser wird.
Der HTML-5-Validator ist m.W. Feature-complete. Er wird sein Leben lang dabei bleiben, schlechte Tag-Soup gutzuheißen, weil HTML 5 kompatibel mit HTML 4 ist. Zwar nicht hinsichtlich der grausigsten SGML-Features wie SHORTTAG, aber z.B. hinsichtlich der vielen optionalen Tags:
<!doctype html>
<title></title>
<p>absatz
<p><select>
<option>a
<option>b
</select>
<dl>
<dt>term
<dd>definition
</dl>
<ol>
<li>eins
<li>zwei
</ol>
<table>
<thead>
<tr><th>bla<td>bla
<tbody>
<tr><th>bla<td>bla
<tfoot>
<tr><th>bla<td>bla
</table>
wird bis ans Ende der Tage valides HTML 5 sein. Da kann man keine andere Qualität kontrollieren, als eben die der HTML-5-Serialisierung. Da kann man nicht zwischen absichtlich weggelassenem oder versehentlich vergessenem End-Tag unterscheiden.
Wenn man sich nicht mit dem abstrakten Dokumentmodell beschäftigt hat, welches diese Serialisierung nur konkret festhält, versteht man nicht einmal, was hier abgeht. Die HTML-5-Spezifikation definiert in erster Linie dieses Dokumentmodell und umso wichtiger ist es, dass Webautoren das verstehen und Erkenntnisse für eine gute Markup-Repräsentation ziehen. Laxheiten wie das Weglassen von manchen Tags führt m.E. dazu, dass man sich von diesem Verständnis eher entfernt, weil die Verschachtelung und der entstehende Knotenbaum nur unter Kenntnis der Parsing-Regeln aus dem Quellcode ersichtlich wird.
Es ginge höchstens, auch bei HTML 5 ein duales Modell zu etablieren: Auslieferung in der HTML-5-Serialisierung, aber XHTML-5-artige Syntax. Dann braucht man nur den HTML-5-Doctype entfernen und kann den Code als XHTML 5 mit Relax NG und Schematron validieren. Da das aber niemand tun wird und kein Tool das anbieten wird, werden Qualitätsstandards, die mit HTML-kompatiblem XHTML 1 Einzug hielten, nach und nach vergehen. Wo kein Validator mehr strikte und konsequente Maßstäbe anlegt, ist auch kein Webautor, der sie verinnerlicht.
Bei der Software-Entwicklung ist es nicht anders: Wo mir ein Compiler keine Warnungen ausgibt und kein Lint existiert, da sinkt die Code-Qualität, so sehr »guter Coding-Stil« im Lehrbuch steht. Wobei sich selbst die Lehrbücher gerade ändern: Da steht dann auch nicht mehr drin, dass man Elemente immer mit End-Tags schließen sollte - ist ja viel einfacher, performanter, wartbarer usw., sie wegzulassen.
Postel's Law war einmal. Dafür stand m.M.n. XHTML 1 (überprüfbar »conservative« auf der Autorenseite, »liberal« auf der Verarbeitungsseite). XHTML 5 hingegen kann nur in besonderen, geschlossenen Umgebungen eingesetzt werden.
Mathias
@@molily:
nuqneH
[…] empfehlen, doch bitte alle weglassbaren End-Tags wegzulassen. Dadurch würde angeblich alles einfacher: »Leaving out optional tags will make your pages a lot smaller and easier to understand.« LOL.
(Nicht, dass hier der Eindruck entsteht, ich würde alles nachplappern, was Jens Meiert so von sich gibt. ;-))
Qapla'
Der HTML-5-Validator ist m.W. Feature-complete. Er wird sein Leben lang dabei bleiben, schlechte Tag-Soup gutzuheißen, weil HTML 5 kompatibel mit HTML 4 ist. Zwar nicht hinsichtlich der grausigsten SGML-Features wie SHORTTAG, aber z.B. hinsichtlich der vielen optionalen Tags [..]
Da kann man nicht zwischen absichtlich weggelassenem oder versehentlich vergessenem End-Tag unterscheiden.
Effektiv wird ein versehentlich weggelassenes End-Tag doch nur relevant, wenn es nicht optional ist – die einzig gemessene Qualität ist dann die Qualität der geringeren kognitiven Last für Quelltext-Entwickler, nicht die technische Unwägbarkeit. Denn die existiert im Prinzip nicht; ist doch die Optionalität und die Selbstschließung von Tags definiert, es gibt ein Verarbeitungsmodell dafür. Zugegeben, ein sehr komplexes Verarbeitungsmodell, aber es gibt eines. Ich tue mich dann schwer, das noch als Tag Soup zu bezeichnen; ich erkenne aber wohl an, dass das ein wesentliches Problem des Authoring ist.
Es ginge höchstens, auch bei HTML 5 ein duales Modell zu etablieren: Auslieferung in der HTML-5-Serialisierung, aber XHTML-5-artige Syntax. Dann braucht man nur den HTML-5-Doctype entfernen und kann den Code als XHTML 5 mit Relax NG und Schematron validieren. Da das aber niemand tun wird und kein Tool das anbieten wird [..]
Soweit ich weiß, braucht man noch nicht mal den Doctype zu entfernen. Im Prinzip kann man also ein Anhang-C-artiges Modell nutzen, XHTML-5-Syntax und Auslieferung als text/html. Nebenbei: Es gibt Tools, die XHTML-Syntax nutzen und HTML-Syntax ausspucken. Das von mir sehr gemochte Template-System Genshi arbeitet z.B. nicht auf Text-Ebene sondern auf einer logischen Markup-Stream-Ebene. Dort könnte man z.B Templates in XHTML-5-Syntax nutzen, die in HTML-5-Syntax serialisiert werden. Ich meine, sogar mal einen HTML-5-Serialisierer für Genshi gesehen zu haben, der sämtliche Optionalität ausnutzt, also z.B. <p class=foo>bar<p class=baz>-artigen Quellcode ausspuckt. Das wäre aber eine extremere Lösung.
Postel's Law war einmal. Dafür stand m.M.n. XHTML 1 (überprüfbar »conservative« auf der Autorenseite, »liberal« auf der Verarbeitungsseite).
Häh? Die drakonische Fehlerverarbeitung von XML ist doch ein wesentlicher Verstoß gegen das Gebot der Liberalität der Verarbeitung. Oder redest Du von Anhang-C-XHTML?
Effektiv wird ein versehentlich weggelassenes End-Tag doch nur relevant, wenn es nicht optional ist – die einzig gemessene Qualität ist dann die Qualität der geringeren kognitiven Last für Quelltext-Entwickler, nicht die technische Unwägbarkeit. Denn die existiert im Prinzip nicht
Wenn ich von Qualität spreche, meine ich weniger, dass der Code »funzt«. Die Verarbeitung im Browser ist hier theoretisch eindeutig und m.W. auch praktisch einheitlich. Mit der Verbreitung von HTML-5-Parser, die keinen Spielraum lassen, sondern fast alles determiniert ist, wird ein gewisses Markup noch zuverlässiger in einen bestimmten DOM-Baum geparst.
Qualitätsstandards sind für mich vielmehr selbst auferlegte Best Practises, die über das hinaus gehen, was zwingend technisch notwendig. D.h. etwa, die erlaubten Ausnahmen und Laxheiten des jeweiligen Standards nicht zu nutzen. Bei so ziemlich allem HTML-Code, den ich zu Gesicht bekomme, würde das Weglassen von optionalen End-Tags die Übersicht verschlechtern und damit die Entwicklung erschweren. Diese Inkonsistenz würde nach und nach zu Verschachtelungsfehlern führen.
Ganz zu schweigen davon, dass nicht alle, die am Code arbeiten, unterscheiden können, ob das Weglassen eines End-Tags Absicht oder Fehler ist. Aber ich sehe auch nicht ein, warum sie es wissen müssten - und warum Fachautoren plötzlich die Kurzschreibung von HTML wiederentdecken. Die Grundregel, alle nicht-leeren Tags zu schließen, ist viel einfacher, und der Aufwand, ihn hinzuschreiben, viel geringer als der, ihn bewusst wegzulassen und damit unklares Markup zu schreiben.
Soweit ich weiß, braucht man noch nicht mal den Doctype zu entfernen.
Tatsächlich. Ich dachte immer, <!DOCTYPE html> schluckt ein XML-Parser nicht. (Ein validierender vielleicht nicht - aber gegen XML-DTDs wird man XHTML 5 ohnehin nicht validieren.)
Im Prinzip kann man also ein Anhang-C-artiges Modell nutzen, XHTML-5-Syntax und Auslieferung als text/html.
Ja, darauf wollte ich hinaus. Allerdings müsste man einen Validator dazu bringen, das auch als XHTML 5 zu validieren, selbst wenn der MIME-Typ HTML 5 nahelegt.
Nebenbei: Es gibt Tools, die XHTML-Syntax nutzen und HTML-Syntax ausspucken. Das von mir sehr gemochte Template-System Genshi arbeitet z.B. nicht auf Text-Ebene sondern auf einer logischen Markup-Stream-Ebene.
Sehr interessant, das kannte ich noch nicht. (Wir arbeiten auch eher mit Ruby.)
Die drakonische Fehlerverarbeitung von XML ist doch ein wesentlicher Verstoß gegen das Gebot der Liberalität der Verarbeitung. Oder redest Du von Anhang-C-XHTML?
Ja - der Autor hat nicht nur die Möglichkeit, das Dokument als XML zu verarbeiten, er behält auch volle Kontrolle darüber, wann das Dokument drakonisch behandelt wird, z.B. bei der Validierung.
Mathias
@@molily:
nuqneH
Tatsächlich. Ich dachte immer, <!DOCTYPE html> schluckt ein XML-Parser nicht.
Warum? Es ist doch korrektes XML. [XML10]
Die DOCTYPE-Angabe muss doch auch in XHTML erlaubt sein; es ist die Stelle, eigene Enitities zu definieren. Wenn XHTML 5 dies verbieten würde, könnte man es kaum als XML-Anwendung bezeichnen.
Qapla'
Es ist doch korrektes XML. [XML10]
Ja, ist mir dann auch aufgefallen - ich wusste nicht, dass ein »leerer« Doctype ohne Public bzw. System Identifier möglich ist. Danke für den Link.
Mathias
@@molily:
nuqneH
ich wusste nicht, dass ein »leerer« Doctype ohne Public bzw. System Identifier möglich ist.
Wird in RDF/XML auch gern benutzt. (Für RDF gibt’s keine DTD, also auch keine Public bzw. System Identifier.) Siehe [RDF-PRIMER], Übergang von Beispiel 7 zu Beispiel 8.
Qapla'
