Wechsel von XHTML 1.0 zu HTML 5

Synonym

So, mal eine andere Frage in die Runde. Hoffe, dass es dazu nun hier ein paar Erfahrungen gibt

Wie sieht denn nun mit HTML5 aus. Offiziell ist es noch noch nicht, doch wenn man danach gehen würde, dann könnte man wohl noch lange warten.

Vieles habe ich schon gelesen, doch die seinen sagen "hü", die anderen "hott". Macht es derzeit Sinn, ein bestehendes Projekt von XHTML 1.0 nach HTML 5 zu ändern oder eher nicht? Spezielle HTML5-Elemente würde ich nicht brauchen, wobei ich da nun eigentlich denke, dass dann die "alten" Browser kompatibel mit sind. Manche sagen ja. Doch ist dem wirklich so?

Vorteile sehe ich eigentlich so direkt bei HTML5 keine, doch die ganzen Dinge wie Opengraph, SocialButtons, Schema.org etc. sind dort halt besser zu integrieren.

Nur hat das dann irgendwelche Nachteile in Sachen SEO und viel mehr in Sachen Browser? Es gibt da ja so ein Javascript als HTML5-Ersatz für den IE", aber das will ich nicht einsetzen. Braucht man das bei einem normalen Grundgerüst?

Jemand Erfahrungen damit? Wäre doch schön, wenn hier mal ein paar andere Themen als "OffTopic" auftauchen

Fridolin: Bitte keine Diskussion, ob Opengraph, SocialButtons, Schema.org sinnvoll sind oder nicht

Alex07

also ich persönlich warte noch mit html5. läuft doch auch so, oder?
hab mich ehrlich noch nicht beschäftigt, werde das aber bei meiner html seite ausführlich ausprobieren und unter die lupe nehmen
*** Link veraltet ***
muss mich da reinfuchsen

guppy

x5 evolution Version 9 - schreibt schon in html5, vereinfacht die ganze Sache sehr und hat einige Features drin, nicht notwendig aber nice to hv it. Und vor allem valide. Für die Hauptdomain nehm ich es derzeit auch noch nicht aber alle Satelliten, die verändert werden oder neu entstehen nur noch damit, erleichtert mir die arbeit schon - ich sehe in html5 keine Nachteile, also alles was neu gemacht wird - warum nicht?

x5 evol. ist allerdings nur begrenzt SEO tauglich, nur falls jemand meiner Empfehlung folgt.

Synonym

Hm, ist dann also doch wohl wirklich Einstellungssache. Einen wirklichen Grund habe ich zur Umstellung halt eben nicht. Nur "verschlafen" möchte ich auch nicht. Bezüglich SEO meinte ich auch eher, ob es Nachteile bringen könnte, wenn man die dort vorhandenen Möglichkeiten (Navi, Artikel, Header und was es da alles gibt) extra nicht nutzt und weiter macht wie bisher um alte Browser nicht zu benachteiligen.

Dieses ganze Social-Zeugs kann man auch in HTML4 reinfrickeln, das ist nicht das Problem. Wobei ich etwa mit schema.org noch keine Lösung gefunden habe. Da ist alles HTML5. Das wäre auch der einzige Grund, warum ich die Überlegungen überhaupt habe. "Rich Snippets" und das mit schema.org. Wobei ich da dann noch nicht mal weiß, ob es das bringt was es soll, wäre also nur ein Test.

Hm, werde mich dann wohl doch noch etwas umsehen, lesen, vergleichen und abwarten.

800XE

Zitat von Synonym;8350

ob es Nachteile bringen könnte, wenn man die dort vorhandenen Möglichkeiten

dieses "Blder in den Seitencode einbinden" ist doch HTML5?

und diese "Sprites" ... sind das genau diese Bilder? (da war letztens ne Doku wo ich unwissend ....

Sprites sind zum Beschleunigen
Wie kommen die BIlder in die Seite? Wie Bilder in einen eMail Attachment, als ALpha5-Code ..... das macht doch die Datenmenge größer
also wird es eher langsamer als schneller
aber, Jemand sagte das es darum geht das weniger Verbindungen zum Server hergestllt werden müßen, und Jede Verbindung selbst vom neuen die Geschwindigkeit ausmessen tut ... also langsam schneller wird ..... dadurch kann eine großße Datei schneller gehen wie 10 kleinere die in Summe kleiner sind wie die größere

bazillus

Zitat von 800XE;8365

und diese "Sprites" ... sind das genau diese Bilder? (da war letztens ne Doku wo ich unwissend ....
...
aber, Jemand sagte das es darum geht das weniger Verbindungen zum Server hergestllt werden müßen, und Jede Verbindung selbst vom neuen die Geschwindigkeit ausmessen tut ... also langsam schneller wird ..... dadurch kann eine großße Datei schneller gehen wie 10 kleinere die in Summe kleiner sind wie die größere

Korrekt, aber das ist imho CSS. Bei Sprites packst Du alle Einzelbilder in eine einzige Bilddatei. Dadurch muss nicht für jedes Bild eine neue Verbindung aufgebaut werden, sondern sie werden als ein Bild runtergeladen. Hübsch veranschaulicht in *** Link veraltet *** für den FF unter em Punkt "Netzwerk". Die Anzahl der HTTP-Request (begrenzt!) wird so verringert - den Rest erledigt CSS.
Vorteil liegt klar bei vielen kleineren Dateien, wo unzählige Request- und Response-Header die Übertragung ausbremsen.

guppy

Zitat von bazillus;8366

Vorteil liegt klar bei vielen kleineren Dateien, wo unzählige Request- und Response-Header die Übertragung ausbremsen.

Du meinst, der Nachteil?

Synonym

Ja ne, der Vorteil liegt da - der Vorteil der Sprites. Aber was bitte haben nun Sprites mit HTML5 zu tun??

Ich weiß schon, was der 800er hier auf seine Art sagen will, aber ist nicht unbedingt das was ich meine. Es geht mir nicht um Bilder / Videos, 3D, Canvas etc. sondern hier viel mehr um die Seitenbeschreibung und die klare Trennung / Auszeichnungen von <header>, <nav>, <footer> etc. Das sind ja eigentlich die klaren Vorteil bei der Strukturierung aber eben auch die klaren Nachteile bei alten Browsern. So, und wenn man die dann daher nicht verwendet, ob das negativ angesehen werden könnte - das meine ich in Sachen SEO.

bazillus

Hm, etwas unglücklich formuliert. Der Vorteil bei der Nutzung von Sprites macht sich vorallem bei vielen kleineren Dateien, wo unzählige Request- und Response-Header die Übertragung ausbremsen, bemerkbar.

so?

/edit: Synonym war schneller... sry für OT

bretterelse

html5 bietet eine bessere Semantic und davon spricht man doch immer mehr. Hier dürfte die Gliederung durch die Suchmaschinen besser verstanden werden und somit müsste der Content mehr Wertung bekommen?

Auch finde ich es ganz praktisch beim "entwickeln", so kann man sich einige class/id sparen (und schlanker schreiben)

header nav {..
footer nav {..
aside {..
article {..
section {..

so könnte man doch den header im code nach dem Content platzieren, dennoch weiß "google" das es ein header ist [ohne die css auszuwerten?]

Warum willst du nicht das ie-js einsetzen? Dieses js bringt dem alten Browser nur die neuen Tags bei. Durch eine Weiche auch nur dann geladen, wenn es nötig ist.

Nachteil: man muss schon tabellenfreies Layouten beherrschen, sonst hat es nicht so viel Sinn?!

Sprites haben nichts mit html5 zu tun. Google-Page-Speed empfiehlt jedoch den Einsatz dieser.

Synonym

so bretterelse, nun kommen wir ja an den Punkt. Das JS mag ich eigentlich deswegen nicht, da ich ungern irgendwelches Gefrickel über JS löse - hab da schlechte Erfahrungen mit gemacht und kann es hier auch nicht wirklich testen. Betrifft ja nicht nur IE6, sondern auch 7 und teilweise 8. Mac? Und andere? Keine Ahnung und nicht testbar. Aber ohne das JS gibt es die "neue" Strukturierung auch nicht, würde also alles beim Alten bleiben, nur der Doctype halt nicht. Daher meine Vermutung, dass das eher schlechter angesehen wird als HTML4, das man so umsetzt wie es ist und nicht HTML5, wobei man dennoch nur "Syntax" von HTML4 verwendet.

Vom Layout her wäre es kein Problem. Tabellen gibt es nur da, wo es wirklich Tabellen gibt Und diese immer wieder angesprochenen Sprites... Ja, ich weiß was das ist und nutze die auch schon 2 Jahre

Wobei mein eigentlicher Grundgedanke, nämlich die Umstellung wegen OG, FB etc. schon wieder etwas verworfen ist. Hab mir das gestern und heute angesehen und durchgetestet mit HTML5 und was soll ich sagen? Die haben schon wieder einiges geändert und mit reinem HTML5 geht es nun auch nicht. Namespace wurde mal wieder umbenannt / verschoben, HTML5 alleine reicht nicht, wenn schon XHTML5 (weitere Probleme im IE) oder HTML+RDFa (nicht wirklich spezifiziert). Also ist da aktuell das gleiche Spiel wie mit HTML4 (bzw. XHTML 1.0), nämlich ein wirres Durcheinander.

Werde da nun wohl doch bei HTML4 bleiben...