nicht angemeldet
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
molily
Hallo,
habe zuvor immer HTML 4.1 strict verwendet. Nun bevor ich mich an ein neues Projektchen ranmachen wollte, habe ich mal etwas rumgelesen wegen XHTML und XML etc.
Nur bin ich jetzt leicht verwirrt. Ist die Verwendung von XHTML im WWW sinnvoll?
Oder sollte man gleich mit eigener DTD XML und XSL arbeiten?
Oder wäre eine gute Lösung XHTML1.0 strict und css Sytlesheets oder wäre es dann besser bei HTML 4.1 strict zu bleiben.
Ich sehe einfach den Wald vor lauter Bäumen nichtmehr und weiß nichtmehr, was jetzt die non-plus-ultra-korinthenkacker-lösung fürs www ist.
Grüßle
Nur bin ich jetzt leicht verwirrt. Ist die Verwendung von XHTML im WWW sinnvoll?
Oder sollte man gleich mit eigener DTD XML und XSL arbeiten?Oder wäre eine gute Lösung XHTML1.0 strict und css Sytlesheets oder wäre es dann besser bei HTML 4.1 strict zu bleiben.
Ich sehe einfach den Wald vor lauter Bäumen nichtmehr und weiß nichtmehr, was jetzt die non-plus-ultra-korinthenkacker-lösung fürs www ist.
Je Korinthenkacker desto XML. :-D
Aber im ernst. Das ist mehr eine Glaubensfrage als irgendwas anderes. Ich persönlich habe mich in meiner mir eigenen Mischung aus Pragma- und Fanatismus auf XHTML 1.0 strict festgelegt, weil:
- Bei HTML sind schließende Tags optional, was ich gar nicht mag.
- XHTML ist echtes XML (Integrierbarkeit)
- Bei XHTML 1.1 und dem IE gibt's Konfusion mit dem Mimetype und der XML-Ansicht
- XSL-Unterstützung ist noch zu sehr vom Browser abhängig
- Selbstgebautes XML (ohne XSL) kennt der Browser nicht und kann er nicht interpretieren (war glaub ich klar)
- Namespace-Unterstützung ist in den Browsern noch nicht besonders
Schöne Grüße
Andreas
- Selbstgebautes XML (ohne XSL) kennt der Browser nicht und kann er nicht interpretieren (war glaub ich klar)
- Namespace-Unterstützung ist in den Browsern noch nicht besonders
Hi,
Danke für deine Antwort.
Und was ist mit XML mit XSL?
Namespace? Ich steh grad auf dem schlauch, was es damit auf sich hat ...
Gruß
Und was ist mit XML mit XSL?
Clientseitiges XSL funktioniert nicht einheitlich in den Browsern. Serverseitig kannst Du natürlich mit XSL machen was Du willst. Letzteres spielt für Dich nur eine Rolle, wenn Du die Daten in einem CMS oder so halten willst, und dann daraus per XSLT den anzuzeigenden Code erzeugst.
XML würde nur mit XSL sinn machen (Browser *verstehen* ja kein XML, sondern nur XHTML). Wenn jetzt XSL nicht gut funktioniert, stirbt damit auch XML. Außerdem ist das Umwandeln von XML per XSL auf Browserseite verhältnismäßig aufwendig und kann nochmal wertvolle Millisekunden beim Seitenaufbau kosten.
Namespace? Ich steh grad auf dem schlauch, was es damit auf sich hat ...
Namespaces ermöglichen das parallele Verwenden mehrerer XML-Definitionen in ein und demselben XML-Dokument. Immer wenn Du Tags siehst, die einen Doppelpunkt im Namen oder in Attributen haben, sind Namespaces im Spiel. Beim Schreiben von XSL-Transformationen verwendest Du z.B. auch den xslt-Namespace, um die "Anweisungen" zu schreiben.
Brauchst Du wahrscheinlich erstmal nicht. Vor allem nicht beim an den Browser ausgelieferten XML/XHTML (da viele Browser ja wie gesagt nicht ordentlich damit können).
Nimm XHTML. Da hast Du dann für die Zukunft alle Möglichkeiten, ohne auf aktuelle Bequemlichkeiten des HTML verzichten zu müssen (außer vielleicht auf Frames...).
Hello out there!
XML würde nur mit XSL sinn machen
Oder mit CSS. [https://forum.selfhtml.org/?t=162666&m=1058726]
Außerdem ist das Umwandeln von XML per XSL auf Browserseite verhältnismäßig aufwendig
Serverseitig ist der Aufwand nicht geringer.
Immer wenn Du Tags siehst, die einen Doppelpunkt im Namen oder in Attributen haben, sind Namespaces im Spiel.
Nein, nicht zwangläufig.
<foo:bar/>
ist wohlgeformtes XML, ohne das irgendwelche Namensräume im Spiel wären; es besteht aus dem Element namens 'foo:bar' (und nicht etwa aus dem Element 'bar' aus dem Namensraum 'foo').
Nimm XHTML. Da hast Du dann für die Zukunft alle Möglichkeiten, ohne auf aktuelle Bequemlichkeiten des HTML verzichten zu müssen (außer vielleicht auf Frames...).
In XHTML 1.0 könnte man Frames genauso verwenden wie in HTML 4.01.
Frames mögen eine Bequemlichkeit für den Webseitenautor sein (obwohl derverseitige Includes noch bequemer sind).
Der Verzicht auf Frames hat andere Gründe: deren Probleme für Nutzer.
See ya up the road,
Gunnar
Oder mit CSS. [https://forum.selfhtml.org/?t=162666&m=1058726]
Nö (siehe meine Antwort). ;-)
Außerdem ist das Umwandeln von XML per XSL auf Browserseite verhältnismäßig aufwendig
Serverseitig ist der Aufwand nicht geringer.
Ja, aber will man das jedem Smartphone zumuten? Serverseitig wird der Aufwand z.B. durch Caching. durchaus geringer.
Immer wenn Du Tags siehst, die einen Doppelpunkt im Namen oder in Attributen haben, sind Namespaces im Spiel.
Nein, nicht zwangläufig.
<foo:bar/>ist wohlgeformtes XML, ohne das irgendwelche Namensräume im Spiel wären; es besteht aus dem Element namens 'foo:bar' (und nicht etwa aus dem Element 'bar' aus dem Namensraum 'foo').
Ah, ok. Wollte nur einen Hinweis geben, dass der orig. Poster vielleicht selbst schonmal über Namespaces gestoßen ist und es nicht gemerkt hat.
Der Verzicht auf Frames hat andere Gründe: deren Probleme für Nutzer.
Auf diese Diskussion lasse ich mich nicht ein. ;-) Stimme dir prinzipiell zu, aber z.B. den Einsatz von iFrames muss man von Einzelfall zu Einzelfall entscheiden.
Hallo,
danke für deine Antowrt.
Clientseitiges XSL funktioniert nicht einheitlich in den Browsern. Serverseitig kannst Du natürlich mit XSL machen was Du willst. Letzteres spielt für Dich nur eine Rolle, wenn Du die Daten in einem CMS oder so halten willst, und dann daraus per XSLT den anzuzeigenden Code erzeugst.
Wie muss ich mir das vorstellen?
Daten im CMS werde vom XSLT "umgewandelt"?
Gruß
Moin,
Wie muss ich mir das vorstellen?
Daten im CMS werde vom XSLT "umgewandelt"?
Die Daten könnten z.B. vom CMS als XML (aka eigene XML-Sprache) verarbeitet werden. Diese Daten werden dann einem XSLT-Prozessor übergeben. Dieser braucht noch ein XSL-Stylesheet das ist wiederum eine XML-Sprache, mit der man beschreibt, wie man eine XML-Sprache in eine andere oder ein anderes Text-basiertes Format wandelt.
Daraus baut der XSLT-Prozessor dann die HTML-Ausgabe, die an den Browser gesendet wird. Apache Cocoon arbeit meines Wissens nach diesem Prinzip.
Man kann damit sehr nette Sachen machen. So kannst du z.B. aus ein und denselben Daten HTML, PDF (mit ein wenig Hilfe), LaTeX, Dokumente im OpenOffice-Format etc. erzeugen.
Es gibt übrigens bereits eine XML-Sprache bei der das gemacht wird: Docbook. Das eine XML-Sprache, die dafür gedacht ist Dokumente - in erster Dokumentationen zu Software - zu schreiben. Das ganze ist erst mal unabhängig vom Ausgabeformat. Erst mit einem XSL-Stylesheet wird dann die letztendliche Ausgabe erzeugt.
Gruß
Stareagle
Hallo,
vielen Dank. So langsam ergibt das ganze für mich ein wages Bild.
Also wenn ich dann diese XML-Daten habe, kann ich sie je nach XSLT eben in HTML oder PDF etc. "überführen".
Soweit so gut. Und wie sieht das jetztin der Praxis aus?
Clientseitig - Serverseitig? Was gibt es für Vorraussetzungen/Einschränkungen Browserprobleme?
Gruß
Hello out there!
- Selbstgebautes XML (ohne XSL) kennt der Browser nicht und kann er nicht interpretieren (war glaub ich klar)
Gar nicht klar, denn Browser stellen mit CSS formatiertes XML durchaus dar.
Allerdings gibt es im Gegensatz zu (X)HTML-Dokumenten kein Default-Browser-Stylesheet, so dass man als Autor wirklich alle Formatierungen selbst angeben muss.
See ya up the road,
Gunnar
Hallo,
hätte es dann nicht einen Immensen Vorteil, das so zu praktizieren?
Man hat seine eigene individuelle Auswahl an Elementen, die man mit der DTD definiert und ist außerdem gezwungen alle angaben zu setzen, was Fehlinterpretationen ausshcließt?
Gruß
Hello out there!
hätte es dann nicht einen Immensen Vorteil, das so zu praktizieren?
Man hat seine eigene individuelle Auswahl an Elementen,
Welchen Vorteil hätten eigene Elemente zur Auszeichnung einer Webseite gegenüber den HTML-Elementen, die zur Beschreibung der Struktur einer Webseite vorgesehen sind?
(Es sei denn, es ist eine semantische Auszeichnung des Dokumentinhalts gewünscht, um die Daten auch anderweitig auswerten zu können.)
die man mit der DTD definiert
Oder mit XML Schema. Oder auch gar nicht.
und ist außerdem gezwungen alle angaben zu setzen
Das ergibt ein recht umfangreiches Stylesheet. Und viel Traffic. [https://forum.selfhtml.org/?t=162652&m=1058749]
was Fehlinterpretationen ausshcließt?
Mitnichten. Die Fehlinterpretationen entstehen ja nicht durch unterschiedliche Default-Browser-Stylesheets, sondern durch fehlerhafte Implementierung der Interpretation von CSS-Regeln. Mit eigenem XML wäre diesbezüglich gar nichts gewonnen.
See ya up the road,
Gunnar
Hallo,
aber der Vorteil mit der erhöten Austauschbarkeit bleibt?!
Gestelltes Beispielt: man bietet auf seiner Seite kochrezepte an, würde man dafür eigene Elemente verwenden wie <gericht> <zutaten> etc könnte man sie durch Software oder änhliches doch viel angenehmer auslesen oder?
Aber würden solche eigenen Elemente und DTD überhaupt brauchbar im WWW funktionieren?
Gruß
Hello out there!
Gestelltes Beispielt: man bietet auf seiner Seite kochrezepte an, würde man dafür eigene Elemente verwenden wie <gericht> <zutaten> etc könnte man sie durch Software oder änhliches doch viel angenehmer auslesen oder?
Sagte ich das nicht gerade?
(Es sei denn, es ist eine semantische Auszeichnung des Dokumentinhalts gewünscht, um die Daten auch anderweitig auswerten zu können.)
Aber würden solche eigenen Elemente und DTD überhaupt brauchbar im WWW funktionieren?
Ob der IE inszwischen XLink beherrscht, weiß ich nicht.
See ya up the road,
Gunnar
Ob der IE inszwischen XLink beherrscht, weiß ich nicht.
Aber es handelt sich dabei mal wieder nur um den achsotollen IE?
Gruß
Hallo,
Aber würden solche eigenen Elemente und DTD überhaupt brauchbar im WWW funktionieren?
Als XML/XSL vielleicht schon, aber auch nicht mit allen Browsern gleich
nutzbar.
Dieser Beispielkatalog zu XML für alle? wird bei FireFox, IE 5.5 bis 7
und Safari 3 angezeigt, aber in der Version und ohne DHTML offenbar nicht ganz
mit Opera, der meldet immerhin "XSLT processing failed!".
Grüsse
Cyx23
Man hat seine eigene individuelle Auswahl an Elementen, die man mit der DTD definiert und ist außerdem gezwungen alle angaben zu setzen, was Fehlinterpretationen ausshcließt?
Mit CSS kann man das Verhalten nicht nachbilden (Links würden z.B. nicht funktionieren). Siehe auch meine Antwort zum Vorposter.
Man ist auch bei XHTML und 'gar HTML gezwungen, alle Angaben korrekt zu setzen. Denn für diese Sprachen gibt es schon DTDs (DTDs sind nicht auf selbst erstelltes XML und noch nichtmal auf XML allgemein beschränkt. Auch die HTML-Versionen haben jew. eine DTD die alles genau vorschreibt.)
- Selbstgebautes XML (ohne XSL) kennt der Browser nicht und kann er nicht interpretieren (war glaub ich klar)
Gar nicht klar, denn Browser stellen mit CSS formatiertes XML durchaus dar.
Offenbar ein Missverständnis. Ich meinte, dass der Browser in frei definiertem XML die Bedeutung von Anker-Elementen etc. nicht kennt (interpretieren != darstellen). Man kann auch noch so schön stylen, aber das *Verhalten* kann man dem Browser mit CSS nicht beibringen.
Ich weiß, es gibt CSS behaviours, aber die sind ja noch nicht wirklich weit genug unterstützt, um in allen Browsern das Verhalten der funktionalen Elemente nachzubilden.
Tschö
Andreas
Hello out there!
Offenbar ein Missverständnis. Ich meinte, dass der Browser in frei definiertem XML die Bedeutung von Anker-Elementen etc. nicht kennt
Es gibt XLink. [</archiv/2005/8/t112735/#m714354>]
See ya up the road,
Gunnar
Yerf!
Nur bin ich jetzt leicht verwirrt. Ist die Verwendung von XHTML im WWW sinnvoll?
Das wird hier in letzter Zeit immer mal wieder heiß diskutiert... Meiner Meinung nach kann XHTML sehr sinnvoll sein, wenn man die Vorteile zu nutzen weiß.
Oder sollte man gleich mit eigener DTD XML und XSL arbeiten?
Wenn du Webseiten erstellen wills, solltest du auch die Sprache dafür verwenden: (X)HTML
Oder wäre eine gute Lösung XHTML1.0 strict und css Sytlesheets oder wäre es dann besser bei HTML 4.1 strict zu bleiben.
Kommt darauf an. XHTML bietet mehr Möglichkeiten, wie z.B. die Verarbeitung als XML, auch die strengere Syntax hat Vorteile (bessere fehlervermeidung). Wenn man diese nicht benötigt, hat man mit HTML allerdings auch keine Nachteile, da auf Browserseite derzeit XHTML noch nicht sein volles Potential ausspielen kann: die Einbettung anderer XML-Formate (und schuld ist mal weider die Innovationsbremse aus Redmond...).
Ich sehe einfach den Wald vor lauter Bäumen nichtmehr und weiß nichtmehr, was jetzt die non-plus-ultra-korinthenkacker-lösung fürs www ist.
Für den Benutzer ists derzeit letztlich egal, aber als Seitenauthor kann XHTML einiges erleichtern/verbessern.
Außerdem besteht bei mir immernoch die leise Hoffnung, dass ein IE8 auch mit XHTML+XML umgehen kann.
Gruß,
Harlequin
Hallo,
dnkae für die Antowrt.
Was sind denn so die markanten Vorteile von XHTML deiner Meinung nach?
Ja so kennen wir das von Redmond ;-) wobei ich eh kein Anwendungsgebiet hätte um andere XML-Formate einzubetten ...
Gruß
Yerf!
Was sind denn so die markanten Vorteile von XHTML deiner Meinung nach?
Eben z.B. die Verarbeitung als XML. Ich stell mir die Programmierung mit einem serverseitigen DOM doch relativ angenehm vor. Auf jede Fall besser als diese Echo-Wüsten, die man häufig in PHP-Skripten sieht ;-)
Hätte auch den Vorteil, dass die clientseitige Verarbeitung im Javascript kaum von der Serverseite abweicht und AJAX-Anwendungen nahtlos miteinander sich austauschen können. Ich denke auch, dass sich mit XSLT einiges anstellen lässt.
Ja so kennen wir das von Redmond ;-) wobei ich eh kein Anwendungsgebiet hätte um andere XML-Formate einzubetten ...
SVG-Grafiken direkt in die Seite einfügen, z.B. für Verziehrungen. Oder auch MathML für wissenschaftliche Texte.
Gruß,
Harlequin
Moin!
Was sind denn so die markanten Vorteile von XHTML deiner Meinung nach?
Eben z.B. die Verarbeitung als XML. Ich stell mir die Programmierung mit einem serverseitigen DOM doch relativ angenehm vor. Auf jede Fall besser als diese Echo-Wüsten, die man häufig in PHP-Skripten sieht ;-)
Wunschdenken, dass du wohl kaum durch eigene Praxiserfahrung verifizieren oder falsifizieren kannst, oder?
Serverseitiges DOM ist genau dann sinnvoll, wenn man sowas tatsächlich als Struktur schon aus irgendeinem anderen Grund vorliegen hat. Ist mir allerdings noch nie über den Weg gelaufen.
Echo-Wüsten kenne ich. Die vermeidet man natürlich. Eine vernünftige Template-Engine vereinfacht sehr viel. Aber schlussendlich bestehen auch Templates eben aus HTML- oder XHTML-Quelltext. Aus dieser Sichtweise heraus gibts keinen Unterschied, und kein Dialekt kann punkten.
Hätte auch den Vorteil, dass die clientseitige Verarbeitung im Javascript kaum von der Serverseite abweicht und AJAX-Anwendungen nahtlos miteinander sich austauschen können. Ich denke auch, dass sich mit XSLT einiges anstellen lässt.
Du unterschlägst gnädig die auch heutzutage immer noch notwendigen Anpassungen für unerwartete Browserbugs und -unzulänglichkeiten.
Jedenfalls fällt die von dir dargestellte Wunderwelt keinesfalls von alleine aus der Tüte - um dahin zu kommen ist vermutlich extrem viel Arbeit notwendig, die im Normalfall nicht gerechtfertigt ist, weil der "einfache" Weg deutlich vorteilhafter ist.
- Sven Rautenberg
Yerf!
Eben z.B. die Verarbeitung als XML. Ich stell mir die Programmierung mit einem serverseitigen DOM doch relativ angenehm vor. Auf jede Fall besser als diese Echo-Wüsten, die man häufig in PHP-Skripten sieht ;-)
Wunschdenken, dass du wohl kaum durch eigene Praxiserfahrung verifizieren oder falsifizieren kannst, oder?
Meine Erfahrungen mit DOM-Manipulation beziehen sich bisher nur auf die Clientseite. Allerdings macht das die ganze Zeit schon "Lust auf mehr". Die Zeit das zu vertiefen habe ich bisher aber leider noch nicht gefunden. (Ich suche vor allem immer noch nach einer vernünftigen Einführung über die Administration des Tomcat. Ich hab ihn zwar inzwischen ans Laufen bekommen, aber die Konfiguration ist mir immernoch ein Buch mit 7 Siegeln...)
Serverseitiges DOM ist genau dann sinnvoll, wenn man sowas tatsächlich als Struktur schon aus irgendeinem anderen Grund vorliegen hat. Ist mir allerdings noch nie über den Weg gelaufen.
Ich stelle mir eine eigene Template-Engin mit XML-Fragmenten vor. Sollte sich eigentlich relativ einfach und schnell lösen lassen.
Echo-Wüsten kenne ich. Die vermeidet man natürlich. Eine vernünftige Template-Engine vereinfacht sehr viel. Aber schlussendlich bestehen auch Templates eben aus HTML- oder XHTML-Quelltext. Aus dieser Sichtweise heraus gibts keinen Unterschied, und kein Dialekt kann punkten.
Man kann natürlich eine fertige Template-Engine nehmen. Aber das DOM bietet eigentlich schon die Basisfunktionalität und wenn man die selbst erweitert bleibt man flexibler.
Du unterschlägst gnädig die auch heutzutage immer noch notwendigen Anpassungen für unerwartete Browserbugs und -unzulänglichkeiten.
Erwischt! Die versuch ich immer so schnell wie möglich wieder zu verdrängen ;-)
Jedenfalls fällt die von dir dargestellte Wunderwelt keinesfalls von alleine aus der Tüte - um dahin zu kommen ist vermutlich extrem viel Arbeit notwendig, die im Normalfall nicht gerechtfertigt ist, weil der "einfache" Weg deutlich vorteilhafter ist.
Der "einfache" Weg bedeutet aber in diesem Fall Fremdsoftware (Template-Engin) zu verwenden, oder? Hier sehe ich den Nachteil, dass die nicht wirklich standardisiert sind, oder gibt es da etwas für verschiedene Plattformen (PHP/Java usw.)? Ansonsten müsste man seine Ausgabe als reinen Text betrachten und das sehe ich auf keinen Fall als einfacher an, als mit DOM zu arbeiten.
Gruß,
Harlequin
Moin!
Echo-Wüsten kenne ich. Die vermeidet man natürlich. Eine vernünftige Template-Engine vereinfacht sehr viel. Aber schlussendlich bestehen auch Templates eben aus HTML- oder XHTML-Quelltext. Aus dieser Sichtweise heraus gibts keinen Unterschied, und kein Dialekt kann punkten.
Man kann natürlich eine fertige Template-Engine nehmen. Aber das DOM bietet eigentlich schon die Basisfunktionalität und wenn man die selbst erweitert bleibt man flexibler.
DOM entsteht ja aber nicht von allein, sondern benötigt ebenfalls Software, damit es funktioniert.
Jedenfalls fällt die von dir dargestellte Wunderwelt keinesfalls von alleine aus der Tüte - um dahin zu kommen ist vermutlich extrem viel Arbeit notwendig, die im Normalfall nicht gerechtfertigt ist, weil der "einfache" Weg deutlich vorteilhafter ist.
Der "einfache" Weg bedeutet aber in diesem Fall Fremdsoftware (Template-Engin) zu verwenden, oder? Hier sehe ich den Nachteil, dass die nicht wirklich standardisiert sind, oder gibt es da etwas für verschiedene Plattformen (PHP/Java usw.)? Ansonsten müsste man seine Ausgabe als reinen Text betrachten und das sehe ich auf keinen Fall als einfacher an, als mit DOM zu arbeiten.
DOM ist ebenfalls von "Fremdsoftware" abhängig. Und es ist, wenn ich unsere internen Diskussionen zum Thema "SELFHTML 9 in XML" erinnere, ein komplexes Thema mit leider nur wenigen brauchbaren Implementationen.
Wenn ich mir dagegen das Wunderland "Template-Engines" angucke - da gibt es eine reichhaltige Auswahl verschiedenster Systeme, man muß eigentlich nur noch zugreifen.
Es ist auch ein Irrglaube, dass eine einmal gefundene Lösung (egal ob DOM oder irgendwelche Templates) in irgendeiner Weise universell einsetzbar sei. Wenn man sie auf "universell" trimmen will, baut man zusätzliche Komplexität und Overhead ein, ohne dennoch vollkommene Freiheit zu gewinnen. Und es ist sehr fraglich, ob dieser Mehraufwand irgendwann einmal Früchte tragen würde.
Konkrete Problemstellungen erfordern konkrete Lösungen. Veränderte Problemstellungen erfordern veränderte Lösungen. Neu hinzugekommene Problemstellungen erfordern neu hinzugefügte Lösungen.
Aber eigentlich nie wird eine ultimativ eierlegende Wollmilchsau verlangt. Alleine schon deshalb nicht, weil niemand von einer Software verlangt, dass sie "alles" kann.
- Sven Rautenberg
Yerf!
DOM ist ebenfalls von "Fremdsoftware" abhängig. Und es ist, wenn ich unsere internen Diskussionen zum Thema "SELFHTML 9 in XML" erinnere, ein komplexes Thema mit leider nur wenigen brauchbaren Implementationen.
Wenn ich mir dagegen das Wunderland "Template-Engines" angucke - da gibt es eine reichhaltige Auswahl verschiedenster Systeme, man muß eigentlich nur noch zugreifen.
Das ist immer das Problem, wenn Standards zu spät kommen. Aber das wird sich wohl nie vermeiden lassen und man wird wohl mit dem Mehraufwand leben müssen, den man beim Wechsel zwischen Systemen hat.
Es ist auch ein Irrglaube, dass eine einmal gefundene Lösung (egal ob DOM oder irgendwelche Templates) in irgendeiner Weise universell einsetzbar sei. Wenn man sie auf "universell" trimmen will, baut man zusätzliche Komplexität und Overhead ein, ohne dennoch vollkommene Freiheit zu gewinnen. Und es ist sehr fraglich, ob dieser Mehraufwand irgendwann einmal Früchte tragen würde.
Nicht "Universell" in der Gesamtheit, aber in Teilen wiederverwendbar und erweiterbar. Das DOM als Basis und nach obenhin Schichtweie erweitert auf die spezielle Aufgabe hin. Bei einer neuen Aufgabe kann man dann die Basis wieder verwenden, "höhere" Schichten werden erweitert oder hinzugefügt. Klar ist das mehr Wunschdenken, als die reale Programmiererwelt. Aber man wird ja wohl noch träumen dürfen... ;-)
Gruß,
Harlequin
PS: Die Unterschiede zwischen schöner DOM-Welt und harter (Browser-)Realität erlebe ich gerade bei meinem Versuch, feststehende Header bei scrollbaren Tabellen ohne Frames zu realisieren...
Hallo Sven,
[DOM] Und es ist, wenn ich unsere internen Diskussionen zum Thema "SELFHTML 9 in XML" erinnere, ein komplexes Thema mit leider nur wenigen brauchbaren Implementationen.
Ähm, verwechselst Du das nicht gerade mit XSLT? Zudem: XSLT 1.0 ist sehr gut unterstützt von aller möglichen Software, erst bei XSLT 2.0 fängt's an, kompliziert zu werden.
Viele Grüße,
Christian
Hallo Harlequin,
Ich stelle mir eine eigene Template-Engin mit XML-Fragmenten vor. Sollte sich eigentlich relativ einfach und schnell lösen lassen.
Ich hab' sowas tatsächlich schonmal (in Perl) für ein kleines Redaktionssystem gemacht.
Artikel und andere Dokumente waren XML (Jedenfalls der Text, den solches wenig strukturiertes Markup speichert sich relational nicht besonders gut) und verschiedene Module haben alle XML-Dokumente erzeugt, die dann mit XSLT als Templates übersetzt wurden.
Da kam auch teilweise DOM zum Einsatz um XML-Fragmente zu erzeugen. Die Ausgabe spielt aber letzten Endes fast keine Rolle. Ich habe zwar damals XHTML genommen, man hätte das aber genau so gut nach HTML serialisieren können. Das XML-Modul hat das sogar direkt unterstützt.
Interessant ist XHTML wegen der XML-Grundlage eigentlich nur, wenn man das Zeug verarbeiten will, da man dann einfach einen XML-Parser benötigt, die praktisch immer verfügbar und sehr robust sind.
Das ist aber praktisch sehr selten der Fall. Bleibt also der Anwendungsfall, dass man MathML, SVG o.ä. verwenden will. Das ist zwar eigentlich toll, nur mangels Browserunterstützung auch selten praktisch einsetzbar.
Grüße
Daniel
Hallo,
Ich stelle mir eine eigene Template-Engin mit XML-Fragmenten vor. Sollte sich eigentlich relativ einfach und schnell lösen lassen.
Schau Dir doch mal bereits vorhandene Lösungen an:
* XSLT
Sowie, falls Du eher Template Engines als eine Transformationssprache suchst:
* TAL
Eine Template-Sprache namens TAL, die ursprünglich für Zope entwickelt
wurde, für die es aber inzwischen auch andere Implementierungen gibt.
Finde ich aber persönlich nicht so gelungen, v.a. wenn ich's vergleiche
mit:
* Genshi
Eine (in meinen Augen) ziemlich coole Template-Engine für Python.
Viele Grüße,
Christian
Yerf!
Ich stelle mir eine eigene Template-Engin mit XML-Fragmenten vor. Sollte sich eigentlich relativ einfach und schnell lösen lassen.
Schau Dir doch mal bereits vorhandene Lösungen an:
Hm, einerseits gehts mir hier auch ums einmal selber machen, andererseits entsprechen deine Vorschläge nicht ganz dem, was ich erreichen will. Evtl. hab ich mit dem Begriff Template-Engin etwas vergirffen, wüsste aber auch grad nicht wie ich das Ding bezeichnen sollte. Vieleicht eher ein CMS, das nur dass kann was ich brauche (passt aber auch nicht ganz...) Es soll halt die Grundlage meiner HP werden und mir Verschiedenes erleichtern. Zusammensetzen der Seite aus einem Tamplate fürs Layout und den tatsächlichen Texten, automatische Menü-Generierung usw.
* XSLT
XSLT klingt sehr interessant, ich hatte bisher nur leider keine Zeit mich tiefer damit zu beschäftigen. Damit kann man sicher einiges eleganter als mit DOM erledigen, aber ich denke sie ergänzen sich eher, als dass sie sich gegenseitig Überflüssig machen.
* TAL
Eine Template-Sprache namens TAL, die ursprünglich für Zope entwickelt
wurde, für die es aber inzwischen auch andere Implementierungen gibt.
Finde ich aber persönlich nicht so gelungen, v.a. wenn ich's vergleiche
mit:
* Genshi
Eine (in meinen Augen) ziemlich coole Template-Engine für Python.
Was mich bei diesen Template-Systemen stört, ist dass HTML und Code nicht getrennt sind. Es ist besser als "stures" PHP (oder ähnliches) mit echo, da der meiste Code ausgelagert ist, aber man hat immer noch die Template-Anweisungen im HTML. ASP.NET mit seinen ASPX-Seiten geht hier einen ähnlichen Weg.
Was mir nebenbei auch noch auffällt: XSLT und Genshi arbeiten ebenfalls intern mit XML, auch wenn man schlußendlich HTML ausgeben kann.
Gruß,
Harlequin
Hallo Harlequin,
* TAL
Eine Template-Sprache namens TAL, die ursprünglich für Zope entwickelt
wurde, für die es aber inzwischen auch andere Implementierungen gibt.
Finde ich aber persönlich nicht so gelungen, v.a. wenn ich's vergleiche
mit:
* Genshi
Eine (in meinen Augen) ziemlich coole Template-Engine für Python.Was mich bei diesen Template-Systemen stört, ist dass HTML und Code nicht getrennt sind.
Kannst Du das mal näher erläutern? Gut, man kann bei Genshi zumindest noch per <?python ?> richtigen Python-Code in die Templates einbinden, aber das muss man nicht verwenden und ich hab's noch nie gebraucht.
Anders gefragt: Einfaches Beispiel, Stupides Gästebuch (Genshi-Syntax, TAL ginge aber ähnlich):
<h3>Gästebucheinträge</h3>
<div py:for="eintrag in eintraege">
<p>${eintrag}</p>
</div>
Ich nehme mal an, dass Dir das schon zu viel Code in den Templates ist - wenn ich Dich richtig interpretiere. Daher: Wie würdest Du dieses einfache Beispiel lösen wollen?
aber man hat immer noch die Template-Anweisungen im HTML. ASP.NET mit seinen ASPX-Seiten geht hier einen ähnlichen Weg.
Bei ASP kümmern sich - genauso wie PHP oder JSP - nicht darum, ob die ausgegebene XML-Struktur stimmt. TAL und Genshi kümmern sich dagegen schon darum. Das ist IMHO ein _enormer_ Unterschied.
Viele Grüße,
Christian
Yerf!
Anders gefragt: Einfaches Beispiel, Stupides Gästebuch (Genshi-Syntax, TAL ginge aber ähnlich):
<h3>Gästebucheinträge</h3>
<div py:for="eintrag in eintraege">
<p>${eintrag}</p>
</div>
>
> Ich nehme mal an, dass Dir das schon zu viel Code in den Templates ist - wenn ich Dich richtig interpretiere. Daher: Wie würdest Du dieses einfache Beispiel lösen wollen?
Hm, das Beispiel ist schon fast wieder zu einfach ;-) So gesehen kann man wenig dran aussetzen, meine Aussage bezog sich eher darauf, das mit den Template-Befehlen noch mehr möglich ist. Aber klar, man muss es ja nicht benutzen. Trotzdem könnte man die Absätze für die Einträge per XSLT erzeugen (eine Schleife im Programm um die Elemente per DOM zu erzeugen wäre hier wohl etwas umständlich, aber möglich) und das Ergebnis-XML dann per DOM an der richtigen Stelle ins Template hängen. Sind auch nur ein paar wenige Befehle.
> Bei ASP kümmern sich - genauso wie PHP oder JSP - nicht darum, ob die ausgegebene XML-Struktur stimmt. TAL und Genshi kümmern sich dagegen schon darum. Das ist IMHO ein \_enormer\_ Unterschied.
Das ist auf alle Fälle ein Vorteil. Das hätte ich auch gern bei ASP.NET... das sieht als Default HTML 4.01 vor, erzeugt aber bei eigenen Tags einen Abschließenden Schrägstrich nach XHTML-Syntax...
Es ging mehr um das Prinzip, im HTML nur noch ein Minimum an Befehlen zur Steuerung zu haben und den restlichen Programmcode getrennt verwalten zu können.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. [Get one today!](http://www.opera.com)<![endif]-->
Hallo,
Trotzdem könnte man die Absätze für die Einträge per XSLT erzeugen (eine Schleife im Programm um die Elemente per DOM zu erzeugen wäre hier wohl etwas umständlich, aber möglich) und das Ergebnis-XML dann per DOM an der richtigen Stelle ins Template hängen. Sind auch nur ein paar wenige Befehle.
Ja, aber dann hast Du im Endeffekt die Information "wo genau steht denn der Inhalt" in den Programmcode verlagert. Gut, natürlich ist Präsentationslogik nicht AUSSCHLIESSLICH Templates, da gehört schon etwas normaler Code dazu, aber ich will ja gerade als Template-Autor NICHT darauf festgelegt sein, welche Struktur der Seite der Code erwartet - ich will nur bestimmte Variablen haben, die ich an beliebiger Stelle ausgeben kann. Natürlich sollen die Daten nicht *vollkommen* beliebig ausgegeben werden, denn wie z.B. die Daten sortiert sind etc. oder ob sie nun ein Baum sind oder nicht gehört tatsächlich nicht ins Template.
Man muss IMHO die richtige Balance finden zwischen dem, was man im Template implementiert und dem, was man lieber im Code macht. Zuviel im Code (und da finde ich tendierst Du gerade zu hin) und man kann sich die Templates fast gleich sparen, weil man da zu wenig anpassen kann. Zuviel im Template und man schießt sich selbst ins Knie, weil's dann sauschlechter, unübersichtlicher und nicht wartbarer Code im Template wird.
Viele Grüße,
Christian
Yerf!
Anders gefragt: Einfaches Beispiel, Stupides Gästebuch (Genshi-Syntax, TAL ginge aber ähnlich):
<h3>Gästebucheinträge</h3>
<div py:for="eintrag in eintraege">
<p>${eintrag}</p>
</div>
>
> Ich nehme mal an, dass Dir das schon zu viel Code in den Templates ist - wenn ich Dich richtig interpretiere. Daher: Wie würdest Du dieses einfache Beispiel lösen wollen?
Noch eine Anmerkung dazu die mir gerade noch eingefallen ist und die erklärt, warum das für mich zu viel Code im Template ist: es ist zu speziell. Damit kann man zwar wunderbar die Einträge eines Gästebuchs ausgeben, aber eine Webpresänz besteht normalerweise aus mehr: Galerie, News, Kontaktformualr, etc.
Die Frage ist jetzt, ist es möglich Templates innerhalb von Templates zu verwenden? Also einen Master fürs Komplett-Layout und dann nochmal eines (je nach Anfroderung verschiedenes) für die Inhalte? Das ist ein Punkt, den ich bisher bei den Template-System noch nicht entdeckt habe (vielleicht muss ich auch nur tiefer einsteigen, hab bisher nur die Einführungen überflogen [1]). Aber bei meiner Variante mittels DOM (.getElementById().appendChild() ) ist es egal, woher ich das XML-Fragment habe (XSLT, Datei, selbstgestrickter DOM-Baum).
Gruß,
Harlequin
[1] Was ich grad bei Genshi entdeckt hab ist zumindest ein include. Der muss dann aber auch wieder mittels if im Template gesteuert werden, womit sich die Programmierung wieder ins Template verlagert.
--
<!--[if IE]>This page is best viewed with a webbrowser. [Get one today!](http://www.opera.com)<![endif]-->
Hallo Harlequin,
Noch eine Anmerkung dazu die mir gerade noch eingefallen ist und die erklärt, warum das für mich zu viel Code im Template ist: es ist zu speziell. Damit kann man zwar wunderbar die Einträge eines Gästebuchs ausgeben, aber eine Webpresänz besteht normalerweise aus mehr: Galerie, News, Kontaktformualr, etc.
Dann hast Du halt einfach mehrere Templates - eins für das Gästebuch, eins für das Kontaktformular, etc... Genauso wie man im Normalfall multiple statische HTML-Seiten haben kann.
Die Frage ist jetzt, ist es möglich Templates innerhalb von Templates zu verwenden? Also einen Master fürs Komplett-Layout und dann nochmal eines (je nach Anfroderung verschiedenes) für die Inhalte?
Ja, das geht, bei Genshi auf zwei verschiedene Arten:
1. Ein "Master-Template", das die Einzel-Templates einbindet (schriebst Du schon), allerdings möchte ich auf Deinen Einwand eingehen:
[1] Was ich grad bei Genshi entdeckt hab ist zumindest ein include. Der muss dann aber auch wieder mittels if im Template gesteuert werden, womit sich die Programmierung wieder ins Template verlagert.
Wieso if?
<xi:include href="${subtemplate}.html" />
Das heißt: Dein "Master-Template" lädt dann nur genau das Subtemplate, das ihm von Deinem Programmcode aus übergeben wird. Bzw, wenn Du multiple Templates an die gleiche Stelle einfügen können willst, kannst Du auch - ohne dass es großartig komplizierter wird - folgendes machen:
<xi:include href="${subtemplate}.html" py:for="subtemplate in subtemplates" />
(und dann die Variable subtemplates auf eine Liste von Templates setzen, die da eingefügt werden sollen)
Ich kann da wirklich nicht nachvollziehen, warum das zu viel Code in den Templates sein soll. Bedenke doch auch, dass es bei Templates darum geht, Präsentation von Prozesslogik zu trennen - und das erreichst Du wiederum nicht, wenn Du zu viele Teile wieder in den normalen Programmcode lagerst.
Zudem, es gibt noch eine zweite (sehr coole) Möglichkeit, mit Genshi Layout etc. zu realisieren: Match-Templates.
Du bindest im Endeffekt nur minimalistische Templates für die jeweiligen Spezialanwendungen, die Du haben willst, ein und diese haben ein einziges Include drin, das das Master-Template lädt, z.B. so:
<!DOCTYPE ...>
<html ...>
<xi:include href="layout.html" />
<head>
<title>Gästebuch</title>
</head>
<body>
<h3>Gästebuch</h3>
<div py:for="eintrag in eintraege">
<p>${eintrag}</p>
</div>
</body>
</html>
Und dann im Master-Template:
<html ... py:strip="">
<head py:match="head" py:attrs="select('@*')">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<!-- weitere meta-Tags oder <link> oder sonstwas was ins <head> JEDER
Seite gehört -->
<!-- im folgenden wird kein <meta/> stehen, sondern alle Elemente, die
im <head> auf der Spezialseite vorhanden sind; man kann's natürlich
auch anders realisieren, dies ist nur ein Beispiel: -->
<meta py:replace="select('*|text()')">
</head>
<body py:match="body" py:attrs="select('@*')">
<h1>...</h1>
<!-- navigation hier einfügen -->
<div class="blub">
<!-- irgendwelche div-konstrukte -->
<!-- und HIER DRIN jetzt der eigentliche inhalt von vorher: -->
<div py:replace="select('*|text()')">Dieser Text samt dem div wird ersetzt.</div>
</div>
</body>
</html>
Heraus käme dann sowas wie:
<!DOCTYPE ...>
<html ...>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<!-- weitere meta-Tags oder <link> oder sonstwas was ins <head> JEDER
Seite gehört -->
<title>Gästebuch</title>
</head>
<body>
<h1>...</h1>
<!-- navigation hier einfügen -->
<div class="blub">
<!-- irgendwelche div-konstrukte -->
<h3>Gästebuch</h3>
<div>
<p>1. Eintrag</p>
</div>
<div>
<p>2. Eintrag</p>
</div>
<div>
<p>3. Eintrag</p>
</div>
</div>
</body>
</html>
Siehe auch die Doku zu Genshi.
Viele Grüße,
Christian
Yerf!
Dann hast Du halt einfach mehrere Templates - eins für das Gästebuch, eins für das Kontaktformular, etc... Genauso wie man im Normalfall multiple statische HTML-Seiten haben kann.
Schon, aber gerade von dieser Menge an Dateien, die auch gepflegt werden wollen, will ich ja wegkommen.
[1] Was ich grad bei Genshi entdeckt hab ist zumindest ein include. Der muss dann aber auch wieder mittels if im Template gesteuert werden, womit sich die Programmierung wieder ins Template verlagert.
Wieso if?
Weils im beispiel der Doku so drinn stand und mein gehirn auf die Schnelle nicht in der Lage war weiterzudenken...
<xi:include href="${subtemplate}.html" py:for="subtemplate in subtemplates" />(und dann die Variable subtemplates auf eine Liste von Templates setzen, die da eingefügt werden sollen)
Ja, so wird das schon flexibler und meiner variante recht ähnlich. Kam mir nur nicht gleich der Gedanke.
Ich kann da wirklich nicht nachvollziehen, warum das zu viel Code in den Templates sein soll. Bedenke doch auch, dass es bei Templates darum geht, Präsentation von Prozesslogik zu trennen - und das erreichst Du wiederum nicht, wenn Du zu viele Teile wieder in den normalen Programmcode lagerst.
Ich glaube mein fehler war bisher mir Template-System nur zu oberflächlich anzusehen und anhand der Beispiele zu sagen: das taugt nix. Allerdings muss man schon etwas aufpassen, die richtige Mischung zu erwischen, nicht dass ein vorhandenes Template die Erweiterbarkeit des Codes einschränkt, weil es zu viel selber macht.
Zudem, es gibt noch eine zweite (sehr coole) Möglichkeit, mit Genshi Layout etc. zu realisieren: Match-Templates.
Du bindest im Endeffekt nur minimalistische Templates für die jeweiligen Spezialanwendungen, die Du haben willst, ein und diese haben ein einziges Include drin, das das Master-Template lädt, z.B. so:
Geil! ...um das mal so auszudrücken ;-)
Die sollten sowas nicht so gut auf der HP verstecken, damit man das eher findet. Wenn ich versuchen würde das zu realisieren käme ich schnell an die grenzen vom DOM. Ich denke mal, das läuft dann über XSLT.
Siehe auch die Doku zu Genshi.
Ich glaube die muss ich mir doch mal genauer ansehen.
Bleiben aber noch die Nachteile, dass zumindest Genshi nur für Python[1] ist und die Template-Sprachen an sich nicht standardisiert und so ohne weiteres austauschbar sind...
Gruß,
Harlequin
[1] könnte allerdings noch passieren, dass ich die Katze (Tomcat) wieder in den Sack packe und mir die Schlange auf meinen Server hole... hab heut mein erstes Python-Script gebaut und muss sagen die Sprache ist recht nett ;-)
Hallo Harlequin,
Geil! ...um das mal so auszudrücken ;-)
Ich sagte ja, Genshi sei cool. ;-)
Die sollten sowas nicht so gut auf der HP verstecken, damit man das eher findet.
*hihi*
Wenn ich versuchen würde das zu realisieren käme ich schnell an die grenzen vom DOM. Ich denke mal, das läuft dann über XSLT.
Nein, das ist alles "zu Fuß" programmiert, die unterstützen z.B. auch nur ein Subset von XPath (Du kannst z.B. keine Elternknoten selektieren - sonst müssten nämlich Teile immer gecached werden, was ENORM auf die Performance drückt). Aber das Prinzip ist ähnlich zu XPath.
Bleiben aber noch die Nachteile, dass zumindest Genshi nur für Python[1] ist und die Template-Sprachen an sich nicht standardisiert und so ohne weiteres austauschbar sind...
Ja, sowas Genshi für andere Sprachen vermisse ich auch. Es gibt zwar TAL, für das es Implementierungen in anderen Sprachen gibt, aber das kann keine Match Templates und außerdem finde ich die Syntax von TAL ziemlich doof. Auf meiner langen TODO-Liste steht übrigens, dass ich mal einen C-Port (den man dann auch in andere Sprachen einbinden könnte) in Angriff nehmen wollte. Aber naja, wie lange das dauert, bis daraus mal etwas sinnvolles wird. ;-)
Viele Grüße,
Christian
Hello out there!
Was sind denn so die markanten Vorteile von XHTML deiner Meinung nach?
XHTML ist einfacher als HTML. Dadurch kann man als Autor weniger Fehler machen, und mithilfe eines Validators findet man Fehler besser. [</archiv/2007/2/t147284/#m961973> und dortige Links]
See ya up the road,
Gunnar
Hello out there!
habe zuvor immer HTML 4.1 strict verwendet.
4.01.
Nur bin ich jetzt leicht verwirrt. Ist die Verwendung von XHTML im WWW sinnvoll?
Ja. [Jendryschik, Schneegans]
Oder sollte man gleich mit eigener DTD XML und XSL arbeiten?
Was versprichst du dir davon, eigenes XML zu schreiben und dieses dann in (X)HTML zu transformieren?
See ya up the road,
Gunnar
Hallo,
Nur bin ich jetzt leicht verwirrt. Ist die Verwendung von XHTML im WWW sinnvoll?
Ja. [Jendryschik, Schneegans]
Nach etwas Quellenstudium könnte ich auch gerade zum gegenteiligen Ergebnis
kommen, die Verwendung von XHTML im WWW ist nicht sinnvoll.
Merkwürdige Fehlerkonstrukte als Vor- oder Nachteil, schließlich irgendwo
möglicherweise irgendwelche Vorteile bei der Validierung, und was die Browser
'bekommen' ist eh wieder HTML.
Grüsse
Cyx23
Hello out there!
Nach etwas Quellenstudium könnte ich auch gerade zum gegenteiligen Ergebnis
kommen, die Verwendung von XHTML im WWW ist nicht sinnvoll.
Welche Quellen hast du denn studiert?
Ohne Argumente ist dein Posting nicht sinnvoll.
See ya up the road,
Gunnar
Hallo,
Welche Quellen hast du denn studiert?
die genannten.
Ohne Argumente ist dein Posting nicht sinnvoll.
"Merkwürdige Fehlerkonstrukte als Vor- oder Nachteil, schließlich irgendwo
möglicherweise irgendwelche Vorteile bei der Validierung, und was die Browser
'bekommen' ist eh wieder HTML."
Grüsse
Cyx23
Hallo,
Merkwürdige Fehlerkonstrukte als Vor- oder Nachteil
Häh?
schließlich irgendwo möglicherweise irgendwelche Vorteile bei der Validierung
Soll das bloße Polemik sein oder willst du mit »irgendwo möglicherweise irgendwelche« etwas bestimmtes ausdrücken außer vielleicht dein Unwissen? ;)
und was die Browser 'bekommen' ist eh wieder HTML.
Genau.
Mathias
Hallo Mathias,
Merkwürdige Fehlerkonstrukte als Vor- oder Nachteil
Häh?
Sorry wenn die Formulierung nicht so gelungen sein sollte.
Bezieht sich auf Überlegungen des Autors(1), welche unüblichen
Code-Veschachtelungen bzw. Schreibweisen jeweils in HTML oder in XHTML
fehlerhaft seien, und welche nicht.
schließlich irgendwo möglicherweise irgendwelche Vorteile bei der Validierung
Soll das bloße Polemik sein oder willst du mit »irgendwo möglicherweise irgendwelche« etwas bestimmtes ausdrücken außer vielleicht dein Unwissen? ;)
Schneegans sieht als Nachteil von XHTML den Verzicht auf document.write,
als Vorteil die bessere Validierbarkeit.
Wo und wann dieser Vorteil wirklich zum Tragen kommt, was daraus wiederum
für konkrete Vorteile entstehen, und ob ähnliche Vorteile nicht auch bei
HTML möglich sind, da mag mir tatsächlich der nötige Überblick fehlen.
Problematische Schreibweisen könnten auch ohne XHTML vermieden oder
ausgeschlossen werden, Validatoren liessen sich wohl auch noch verbessern.
Ich hab jetzt keine Quellen bemüht, um Nachteile von XHTML aufzuführen,
vmtl. wird es trotz 'XHTML-Hype' auch irgendwo Kritik geben.
Allerdings habe ich bislang in der Praxis auch keine Nachteile mit XHTML
festgestellt.
Grüsse
Cyx23
Hallo,
Wo und wann dieser Vorteil wirklich zum Tragen kommt, was daraus wiederum
für konkrete Vorteile entstehen, und ob ähnliche Vorteile nicht auch bei
HTML möglich sind, da mag mir tatsächlich der nötige Überblick fehlen.
Dazu bedarf es natürlich eines Verständnisses von SGML versus XML, den Problemen von SGML-DTDs und den Vorteilen von XML und XML Schema. Das ist ein weites Feld. Kurz gesagt lassen sich viele Regeln nicht in DTDs ausdrücken, aber in XML Schema. Und übliche HTML4-DTD-Validatoren können aus strukturellen Gründen manche »Fehler« gar nicht finden, weil SGML sie zulässt, sie also strenggenommen erlaubt sind, aber in der Praxis Bullshit.
Zum Einstieg:
http://forum.de.selfhtml.org/archiv/2007/5/t152241/#m990423
http://aktuell.de.selfhtml.org/weblog/xhtml-validierung
Problematische Schreibweisen könnten auch ohne XHTML vermieden oder
ausgeschlossen werden, Validatoren liessen sich wohl auch noch verbessern.
Ja, aber Validatoren validieren bloß. Das ist ein definiertes, festgelegtes technisches Verfahren. Darüber hinaus kann man viele »Lints« schreiben wie etwa HTML Tidy. Die beziehen sich dann nicht bloß auf eine normative maschinenlesbare Definition von dem, was »valide« bedeutet.
vmtl. wird es trotz 'XHTML-Hype' auch irgendwo Kritik geben. HTML 5 und damit »definierte« Tag Soup ist en vogue.
Eigentlich gibt es momentan das Gegenteil eines XHTML-Hypes, siehe Links.
Mathias
Hallo,
vmtl. wird es trotz 'XHTML-Hype' auch irgendwo Kritik geben. HTML 5 und damit »definierte« Tag Soup ist en vogue.
Eigentlich gibt es momentan das Gegenteil eines XHTML-Hypes, siehe Links.
danke, die Links werd ich mir morgen nochmal im Detail anschauen.
Vermute mal, dass es als Gegenentwicklung kein reiner "HTML-Hype" ist,
sondern dass die Entwicklung mit eingebundenen Medien, Werbung und
interaktiven Sachen a la Web 2.0 mit anderen Anforderungen einfach am
offenbar auch entbehrlichen XHTML erstmal vorbeigegangen ist.
Grüsse
Cyx23
Hallo,
Vermute mal, dass es als Gegenentwicklung kein reiner "HTML-Hype" ist,
sondern dass die Entwicklung mit eingebundenen Medien, Werbung und
interaktiven Sachen a la Web 2.0 mit anderen Anforderungen einfach am
offenbar auch entbehrlichen XHTML erstmal vorbeigegangen ist.
Klar. XHTML 1.x war ja nie mehr als die Reformulierung von HTML in XML. Das ist natürlich keine Erweiterung der Möglichkeiten bzw. keine Reaktion auf aktuelle Anforderungen. HTML 5 ist m.M.n. keine Gegenentwicklung in Bezug auf XHTML 1, sondern mehr in Bezug auf XHTML 2. Und XHTML 2 war immer ein Luftschloss, an dem tatsächlich die aktuelle Entwicklung vorbeigegangen ist. (Die praktische Frage »XHTML ja/nein« drehte sich ohnehin nie um XHTML 2.)
HTML5-Enthusiasten verachten aber nicht nur XHTML 2, sondern sehen die gesamte XML-Linie als gescheitert an und verwenden deshalb demonstrativ HTML 4 ... Das kann ich so nicht nachvollziehen.
Der Schritt von (sauberem) HTML 4 zu XHTML 1 (als text/html) ist kein großer oder bedeutender, soviel Diskussionsstoff liefert das gar nicht.
Mathias
Hallo,
HTML5-Enthusiasten verachten aber nicht nur XHTML 2, sondern sehen die gesamte XML-Linie als gescheitert an und verwenden deshalb demonstrativ HTML 4 ... Das kann ich so nicht nachvollziehen.
Ich bin selbst XHTML-Kritiker, aber das hat nichts mit HTML 5 zu tun. Das hab ich bis vor kurzem auch noch verachtet.
Die Problematik an XHTML ist, dass es als text/html verarbeitet einfach nur Schrott produziert. Die Dokumente müssten dann trotzdem den strengen XML Regeln folgen und das zieht zahlreiche Probleme mit sich: Stile und Skripte werden unterschiedlich verarbeitet Manche Features aus HTML und XML können nicht verwendet werden. Quirksmode.
Der Schritt von (sauberem) HTML 4 zu XHTML 1 (als text/html) ist kein großer oder bedeutender, soviel Diskussionsstoff liefert das gar nicht.
Bei HTML 4 muss man selbst etwas genauer auf die Fehler achten. bei XHTML mehr auf die Kompatibilität zu XML-Parsern. Letzteres macht kaum jemand...
Gruß;
Hello out there!
Die Problematik an XHTML ist, dass es als text/html verarbeitet einfach nur Schrott produziert.
??*
XHTML 1.0 als 'text/html' produziert nichts anderes als HTML 4.01 als 'text/html'.
(Mag sein, dass das Schrott ist, das liegt dann am Webseitenautor, der mit XHTML 1.0 wie mit HTML 4.01 gleichermaßen Schrott produziert.)
Die Dokumente müssten dann trotzdem den strengen XML Regeln folgen und das zieht zahlreiche Probleme mit sich: […] Manche Features aus HTML und XML können nicht verwendet werden.
??*
Welche Features aus HTML 4.01 können denn bitte in XHTML 1.0 nicht verwendet werden?
Quirksmode.
??*
XHTML 1.0 zieht keinen Quirksmode nach sich; die XML-Deklaration ist schließlich optional.
See ya up the road,
Gunnar
* lies: Unsinn!
Hallo,
Ich bin selbst XHTML-Kritiker, aber das hat nichts mit HTML 5 zu tun.
HTML 5 und XHTML 1 sind Antworten auf dasselbe Problem: Nach HTML 4 sind viele unterschiedliche Parser entstanden, die die mannigfaltigen Fehler in HTML-Dokumenten unterschiedlich behandelt haben.
XHTML sollte alle Schwierigkeiten bei der Dekodierung der textuellen Linearisierung zum DOM (und umgekehrt) mit einem Mal abfrühstücken, indem eine eindeutige Linearisierung und eindeutige Regeln zum Parsen vorliegen.
HTML 5 will das genaue Gegenteil und doch dasselbe. Es gibt auch definierte Parsing-Regeln und eine eindeutige Abbildung, aber das Verhalten bei Fehlern ist mitdefiniert und ein Konzept von rigider Wohlgeformtheit und »Fatal Errors« gibts nicht.
Die Problematik an XHTML ist, dass es als text/html verarbeitet einfach nur Schrott produziert.
Definiere Schrott.
Die Dokumente müssten dann trotzdem den strengen XML Regeln folgen
Ja, das ist der Sinn, sonst sollte man bei HTML 4 bleiben.
und das zieht zahlreiche Probleme mit sich: Stile und Skripte werden unterschiedlich verarbeitet
Ja, wenn man XHTML als XHTML ausliefert, ansonsten nicht.
Diese Unterschiede sind unter dem Strich marginal.
Manche Features aus HTML und XML können nicht verwendet werden. Quirksmode.
?? ;)
Bei HTML 4 muss man selbst etwas genauer auf die Fehler achten. bei XHTML mehr auf die Kompatibilität zu XML-Parsern. Letzteres macht kaum jemand...
Wohlgeformtheit - mach's mit! ;)
Mathias