XHTML ist tot, es lebe HTML 5.0
-
Hallo,
TdZ schrieb:
Was meint ihr? Haltet ihr die Entscheidung des W3C für klug?
Nein, das ist ganz sicher nicht klug. Gerade das mit XHTML das alte verwachsene HTML auf eine neue saubere XML-Basis gestellt wurde finde ich persönlich sehr gut. Ich selber habe nur einzelne primitive Webseiten geschrieben, waren meistens einfache Text-Seiten zur Dokumentation oder als Manual mit vereinzelten SVG-Graphiken, aber die waren alle als valides "XHTML 1.1 strict" ausgeführt. Ich hätte mir viel lieber gewünscht das die multimedialen Fähigkeiten in XHTML 2.x eingeflossen wären.
Pixel-Genaues Web-Design ist IMHO schon von der Idee her scheiße, schließlich habe ich mit hoher Wahrscheinlichkeit einen anderen Monitor als der Seiten-Gestalter. Viel wichtiger wäre es wenn ein Browser jede Seite so darstellen könnte wie dem User das zusagt. Daher wäre es toll wenn der Browser z.B. Navigationselemente als solche erkennen könnte und sie immer dort hin positioniert wo es mir am liebsten ist und ich nicht auf jeder Seite neu suchen muss, auch der Screen-Reader eines Blinden (oder ein Suchmaschinen-Bot) würde das sicher sehr begrüßen. Aber das wird wohl noch auf lange Zeit ein unerfüllter Wunschtraum bleiben, vor allem solange Firmen wie Adobe oder Microsoft damit ihr Geld verdienen wollen.
TdZ schrieb:
Ich bin mir da nicht so sicher, zumal XHTML für mich endlich eine logische Alternative zur HTML 4.0-Katastrophe darstellte...
Kann ich sehr gut nachvollziehen.
TdZ schrieb:
Und da geht's schon los: Adobe sieht mit Flash seine Felle davonschwimmen und wettert mächtig dagegen. Auch MS scheint nicht so glücklich damit zu sein, das Randgruppendasein von Silverlight in Zukunft noch intensiver zu fristen.
Ist ja wohl beides recht verständlich, trotzdem bin ich als intensiver Internet-Nutzer bestimmt nicht traurig wenn diese beiden Dinge verschwinden würden. Okay Silverlight hab ich noch nie gesehen, wird auf meiner Linux-Kiste wohl auch nicht passieren, und beim Flash tät ich ein paar Online-Games vermissen. Aber es gibt ja noch Java-Applets (nein, bitte keinen Flame-War).
Grüße
Erik
-
die paar Seiten, die ich mal gestaltet hab, waren auch soweit XHTML1.0-Strict- bzw. XHTML1.1-valide. Aber je größer ein Projekt wird, desto schwieriger wird es mMn, sich daran zu halten
Normales HTML empfand ich immer als zu schwammig
mit HTML5 hab ich noch nicht gearbeitet, begrüße aber diverse Änderungen
-
Hallo,
zwutz schrieb:
Aber je größer ein Projekt wird, desto schwieriger wird es mMn, sich daran zu halten
Wieso? Das kann ich nicht nachvollziehen. Was wird bei großen Projekten am zu Grunde liegenden (X)HTML-Code anders?
Grüße
Erik
-
erik.vikinger schrieb:
zwutz schrieb:
Aber je größer ein Projekt wird, desto schwieriger wird es mMn, sich daran zu halten
Wieso? Das kann ich nicht nachvollziehen. Was wird bei großen Projekten am zu Grunde liegenden (X)HTML-Code anders?
Allein die ganzen Browser Bugs die man beachten muss produzieren eine Menge Workarounds. Desto strikter das HTML ist, desto umstaendlicher sind die Workarounds.
Wobei natuerlich ein strengeres HTML schon gut ist, man will ja den Quirks Mode der Browser unbedingt vermeiden - aber alleine die Idee den Content-Type von XHTML aus xml zu aendern war ja ein Schuss ins Knie.
Im Web dreht sich alles um kompatibilitaet. Man muss heute noch den IE 6 supporten, das ist mit XHTML einfach nicht moeglich. Natuerlich kann man mit genuegend Aufwand jede Seite XHTML strict bekommen, aber wo ist der Sinn?
Wer zahlt diese zusaetzliche Arbeitszeit? Alleine der CDATA Schwachsinn ist ne Kastastrophe bei aelteren Browsern...
HTML ist eben kein XML, da die Tags semantische Bedeutung haben. style, br, hr, table, script, object, param,... das sind alles semantische Tags - das funktioniert in reinem XML einfach nicht gut.
Die Idee von XHTML war ja gut, da sagt ja auch niemand was dagegen, aber in der Praxis hat es sich als nicht tragbar erwiesen. Der Hype um HTML 5 hat schon seinen Sinn, das ist ein guter HTML Standard der viele Probleme loest (waehrend XHTML ja keine Probleme geloest hat). Denn das ist der Punkt wo XHTML versagt hat: es bietet mir als Entwickler keinen Mehrwert. Und die Idee dass man dadurch leichter den Quirksmode umgehen kann, das hat ja nicht funktioniert.
Bei HTML 5 ist eigentlich nur schade dass die freien Codecs fuer audio und video nicht standardisiert worden sind, aber damit laesst sich leben.
PS:
um es nochmals klar zu machen:
HTML 5 loest effektiv Probleme die heute die entwickler plagen.
Und genau das muss ein Standard machen.
-
Hallo,
Shade Of Mine schrieb:
Allein die ganzen Browser Bugs die man beachten muss ....
Okay, das ist ein Argument. Mit so was hatte ich es noch nie zu tun, ein so komplexes Design hatte ich noch nicht. Einige meiner Seiten hat der IE verhunzt aber in allen anderen Browsern die ich getestet habe sah alles wie gewünscht aus und das hat mir gereicht (ein Browser, der es nicht mal schafft die paar Basics deren Einsatz ich fähig bin ordentlich dar zu stellen, beachte ich auch nicht weiter). Ich das bei vielen Web-Designern die IE-Tauglichkeit sehr wichtig ist, dieses Übel ist an mir glücklicherweise vorüber gegangen und daher kann ich nicht sehen wo XHTML dabei eine Einschränkung ist.
Shade Of Mine schrieb:
HTML 5 loest effektiv Probleme die heute die entwickler plagen. Und genau das muss ein Standard machen.
Da gebe ich Dir natürlich recht.
Auch wenn ich persönlich der Meinung bin das man in einer Zeit, wo jeder mit kaum Aufwand einen ordentlichen Browser benutzen kann, solche Unsinns-Browser wie den IE nicht unbedingt beachtet werden müssen. Wenn einfach alle Web-Designer plötzlich aufhören würden den IE explizit zu unterstützen wäre dieser entweder ruck zuck weg oder von Microsoft in einen ordentlichen Zustand versetzt. (bitte auch hierzu keinen Flame-War)Grüße
Erik
-
erik.vikinger schrieb:
Wenn einfach alle Web-Designer plötzlich aufhören würden den IE explizit zu unterstützen wäre dieser entweder ruck zuck weg oder von Microsoft in einen ordentlichen Zustand versetzt. (bitte auch hierzu keinen Flame-War)
Facebook und Google haben den offiziellen Support vom IE 6 eingestellt, das wird eine Menge erreichen.
-
Shade Of Mine schrieb:
erik.vikinger schrieb:
Wenn einfach alle Web-Designer plötzlich aufhören würden den IE explizit zu unterstützen wäre dieser entweder ruck zuck weg oder von Microsoft in einen ordentlichen Zustand versetzt. (bitte auch hierzu keinen Flame-War)
Facebook und Google haben den offiziellen Support vom IE 6 eingestellt, das wird eine Menge erreichen.
Es gibt leider genug Leute die idiotische Aussagen verfolgen, wie "Never change a running system", oder "Updates verlangsamen das System". Und solange es solche DAU gibt, gibt es auch veraltete Browser..
-
JanJan schrieb:
Es gibt leider genug Leute die idiotische Aussagen verfolgen, wie "Never change a running system", oder "Updates verlangsamen das System". Und solange es solche DAU gibt, gibt es auch veraltete Browser..
Der Leitsatz "Never change a running system" ist eine der am häufigsten missverstandenen IT-Empfehlungen überhaupt. Abgesehen davon, dass es sich um einen deutschen Pseudo-Anglizismus handelt (im angloamerikanischen Sprachraum nutzt man diesen Spruch nicht, sondern nur in Deutschland – ähnlich wie das Wort "Handy"), dient dieser Satz in der Regel dazu, ein fehlendes Patchmanagement für Betriebssysteme und Applikationen zu rechtfertigen. Berechtigt ist das praktisch nie.
Der Spruch leitet sich von der Sportweisheit "never change a winning team" ab. Jeder halbwegs fähige Trainer weiß aber, dass selbst das nur für sehr begrenzte Zeit gut geht, weil das Team dann eben nicht mehr gewinnt. Die Aufgabe eines guten Teamchefs besteht darin, sein Team weiterzuentwickeln, damit es besser wird oder zumindest seinen Status nicht verliert. Selbst die Mannschaft von Bayern München wird ständig umbesetzt, obwohl es mehr als den Meistertitel in der Bundesliga kaum zu gewinnen gibt.
Bei dieser falsch verstandenen und falsch angewandten Binsenweisheit geht es nicht darum, ein System nie zu patchen, weil es grundsätzlich läuft, also in Betrieb ist. Im Gegenteil geht es nur darum, ein System nicht in genau dem Moment in seiner Funktion zu verändern, in dem kritische Prozesse darauf von den Anwendern aktiv benötigt werden! Heißt also: Wartungsfenster definieren, statt einfach die Maschine zu patchen.
Aus Sicht der Sicherheit und Stabilität eines Systems kann es nur lauten: Patch your stuff! Nicht umsonst lautet die idiomatische Entsprechung zu unserem nicht so richtig englischen Sprichwort "if it ain't broke don't fix it" – wenn es nicht kaputt ist, dann repariere es nicht. Warum aber erscheinen Patches und Service Packs? Nur deshalb, weil im Herstellersupport festgestellt wurde, dass der ursprüngliche Code fehlerhaft ist. Das System ist also bereits kaputt – und daher muss es repariert werden!
Die richtige Einstellung ist also, ein aktives Patch- und Updatemanagement zu betreiben. Die technische Infrastruktur dafür existiert seit Jahren. Ein professionelles Patchmanagement in einem kleineren oder mittleren Unternehmen muss auch nicht ständig Arbeitskraft binden: Mit Virtualisierungs-Laboren lassen sich die kritischen Systeme schnell simulieren und die Auswirkungen von Patches und Service Packs prüfen. Läuft das Testsystem danach noch, kann der Patch produktiv eingesetzt werden. Da die meisten Patches deinstallierbar sind (bei den Ausnahmen ist dies in der Regel dokumentiert), ist auch das Fallback-Verfahren bekannt, es braucht nur eine gewisse Aufmerksamkeit.
-
Shade Of Mine schrieb:
Allein die ganzen Browser Bugs die man beachten muss produzieren eine Menge Workarounds. Desto strikter das HTML ist, desto umstaendlicher sind die Workarounds.
Das kann ich nicht bestätigen. Meine Faustregel: Desto einfacher die Mittel, desto weniger Workarounds. Ich brauche eigentlich trotz strict so gut wie keine Workarounds mehr.
Shade Of Mine schrieb:
Im Web dreht sich alles um kompatibilitaet. Man muss heute noch den IE 6 supporten, das ist mit XHTML einfach nicht moeglich. Natuerlich kann man mit genuegend Aufwand jede Seite XHTML strict bekommen, aber wo ist der Sinn?
Wer zahlt diese zusaetzliche Arbeitszeit? Alleine der CDATA Schwachsinn ist ne Kastastrophe bei aelteren Browsern...
Den IE6? Das ist völlig übertrieben meiner Ansicht nach. Ich hab vor über nem halben Jahr aufgehört, den zu supporten, weil dir DAS nämlich niemand bezahlt, so sieht's in der Realität aus.
Shade Of Mine schrieb:
HTML ist eben kein XML, da die Tags semantische Bedeutung haben. style, br, hr, table, script, object, param,... das sind alles semantische Tags - das funktioniert in reinem XML einfach nicht gut.
Shade Of Mine schrieb:
PS:
um es nochmals klar zu machen:
HTML 5 loest effektiv Probleme die heute die entwickler plagen.
Und genau das muss ein Standard machen.Da geb ich dir Recht, auch wenn ich's nicht gutheiße. Endverbraucher bzw. Entwickler sind doofe Herdentiere, die brauchen ab und an mal einen Leithammel, der den Ton angibt
-
TdZ schrieb:
Den IE6? Das ist völlig übertrieben meiner Ansicht nach. Ich hab vor über nem halben Jahr aufgehört, den zu supporten, weil dir DAS nämlich niemand bezahlt, so sieht's in der Realität aus.
Unsere Kunden haben zu einem relevanten Anteil den IE6 im Einsatz. Desto größer das Unternehmen, desto älter die Software. Das Problem ist, dass Windows XP immer noch das standard OS ist. Und der Standard Browser auf XP ist eben IE6, der IE7 macht fast nur Probleme. Ich sehe es ja bei uns, wir haben überall Firefox im Einsatz und eben IE7 oder IE8 installiert (je nach patchlevel des PCs) und der Administrationsaufwand ist durch das update von IE6 angestiegen.
Wir hatten letztens auch einen ziemlichen Stress weil der IE6 support bei einer Webseite nicht gut genug war.
Hängt natürlich von den Kunden ab, bei unseren ist IE6 support einfach notwendig. Vermutlich nur wegen der Marketingabteilung des Kunden und nicht wegen den Besuchern der Seite.
Ich hoffe dass die Sache ende des Jahres besser aussieht.
-
Die legen gerade wert darauf das alles gleich aussieht.
Deswegen sind die ja nicht Super strict.
Weil das sieht dann überall anders aus.!
-
egal schrieb:
Die legen gerade wert darauf das alles gleich aussieht.
Genau das ist ja der Schwachsin! Solange es verschiedene Monitore gibt kann eine Webseite nicht überall gleich aussehen. Pixel-Genaues Web-Seiten-Layout ist auf einem Monitor mit sehr hoher Auflösung ein Grund die betreffende Seite nicht zu benutzen da der Text oft unlesbar klein ist, aber wenn man den Browser zwingt eine lesbare Schriftgröße zu benutzen dann zerfällt das Design und ist fast unbenutzbar.
egal schrieb:
Deswegen sind die ja nicht Super strict. Weil das sieht dann überall anders aus.!
Warum sollte das so sein?
Meine kleinen Seiten, alle XHTML 1.1 strict, sehen in den unterschiedlichsten Browsern extrem ähnlich aus. Unterschiede entstehen vor alllem durch unterschiedliche Default-Schrift-Arten/Größen in den Browsern bzw. Betriebssystemen. Von den Proportionen her bleiben die Seiten aber immer fast perfekt identisch und wenn der User des Browserfenster verkleinert dann funktioniert immer noch alles und sieht immer noch konsistent aus.Ich denke das meine Seiten gerade wegen XHTML strict sich auf den unterschiedlichsten Systemen/Browsern/Bildschirmen so konsisten verhalten und immer benutzbar sind.
-
Guest123 schrieb:
Ich denke das meine Seiten gerade wegen XHTML strict sich auf den unterschiedlichsten Systemen/Browsern/Bildschirmen so konsisten verhalten und immer benutzbar sind.
Nope, hat garnichts mit XHTML zu tun. Funktioniert unter HTML genauso.
-
Shade Of Mine schrieb:
Unsere Kunden haben zu einem relevanten Anteil den IE6 im Einsatz.
http://www.heise.de/newsticker/meldung/Internet-Explorer-6-soll-sterben-993065.html
MfG SideWinder