Zitat:
Es wird einige neue Elemente geben, das DOM wird geändert und einige vorhandene Elemente bekommen neue Attribute (bspw. PING). Sowie man diese Sachen ernsthaft nutzen wird, kommt man um Browserweichen nicht mehr rum.
|
Wozu brauchst du eine Browserweiche, wenn das neue Element oder Attribut bei alten Browsern
keinerlei Schaden anrichtet? Was du auch mit »ernsthaft nutzen« meinst — es unterscheidet sich sehr vom Einsatzzweck des HTML 5. Wenn sich irgend etwas davon nicht einfach einsetzen läßt, dann wird das einfach niemand benutzen. Und damit haben wir dann auch kein Problem.
Ping selbst ist übrigens ein Beispiel für ein Attribut, dem ich kein langes Leben zutraue. Es ist einfach nicht sicher genug.
Zitat:
Welche Elemente sollen das sein? Ich sehe da an neuen Elementen solche wie NAV, SECTION, ARTICLE, FOOTER oder ASIDE und die kennt noch kein Browser.
|
Ich meinte Sprachelemente, also auch Attribute und bestimmte Attributwerte. _charset_ oder designmode beispielsweise. Außerdem wird endlich eine
brauchbare Fehlerbehandlung kodifiziert; ein großer Mangel sowohl in HTML (hat nahezu keine) und in XHTML (bestraft auch Leser). Schon allein das ist in meinen Augen eine Rechtfertigung für diese neuen Spezifikationen.
Zitat:
Der UA wird den Inhalt versuchen darzustellen. Dabei wird er jedoch sämtlich Style-Angaben für das unbekannte Element ignorieren, sodass (um beim Beispiel des neuen NAV-Elements zu bleiben) die Navigation ohne die Formatierungen des Element angezeigt wird. Ohne Browserweichen oder zusätzliche (eigentlich unnötige) Elemente, kommt man da also nicht drumherum.
|
Bei manchen Elementen werden die alten Mechanismen auch weiterhin gebraucht, richtig. Aber die neuen Features bieten einen
zusätzlichen Nutzen für den Besucher und schaden denjenigen nicht, die sie nicht interpretieren können. Als Beispiel seien die neuen Werte für Eingabefelder genannt, die dann leichter clientseitig validiert werden können.
Zitat:
Content Negotiation ist nicht unsicher. Clientseitig gibt es dagegen keinen gangbaren Weg, der nicht Hacks, Scripte oder proprietäre Browsererweiterungen benötigt.
|
Content-Negotiation funktioniert nur, wenn man das Caching in Proxies zuverlässig kaputtmacht und sich immer auf die HTTP-Header verlassen kann. Was ist daran zuverlässig?
Clientseitige Weichen hingegen funktionieren unabhängig vom Transportverfahren und fragen genau die Browserfähigkeiten ab, die man einsetzen will (so es vernünftig gemacht wird natürlich).
Zitat:
Die angebliche Rückwärtskompatibilität von HTML5 ist und bleibt ein Märchen, welches sich wohl noch solange halten wird, bis die ersten Seiten im Netz auftauchen und sich alle wundern, wie sch....e die doch in HTML<5 Browsern aussehen.
|
Wenn das der Fall sein sollte, und das bezweifle ich sehr, dann wird niemand HTML 5 benutzen. Na und?
Zitat:
Da stecken viele sinnvolle Ideen drin. Es kommt aber einfach Jahre zu spät und eine neue HTML-Version braucht heute keiner mehr.
|
Besser spät als niemals. Und es wird auch ein XHTML-Modul mit den WHAT-WG-Erweiterungen geben, daher brauchst du dir darum eigentlich keine Sorgen machen.
[XHTML 2]
Zitat:
Anstatt, dass die Leute der WHATWG dies nun unterstützen und ihre Ideen dort sinnvoll einbringen, machen sie lieber was neues und verzögern die Verabschiedung von XHTML2 damit. Reife Leistung!
|
Wie und warum die WHAT-WG überhaupt entstanden ist: Weil in den (X)HTML-Arbeitsgruppen diejenigen in der Mehrzahl sind, die keine Browser entwickeln, sondern eben diese Leute eine pragmatische Weiterentwicklung so lange verhindert haben, bis man aus der Not heraus eben in einer parallel arbeitenden Gruppe zusammengefunden hat. Die Verzögerung von XHTML 2 haben ganz allein diejenigen verschuldet, die damit befaßt sind.
Zitat:
Doch, die Aufregung lohnt sich, da die WHATWG nichts anderes erreichen wird, als dass es bald noch einen weiteren pseudo-Standard gibt und damit das Wirrwar an Standards und der Browserunterstützung noch weiter zunimmt.
|
Nix Pseudo. HTML 5 wird nach Fertigstellung beim W3C eingereicht und dort den ganz normalen Standardisierungsprozeß durchlaufen. Das wird niemandem schaden, sondern einfach die Wahl erweitern.
Zitat:
Außerdem hat die Aussicht auf HTML5 Microsofts Entschluss, dass auch der IE7 noch kein XHTML unterstützen wird, sicherlich teilweise mit beeinflusst. Der IE7 wird zwar keine HTML5 verstehen, das ganze hin und her kam MS aber sehr gelegen und so lässt man alles erst mal beim alten.
|
Das ist doch nicht dein Ernst? Wofür welche Ressourcen bei Micrososft eingeteilt wurden, weiß nur Microsoft allein; eine echte Notwendigkeit für XHTML besteht ja bis heute sowieso nicht. Dies der WHAT-WG anzukreiden halte ich für sehr abwegig.
Gruß
Thomas