Pfui.
Ich bin zwar nicht der größte aller Experten, aber ich habe XHTML immer bevorzugt. Da einfach besser als HTML 4. Jetzt wollen wir mal hoffen, dass HTML 5 da einiges ändert, sonst bin ich aber richtig beleidigt

hmmm.. weiß nicht recht, was ich davon halten soll. die ansätze in xhtml2.0 schienen mir irgendwie runder, als die etwas inkonsistenten conventions von html5. habe mich aber auch noch nicht "in depth" damit beschäftigt. die festlegung auf einen der standards halte ich aber für durchaus sinnvoll.

html ist nicht xml ... Naja! <br> oder sauber: <br/> ... meiner Meinung nach soll HTML abgelöst werden und nur XHTML, damit alle XML Parser alle Webseiten auslesen kann ...

Leider ist das Web so furchtbar komplex, dass XHTML nicht ausreichen wird. Dazu gibts einfach zu viele Seiten, die nicht standard-konformes HTML verwenden. Die Browser müssen diese Seiten auch unterstützen, daher ist wohl wirklich sinnvoller, sich auf HTML 5 zu konzentrieren und XHTML auslaufen zu lassen.

Support für HTML 5 sollte oberste Priorität haben. Umso schneller ich auf Flash verzichten kann, umso besser. Also macht hinne YouTube und co

Ich bin ja nach wie vor dafür, dass man bei einer neuen Version von HTML oder XHTML den Browser anweist, Fehler zu melden und fehlerhafte Webseiten gar nicht erst anzuzeigen.

tzi
Viel Spass dann beim Surfen. Praktisch bedeutet das, dass du fast gar keine Seite besuchen kannst.

Bravo. HTML 5 bringt zusammen, was zusammen gehört.

Die Browser könnten für die schlechten Seiten ihren Quirks-Modus verwenden, wie sie es bisher auch tun. Wenn man sich nur nach schlecht gemachten Seiten richtet, dann braucht man auch keinen Standard zu definieren!

Für HTML kann man wohl schlecht XML-Werkzeuge benutzen, ich sehe auch keinen zwingenden Grund HTML weiterzuentwickeln.


BTW: Gibt es für CSS inzwischen eine Möglichkeit Farben in nicht-sRGB-Farbräumen anzugeben?

Würde eine Seite von den Browser nicht geparst werden, wenn Sie nicht XHTML konform wäre gäbe es das Problem nicht.

@Schildie
Dass HTML 5 nicht nur ein Nachfolger von HTML 4 ist, sondern auch XHTML beinhaltet, weißt Du aber schon, oder?
Und was daran ist „einfach besser“? Ich sehe den einzigen Vorteil, dass es von einem XML-Parser gelesen werden kann. Aber warum sollten meine Webseiten ausgerechnet von einem XMP-Parser gelesen werden können müssen? Mein Adressat sind Webbrowser, und da war mir XHTML bisher immer irgendwie zu kompliziert:
* Unterschiede in der Browserkompatibilität je nach MIME-Type (z.B. text/html oder text/xml) zur Auslieferung des XHTML-Markups
* Der XHTML-Code, den ich über XSLT generiere, wurde prompt von gewissen Browsern nicht korrekt verarbeitet, wenn als text/html ausgeliefert, da der generierte XHTML-Code wo möglich "/>"-geschlossene Tags verwendete. Der IE zeigte z.B. wegen <script.../>-Tags im Header einfach nur eine leere Seite, da er den Slash nicht verstand und die ganze Seite als Script interpretierte. Bei manuell erzeugtem Code konnte man das durch Verwendung eines expliziten schließenden </script>-Tags umgehen, aber mein Code wird ja generiert.

Jetzt generiere ich vorerst wieder HTML 4.01 Strict. Meinen XML-Quellen ist's eh egal, ich könnte das jederzeit umstellen.

man sollte in seinem standardkonformen html5 dokumenten einen hinweis für den browser einbauen können, dass dieser ohne fehlerkorrektur drauf los parsen darf..
als gegenleistung muss der browser dann die seite mit einer blauen icq-blume in der oberen rechten ecke belohnen.

Schildie:

Zu Deiner Beruhigung sei angemerkt, dass HTML5 nicht nur Nachfolger von HTML4 sein soll, sondern als XHTML5 in XML-Schreibweise, wie Du es aus XHTML 1/XHTML1.1/XHTML 2 ebenfalls existiert.
Im Fokus des allgemeinen (Medien-)Interesses ist leider lediglich HTML5, obwohl XHTML5 gleichzeitig und ebenfalls eine Daseinsberechtigung hat. Beide unterscheiden sich nur marginal und aufgrund der XML-Schreibweise und der XML-Gesetzlichkeiten in sehr ähnlichen Punkten wie das bisher zwischen HTMl 4.01 und XHTML 1.0 ist. Ausschlaggebend für die Unterscheidung ist wie bisher sicherlich u.a. der Mimetype, ob ein Dokument nun ein echtes XML-basiertes XHTML-Dokument ist (application/xhtml+xml oder application/xml) oder lediglich ein SGML-basierts HTML-Dokument (text/html).

An diesen Dingen hat sich im Grunde nichts geändert, und alle positiven Dinge und Erfahren, die man bisher mit XHTML 1.0/XHTML 1.1 und XHTML 2.0 sammeln konnte, sind in HTML 5 bzw. XHTML 5 eingeflossen.
Da wird also nicht sehr viel über Bord geworfen, sondern in großen Teilen weiterverwendet (wenn man mal von einigen Ausnahmen bzgl. XHTML 2 absieht).

Siehe dazu u.a. auch diese schöne Gegenüberstellung von Jens Meiert aus dem Jahre 2007:

HTML 5 und XHTML 5 im Vergleich (WHATWG)

wegen dem Nichterscheinen von XHMTL2 und dem Erscheinen von HTML5 werden die anderen HTML-Versionen und XHTML-Versionen weiterhin von den aktuellen Browsern unterstützt.

Johloemoe:

Nicht nur die. Sondern mit Sicherheit auch diese beiden Firmen: Microsoft und vor allem auch Apple. Nämlich in Bezug auf einen frei verwendbaren Video-Codec für deren Web-Browser, wo sich beide Firmen Ogg Theora gegenüber bisher nämlich sperren und (zumindest Apple) H.264 bevorzugt (Apple gehört meines Wissens bei H.264 sogar u.a. zu den LizenzGEBERN).

Entweder Ogg Theora wird von beiden Firmen implementiert, oder H.264 sollte auf einer Royalty-free-Basis zumindest für diesen begrenzten Rahmen kostenfrei zur Verfügung gestellt werden (und dagegen sperrt sich derzeit u.a. auch Apple bzw. unterlässt es diesbzgl. seine Einflüsse auf die MPEG-Group geltend zu machen).

Apple spielt da im Moment jedenfalls keine rühmliche Rolle indem Spiel und geriert sich als Bremser für ein Problem, welches ziemlich drängend ist (weil es die Hürde für Anwender senkt, eigene, produzierte Videos online zu stellen) und HTML5/XHTML5 einen ziemlich Schub an Akzeptanz verleihen würde, wenn dieser Knoten endlich gelöst würde.

Es ist nämlich noch was Anderes zu beachten: die bisherigen Lizenzen für H.264 laufen nächstes Jahr aus, und es sind ab da noch höhere Lizenzgebühren dafür zu erwarten. Youtube/Google wird das sicher auch kalkulieren, ob sie bereit sind, ab dann NOCH höhere Lizenzgebühren bzgl. H.264 abzudrücken, Google fährt ja jetzt schon zweigleisig und unterstützt sowohl H.264 als auch Ogg Theora. Von den zu erwartenden Lizenzgebühren für den einfachen User, der einfach nur mal eben schnell sein eigenes, selbst produziertes Video hochladen will, mal ganz zu schweigen. Ein lizenzfreier bzw. lizenzbefreiter Codec würde da sicher so EINIGES erleichtern...

Zu diesem empfindlichen Thema siehe u.a. auch die aktuelle Diskussion (Thema "Codecs for <video> and <audio>") dieser Tage innerhalb der HTML Working Group: zurückgehend auf folgende Mitteilung von Ian Hickson vom 30. Juni: .

Ich hoffe, wenigstens Apple bewegt sich da mal langsam, ansonsten könnte das Problem noch für lange Zeit ein echter Bremsklotz für den Erfolg von HTML 5 werden.

ex_apple_user_neu:

Völlig korrekt.

HTML 5 ist sogar (in Grenzen) abwärtskompatibel bzgl. Browsern, die nicht hochaktuell sind. Als Beispiel sieh Dir mal die Homepage von Sam Ruby an: . Die ist komplett in HTML5 geschrieben und lässt sich auch mit Browsern anschauen, die nicht so aktuell sind und Firefox 3.5 oder Safari 4 heißen bzw. die eigentlich kein einziges HTML5-Element neuerer Browser implementiert haben.

Sam Ruby leitet inzwischen die HTML Working Group als sog. Chair, nachdem Dan Conolly seinen Sitz abgegeben hat; Ruby war bisher Co-Chair.

sirkb

mit welcher App produziert denn Ruby diese ganzen schlanken SVG Grafiken auf der Seite?

sierkb:

Streiche: HTML5
Setze: XHTML5

Retrax:

Weiß ich nicht. Im Quelltext fehlen entsprechende Meta-Informationen der SVGs. Wenn's Dich so brennend interessiert, frag' ihn.

Möglicherweise Inkscape?

Was ist ein App?

sierkb

ich glaube der macht das von Hand.... so schlanken SVG Code hab ich noch bei keinem WYSIWYG Prog gesehen: (z.b. das LG Logo)

Retrax:

Ob diese Grafiken alle von Hand gecodet sind, das wage ich zu bezweifeln (selbst für einen Vollprofi bzw. Koriphäe wie Ruby wäre das sicher zu zeitaufwendig, diese Zahlen und Koordinaten alle von Hand zu berechnen und zu coden), ich nehme aber mal an und traue das Ruby durchaus auch zu, dass er diese Grafiken mit einem entsprechenden Werkzeug erzeugt und bearbeitet hat und sie dann möglicherweise von Hand nachbearbeitet und optimiert hat.

Wie gesagt: frag' ihn, schreib' eine email hin!
Vielleicht existiert von ihm ja auch irgendein früherer Blogeintrag, der darüber Auskunft gibt, ich habe auf die Schnelle jetzt keinen darüber gefunden.

Jawohl! Wenn Apple sich endlich mal bewegen würde wäre die Welt gerettet!

ExRabbitPro:

Wie meinen? Ich nehme an, Du hast da den grinsenden Smiley vergessen?

sierkb

Ich denke er meint die Blockade gegenüber OGG Theora und Vorbis und die drohenden Lizenzgebühren für H.264. Die Lizenzgebühren sind auch der Grund weshalb es erstmal keine direkte Unterstützung für Video/Audio ohne entsprechendes Plug-In geben wird. Opera und Mozilla haben sich hauptsächlich dagegen gesperrt. Microsoft und Apple blockieren gegen OGG.

H.264 ist besser als OGG Theora, ich kann aber nachvollziehen, dass man sich gegen die Verwendung sperrt, wenn man es teuer bezahlen muss.

Immerhin sind die Videos auf der Apple-Website nicht mehr ausschließlich mit installiertem QuickTime-Plugin anzusehen.
Wann wurde dort eigentlich der neue Player eingeführt?

IMHO sind die HTML5 Audio/Video-Tags _leider_ noch "a bag of hurt". Kann mich daher nur mit Nachdruck anschließen:
Die Lizenzbefreiung von h.264 würde HTML5 einen schnellen und ruhmreichen Siegeszug bescheren.

bjbo:

Warum wohl? Weil sie im Zweifel die anfallenden Lizenzgebühren an den Benutzer weiterreichen müssten bzw. ihm dann den Schwarzen Peter überlassen würden, ob und wie er seine Videos erstellt bzw. das mit einem Programm tut, welches diese Lizenzgebühren bezahlt.

Das ist aber nicht das, was mit den neuen Video-Eigenschaften in HTML5 bezweckt werden soll. HTML5 soll/diese neuen Audio- und Video-Möglichkeiten sollen Hürden für Benutzer SENKEN, ihre Inhalte ins Web zu stellen und keine alten Hürden beibehalten oder sogar neue aufbauen!

Aus unterschiedlicher Motivation heraus. Apple, weil man (meines Wissens u.a. selber über die MPEG-Group am Lizenzgeschäft von H.264 beteiligt ist) und auch sonst systemseitig ziemlich eng an H.264 hängt bzw. das favorisiert; Microsoft, weil sie lieber gerne das eigene Silverlight pushen/schützen wollen bzw. dem ungerne einen Konkurrenten vor die Nase setzen wollen.

Die bisher von den Vertretern beider Unternehmen vorgebrachten Vorbehalte bzgl. irgendwelcher möglicherweise zu erwartenden UBoot-Patent-Trolle sind ziemlich durchsichtig vorgeschoben. Wenn Apple und Microsoft daran gelegen wäre, dieses Thema Ogg Theora auf möglicherweise versteckte Patentansprüche rechtlich wasserdicht abzuklopfen, dann htten sie das schon längst getan und ihre jeweiligen Anwalt-Armadas daraufhin angesetzt, genau das abzuchecken. Das ist bisher aber nicht geschehen. Mangels echtem Interesse an einer Lösung in dieser Richtung?

Genau das hat sich gerade geändert bzw. ändert sich gerade. Da ist u.a. viel Geld und Entwickler-Arbeit im Spiel, was dazu eingesetzt worden ist, Ogg Theora in dieser Richtung maßgeblich zu verbessern. Erste Ergebnisse lassen sich zeigen, und es wird auch noch weiter verbessert werden, sodass die Unterschiede kaum noch wahrnehmbar sind.

Ich schon.

hmm...

interessant.
irgendwie ist da 'n haken drin.

sierkb

also doch:

alles andere hätte mich bei dieser Geschmeidigkeit und Schlankheit der Code-Basis auch stark gewundert. Klasse. Einfach klasse.

Hier noch weitere Infos:

Wahnsinn! Das nenn' ich mal 'nen Geek!

corleone

mit VIM!! Das nerdet das ganze!