Bei HTML bleiben oder zu XHTML wechseln?
- Ersteller Maxefix
- Erstellt am
Hallo,
ich hab meine komplette Homepage in "HTML 4.01 Transitional" geschrieben. Aber in letzter Zeit begegnen mir immer mehr Seiten die in XHTML geschrieben sind, auch so Templates von Foren und Gästebüchern (Buringbook zum Beispiel) sind in XHTML geschrieben.
Aber warum? Hab schon hier bissl gesucht und wenn ich des richtig verstanden hab hat XHTML gar keinen Vorteil sondern nur den Nachteil das man jedes Detail extra festlegen muss?!
Deshalb meine Frage: Lohnt es sich XHTML mal näher anzuschaun und ggf. meine Homepage "umzuschreiben"?
MFG Max
ich hab meine komplette Homepage in "HTML 4.01 Transitional" geschrieben. Aber in letzter Zeit begegnen mir immer mehr Seiten die in XHTML geschrieben sind, auch so Templates von Foren und Gästebüchern (Buringbook zum Beispiel) sind in XHTML geschrieben.
Aber warum? Hab schon hier bissl gesucht und wenn ich des richtig verstanden hab hat XHTML gar keinen Vorteil sondern nur den Nachteil das man jedes Detail extra festlegen muss?!
Deshalb meine Frage: Lohnt es sich XHTML mal näher anzuschaun und ggf. meine Homepage "umzuschreiben"?
MFG Max
feelx
Grand Admiral Special
Hi
Anschauen lohnt sich XHTML bestimmt - aber die bestehende Site würde ich sicher nicht "umbauen". Darin sehe ich keinerlei Vorteile. Ein Redesign oder einen neuen Auftritt kannst du dann immer noch in XHTML machen.
XHTML hat besonders da vorteile, wo du auch XML daten in die Homepage miteinpflegst... (denke z.B. an eine angeschlossene grosse Datenbank, welche XML Daten exportiert).
Die Unterschiede sind relativ klein - und somit hält sich auch das "Umgewöhnen" in Grenzen. Aber man sollte dies schon tun, da das W3C keine weiteren HTML Versionen veröffentlichen will, sondern XHTML fortführen soll. HTML5, welches eine Gruppierung forciert, gebe ich persönlich eher weniger Chancen...
BTW: Was meinst du mit "Nachteile" bei XHTML ?
Anschauen lohnt sich XHTML bestimmt - aber die bestehende Site würde ich sicher nicht "umbauen". Darin sehe ich keinerlei Vorteile. Ein Redesign oder einen neuen Auftritt kannst du dann immer noch in XHTML machen.
XHTML hat besonders da vorteile, wo du auch XML daten in die Homepage miteinpflegst... (denke z.B. an eine angeschlossene grosse Datenbank, welche XML Daten exportiert).
Die Unterschiede sind relativ klein - und somit hält sich auch das "Umgewöhnen" in Grenzen. Aber man sollte dies schon tun, da das W3C keine weiteren HTML Versionen veröffentlichen will, sondern XHTML fortführen soll. HTML5, welches eine Gruppierung forciert, gebe ich persönlich eher weniger Chancen...
BTW: Was meinst du mit "Nachteile" bei XHTML ?
OK, aber irgendwie versteh ich immernoch nicht warum man dann nen neuen Standard entwickelt wenn er keine nennenswerte Vorteile hat?!
Ich beziehe mich da auf dieses Posting. Kann aber auch sein das ich da was Missverstanden hab...
MFG Max
Soweit ich weiß wird es HTML5 nicht geben, sondern alles in XHTML 2 Einzug nehmen. Zu HTML5 gibt es auch keine Working group beim W3C. Es gibt ein paar Artikel, die sich auf HTML5 beziehen. Ich würde aber nicht drauf wetten.
Diesen Nachteil kann man auch als Vorteil sehen.
Wie viele Leute gibt es denn, die h3 Tags verwenden, weil da die Schrift nicht so groß ist? mit den hX-Tags soll eine semantische Gliederung erreicht werden und das Aussehen soll wo anders konfiguriert werden. Es gibt da noch mehr Beispiele.
XHTML 1 ist mehr oder weniger das gleiche wie HTML4, nur, dass es jetzt eben ein XML-Dokument ist und mit xml Schema und nicht mehr mit SGML (DTD) beschrieben ist.
Damit muss das Dokument eine saubere Baumstruktur haben, es muss jedes Tag also geschlossen werden und Tag-Bereiche dürfen sich nicht überkreuzen. Bei html4 musste z.B. ein li-Tag, ein br-Tag oder ein p-Tag nicht zugemacht werden. br-Tags stellt man dann halt als leeres xml-Element dar : entweder <br/> oder die auch gültige, wenn auch hässliche Variante <br></br>
Diesen Nachteil kann man auch als Vorteil sehen.
Wie viele Leute gibt es denn, die h3 Tags verwenden, weil da die Schrift nicht so groß ist? mit den hX-Tags soll eine semantische Gliederung erreicht werden und das Aussehen soll wo anders konfiguriert werden. Es gibt da noch mehr Beispiele.
XHTML 1 ist mehr oder weniger das gleiche wie HTML4, nur, dass es jetzt eben ein XML-Dokument ist und mit xml Schema und nicht mehr mit SGML (DTD) beschrieben ist.
Damit muss das Dokument eine saubere Baumstruktur haben, es muss jedes Tag also geschlossen werden und Tag-Bereiche dürfen sich nicht überkreuzen. Bei html4 musste z.B. ein li-Tag, ein br-Tag oder ein p-Tag nicht zugemacht werden. br-Tags stellt man dann halt als leeres xml-Element dar : entweder <br/> oder die auch gültige, wenn auch hässliche Variante <br></br>
![[³dgamer]](/data/avatars/m/25/25369.jpg?1596828194){kind=avatar}
[³dgamer]
Grand Admiral Special
- Mitglied seit
- 08.02.2005
- Beiträge
- 2.018
- Renomée
- 38
was mich bisher abhält xhtml zu nutzen ist die tatsache, das DHTML-editieren grundsätzlich nur html-befehle kann. ist zwar hart das fett noch mit <strong></strong> erzeugt wird, dafür kann halt online-WYSIWYG + W3C-konform abgedeckt werden.
vielleicht wirds ja mit IE7 kommen...![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
vielleicht wirds ja mit IE7 kommen...
feelx
Grand Admiral Special
Hi[³dgamer];2604405 schrieb:was mich bisher abhält xhtml zu nutzen ist die tatsache, das DHTML-editieren grundsätzlich nur html-befehle kann. ist zwar hart das fett noch mit <strong></strong> erzeugt wird, dafür kann halt online-WYSIWYG + W3C-konform abgedeckt werden.
vielleicht wirds ja mit IE7 kommen...
Ich verstehe nicht ganz was du meinst? DHTML editieren ? Also Javascript/ECMAscript kannst du natürlich auch mit XHTML einbinden... oder verstehe ich was falsch?
BTW: Ein Nachteil von XHTML könne z.B. sein, dass (zumindest streng korrekt nach XML schema) kein Javascript document.write(xxx) mehr erlaubt ist. Zahlreiche fertige Javascript/DHTML lösungen setzten noch auf document.write. Aber damit wäre es ja z.B. möglich ein "ungültiges", bzw. not wellformed XML dokument zu erstellen... document.write ('<bla>ich bin ein ungültiges bla-element </bla>')
Daher muss man tatsächlich "umdenken", was Javascript/DHTML betrifft und sich ans W3C Dom halten - für <p> z.B. document.createElement("P"); usw, was natürlich nur für definierte Elemente gültig ist...
Aber ich fürchte das hast du nicht gemeint, oder?
BTW: ein <strong> bla bla bla </strong> ist natürlich nach wie vor zugelassen - sogar in XHTML strict oder xhtml 1.1 - Dabei handelt sich sich NICHT um ein "Formatierungselement", sondern um ein Element der Textstrukturierung (also sowas wie "besonders wichtig" oder so). Das kannst du vergleichen mit <acronym>U.N.</acronym) usw, die nach wie vor gültig (und sinnvoll) sind.
Ja ich bin auch mehr als skeptisch, was HTML 5 betrifft - es gibt zwar eine "Working Group" http://whatwg.org/, welche dies vorantreiben will. Es sind auch Browser-Hersteller beteiligt - aber mir leuchtet der Sinn ehrlich gesagt nicht ganz ein - Es führt imo nur wieder dazu, dass die Browserhersteller womöglich Standards nur unzulänglich unterstützen - also genau das Gegenteil von dem, was eigentlich notwendig wäre.Georg schrieb:
Vermutlich nen kleinen Tippfehler: Man sollte nicht <br/> schreiben (das könnten ältere Browser irritieren), sondern immer den Abstand machen - also <br />, dann interpretieren ältere (XHTML-untaugliche) browser den <br> trotzdem.
Zuletzt bearbeitet:
Der eigentliche Vorteil von XHTML ist einfach, daß es sauberer ist, das ist immer gut. Bei HTML sind diverse eigentlich unlogische Sachen drin (wie eben z.B. das <br>, was ein ungeschlossenes Tag ist). Allerdings wird es oft nicht möglich sein oder zumindest unnötig schwierig, die Seite mit den W3C-Validator wirklich komplett zertifiziert zu kriegen; wenn man z.B. ein Gästebuch als IFrame einbaut, ist schon Essig.
Jedenfalls kann es sicher nicht schaden, sich einen möglichst modernen und möglichst sauberen Stil anzugewöhnen, und die Seite erstmal "richtig" zu schreiben und danach mithilfe diverser Unsauberkeiten soweit anzupassen, daß sie auch in jedem Browser läuft (naja, Netscape 4.x vergessen wir mal^^, aber IE ist schon schwer genug). Dazu gehört auch, Inhalt und Formatierung zu trennen, d.h. möglichst alle Formatierungen in CSS zu machen. Das wird später durch XSL abgelöst werden, was XML voraussetzt, selbst aber auch wiederum XML ist und auch mehr Möglichkeiten bietet.
Jedenfalls kann es sicher nicht schaden, sich einen möglichst modernen und möglichst sauberen Stil anzugewöhnen, und die Seite erstmal "richtig" zu schreiben und danach mithilfe diverser Unsauberkeiten soweit anzupassen, daß sie auch in jedem Browser läuft (naja, Netscape 4.x vergessen wir mal^^, aber IE ist schon schwer genug). Dazu gehört auch, Inhalt und Formatierung zu trennen, d.h. möglichst alle Formatierungen in CSS zu machen. Das wird später durch XSL abgelöst werden, was XML voraussetzt, selbst aber auch wiederum XML ist und auch mehr Möglichkeiten bietet.
feelx
Grand Admiral Special
Ja du hast recht, <iframe> ist sowohl in xhtml 1.0 strict als auch in xhtml 1.1 nicht mehr unterstützt - dafür gibt's den Weg via <object> - oder aber, man bindet in xhtml 1.1 das <iframe> modul mit ein. Dazu erstellt man eine eigene DTD - einen Überblick mit Beispielen verschaft diese Seite (code-beispiele und Hinweise wie man die DTD schreibt, befinden sich ganz unten)
[³dgamer]
Grand Admiral Special
- Mitglied seit
- 08.02.2005
- Beiträge
- 2.018
- Renomée
- 38
ich meinte diese DHTML-IE-only geschichte mit 'contentedidable'
dort sind halt IE-funktionen definiert, an die man parameter übergibt, die dann entsprechende elemente in z.b. ein zu editierendes div-feld schreiben.
sowas geht auch per JS, aber dort ist es, jedenfalls für mich, nicht möglich, das eine markierung erkannt und umgesetzt wird.
z.b. ich markiere nen text und kann für diesen text einen link definieren...
und dieser krams ist halt kein xhtml (auch wenn ein teil durchaus gültiges xhtml darstellt, das geb ich zu)
feelx
Grand Admiral Special
[³dgamer];2605682 schrieb:ich meinte diese DHTML-IE-only geschichte mit 'contentedidable'
dort sind halt IE-funktionen definiert, an die man parameter übergibt, die dann entsprechende elemente in z.b. ein zu editierendes div-feld schreiben.
sowas geht auch per JS, aber dort ist es, jedenfalls für mich, nicht möglich, das eine markierung erkannt und umgesetzt wird.
z.b. ich markiere nen text und kann für diesen text einen link definieren...
und dieser krams ist halt kein xhtml (auch wenn ein teil durchaus gültiges xhtml darstellt, das geb ich zu)
Hui... ich kenne diese contenteditable geschichte nicht - hab in allen Büchern, die ich gelesen habe jeweils die Kapitel und Passagen übersprungen, die sich mit IE proprietären Dingen beschäftigten... Auch mit JS habe ich keine Erfahrung, wie das geht... habe aber in meinem Buch nen kleinen Hinweis gefunden auf 'selection' bzw 'getSelection'. Und bin dann auf diesen Link gestossen:
http://www.quirksmode.org/js/selected.html
Kurz - es gibt 3 Mögichkeiten
window.getSelection() (Mozilla, alle IE)
document.getSelection() (Mozilla, IE7-beta2, IE 5-6)
document.selection() (alle IE, Mozilla)
(grün=works | rot = works not)
Also wieder mal eine tolle Kompatibilitätsgeschichte - nett, dass MS beim IE7 zumindest Besserung gelobt - aber in der Praxis wird man wohl wie im Beispiel alle drei Methoden anwenden müssen....
PS: Danke für den Hinweis
*edit*
habe es gerade noch mit Konqueror getestet, weil auf der o.g. Site ja steht, dass es nicht funktioniert - aber hier Entwarnung: document.getSelection funktioniert mit Konqueror (v3.5.1 / KDE 3.5)
Zuletzt bearbeitet:
