nicht angemeldet
suit
suit
Gunnar Bittersmann
Gunnar Bittersmann
molily
suit
Gunnar Bittersmann
Tim Tepaße
molily
molily
molily
molily
Gunnar Bittersmann
Die WHATWG meint ja, man solle die HTML 5 Features ruhig nutzen, auch wenn HTML 5 so noch gar nicht abgenommen ist:
http://wiki.whatwg.org/wiki/FAQ#When_will_we_be_able_to_start_using_these_new_features.3F
jetzt möchte ich z.b. das video-tag benutzen.
die frage ist nur welchen Doctype soll ich benutzen?
den von HTML 5? macht es überhaupt Sinn einen Standard zu verwenden, der noch gar keiner ist? Schließlich kann sich ja an HTML 5 noch so einiges ändern bis zum Release (wann ist das eigentlich?)
Die WHATWG meint ja, man solle die HTML 5 Features ruhig nutzen, auch wenn HTML 5 so noch gar nicht abgenommen ist:
das ist wunschdenken - ein hoch darauf, dass html 5 noch früh genug stirbt und einem ordentlich durchdachten xhtml 2.0 weichen uss
jetzt möchte ich z.b. das
video-tag benutzen.
die frage ist nur welchen Doctype soll ich benutzen?
wie wärs mit lesen des working-draft oder gehirn einschalten?
<!DOCTYPE HTML>
im übrigen wünsche ich gleich viel spass mit allen möglichen browsern ;)
den von HTML 5? macht es überhaupt Sinn einen Standard zu verwenden, der noch gar keiner ist?
siehe oben - es macht keinen sinn, solange es noch keine reccomendation gibt - was spricht gegen das object-element zum einbinden von filmen im flash-format?
Schließlich kann sich ja an HTML 5 noch so einiges ändern bis zum Release (wann ist das eigentlich?)
es kann sich noch einiges ändern und es wird sich noch einiges ändern (so uneinig wie sich die typen da sind) - "release": hoffentlich nie ;)
[latex]Mae govannen![/latex]
Die WHATWG meint ja, man solle die HTML 5 Features ruhig nutzen, auch wenn HTML 5 so noch gar nicht abgenommen ist:
das ist wunschdenken - ein hoch darauf, dass html 5 noch früh genug stirbt und einem ordentlich durchdachten xhtml 2.0 weichen uss
Das ist kein Wunschdenken, das ist Rechtschreibreform-Taktik. Erst mal einführen und dann die Nicht-Änderungen bzw. Rücknahme unsinniger Punkte damit begründen, daß es schon zu verbreitet sei. Die obige Empfehlung ist ein weiterer Grund, HTML5 nicht zu mögen. Es ist höchstens Wunschdenken der WHATWG, daß _alle_ Autoren zukünftige Änderungen gegenüber dem jetzigen Stand der Dinge nachtragen werden, wenn jetzt schon nicht standardisierte Verfahren genutzt werden. Oder auch kurz: WHATWG verbreitet unüberschaubares Chaos.
Cü,
Hi,
das ist wunschdenken - ein hoch darauf, dass html 5 noch früh genug stirbt und einem ordentlich durchdachten xhtml 2.0 weichen uss
*Das* ist "Wunschdenken"! :-))
<!DOCTYPE HTML>
im übrigen wünsche ich gleich viel spass mit allen möglichen browsern ;)
Der Zwinkersmiley ist wohl so zu deuten, daß Du diese Aussage nicht ganz ernst meinst, und, neben Amüsement, vielleicht etwas Unsicherheit verbreien möchtest?!
es kann sich noch einiges ändern und es wird sich noch einiges ändern (so uneinig wie sich die typen da sind)
Immerhin sind sie sich einig über die Ablehnung der Art, wie das W3C die Zukunft angehen wollte. :->
Gruß, Cybaer
<!DOCTYPE HTML>
Der Zwinkersmiley ist wohl so zu deuten, daß Du diese Aussage nicht ganz ernst meinst, und, neben Amüsement, vielleicht etwas Unsicherheit verbreien möchtest?!
nein, ich find nur den doctype etwas geschacklos bzw dass sich die html5-verschlimmbesserer herrausnehmen, einen "neutralen" doctype zu erfinden, der browser wirds schon verstehen, was gemeint ist
ich find den doctype-switch gut und eine genaue und möglichst exakte angabe sinnvoll
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml2.dtd">
warum kann da nicht folgendes stehen?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5//EN"
"http://www.w3.org/MarkUp/DTD/html5.dtd">
mir scheint so, als will man html 5 "irendwie durchwürgen" ohne sich über den genauen umfang im klaren zu sein und schaut mal nach, was die browserentwickler so alles implementieren
@@suit:
nein, ich find nur den doctype etwas geschacklos bzw dass sich die html5-verschlimmbesserer herrausnehmen, einen "neutralen" doctype zu erfinden, der browser wirds schon verstehen, was gemeint ist
Es sollte einem nicht validierendem Client genügen zu verstehen, dass 'html' gemeint ist.
ich find den doctype-switch gut und eine genaue und möglichst exakte angabe sinnvoll
Umschaltung der Darstellungsmodi anhand der DOCTYPE-Angabe sinnvoll?? Sag bitte schnell, dass das nicht dein Ernst ist!
warum kann da nicht folgendes stehen?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5//EN"
"http://www.w3.org/MarkUp/DTD/html5.dtd">
Weil es für HTML 5 keine DTD gibt.
Live long and prosper,
Gunnar
--
Das einzige Mittel, den Irrtum zu vermeiden, ist die Unwissenheit. (Jean-Jacques Rousseau)
warum kann da nicht folgendes stehen?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5//EN"
"http://www.w3.org/MarkUp/DTD/html5.dtd">
>
> Weil es für HTML 5 keine DTD gibt.
Warum eigentlich nicht? Verschachtelungsregeln und Angaben, bei welchen Elementen Tags weggelassen werden können oder müssen, existieren doch in der Spezifikation, nur leider als Prosa. Oder gibt es ein Schema, um zu validieren? Wie kriegt man heraus, dass man keinen Mist gebaut hat?
Willkommen im alten Reich der Tagsuppen:
~~~html
<!DOCTYPE HTML>
<title>Titel</title>
<p>Ich bin ein gültiges HTML-5-Dokument.<p>
Hi,
Weil es für HTML 5 keine DTD gibt.
Warum eigentlich nicht?
Vielleicht weil man endgültig von dieser (ohnehin nie relevanten und IMHO eh arg hinrissigen) Vorstellung des W3Cs wegkommen wollte, man bräuchte eine DTD, um für HTML so etwas wie "gültig" zu definieren (jedenfalls was über die Wohlgeformtheit hinausgeht). :)
Wieder hin zum Ursprung, daß alle Elemente und Attribute einfach zu ignorieren sind, wenn der Browser sie nicht kennt (allerdings nun mit der Verpflichtung, sie dennoch im DOM zu repräsentieren).
Im Real-Life nennt man das "Bürokratieabbau".
Wie kriegt man heraus, dass man keinen Mist gebaut hat?
Wie immer: Durch Studium der Docs und ggf. Nutzung eines Validators.
Willkommen im alten Reich der Tagsuppen:
<!DOCTYPE HTML>
<title>Titel</title>
<p>Ich bin ein gültiges HTML-5-Dokument.<p>
Den Doctype braucht es nicht für ein gültiges und korrektes HTML-Dokument. Das war so, das W3C hat es verkompliziert, und jetzt wird es wieder einfacher.
Merke auch: Die Angabe des Doctypes ist \*ausschließlich\* "notwendig" wg. des überaus dämlichen Doctype-Switchings - also rein aus \*technischen\* Gründen, weil da jemand mal eine ganz dumme Idee hatte, und alle mitgemacht haben. Wo das nicht gebraucht wird, kann er daher entfallen. Verpflichtend ist er nicht.
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
Yerf!
Wie kriegt man heraus, dass man keinen Mist gebaut hat?
Wie immer: Durch Studium der Docs und ggf. Nutzung eines Validators.
Und der Validator ist dann jemand (in Person) der für mich die Docs studiert und mein Document prüft, oder wie soll das maschinell ohne eine DTD (oder ähnliche Beschreibung) gehen?
Gruß,
Harlequin
Hi,
Und der Validator ist dann jemand (in Person) der für mich die Docs studiert und mein Document prüft, oder wie soll das maschinell ohne eine DTD (oder ähnliche Beschreibung) gehen?
Genauso wie bisher: Du rufst einen Validator auf, sendest ihm Quellcode oder URL, und er validiert.
Da das W3C HTML 5 ja adoptiert hat (bzw. adoptieren mußte), wird es über kurz oder lang auch vom W3C einen entsprechenden Validator geben.
Momentan & bis dahin, wird man, sofern überhaupt nötig, auf fremde Validatoren verwiesen. Du wirst auch bereits fündig, wenn du danach googelst ...
Gruß, Cybaer
Yerf!
Genauso wie bisher: Du rufst einen Validator auf, sendest ihm Quellcode oder URL, und er validiert.
Die Frage war ja eher ob es dann (zumindest für den Validator) doch eine maschinenlesbare Beschreibung (ähnlich einer DTD) gibt oder ob die Regeln einzeln in den Validator gepfriemelt werden...
Gruß,
Harlequin
Hi,
Die Frage war ja eher ob es dann (zumindest für den Validator) doch eine maschinenlesbare Beschreibung (ähnlich einer DTD) gibt oder ob die Regeln einzeln in den Validator gepfriemelt werden...
Wozu? Wolltest Du einen schreiben oder nutzen? ;->
Was interessiert mich, wie das Benzin hergestellt wird, solange ich an der Tanke das Benzin bekomme, mit dem das Auto fährt ... ;)
... Strom kommt ja auch aus der Steckdose! >;->
Gruß, Cybaer
Yerf!
Wozu? Wolltest Du einen schreiben oder nutzen? ;->
In einem CMS könnte ich mir das durchaus vorstellen, sozusagen als Qualitätskontrolle (oder um das Templatesystem zu steuern, dass es keinen Mist baut).
Gruß,
Harlequin
Hallo Harlequin,
Die Frage war ja eher ob es dann (zumindest für den Validator) doch eine maschinenlesbare Beschreibung (ähnlich einer DTD) gibt oder ob die Regeln einzeln in den Validator gepfriemelt werden...
Der derzeitig halbwegs offizielle HTML-5-Validator nutzt intern Relax NG Schemata mit zusätzlichen Schematron Regeln und zusätzlich noch diverse Überprüfungen in einer Programmiersprache, um zusätzliche Bedingungen zu überprüfen, die sich nicht in den gängigen Schemasprachen ausdrücken lassen. Die derzeitigen Relax NG Schemata findest Du hier, das ganze wird natürlich mit der Spezifikation weiter entwickelt. Ich meine mich zu erinnern, dass die RNGs auch mit der Spezifikation ausgeliefert werden sollen; mag meine Hand dafür aber nicht ins Feuer legen.
validator.nu soll wohl der nächste W3C-Validator werden.
Tim
@@Cybaer:
Vielleicht weil man endgültig von dieser (ohnehin nie relevanten und IMHO eh arg hinrissigen) Vorstellung des W3Cs wegkommen wollte, man bräuchte eine DTD, um für HTML so etwas wie "gültig" zu definieren (jedenfalls was über die Wohlgeformtheit hinausgeht). :)
Hm, und was sagt mir dann, was gültig ist und was nicht? Die Spezifikation von HTML 5 mag für Implementierer lesbar sein (für solche ist sie ja offensichtlich auch geschrieben); für HTML-Autoren ist sie das eher nicht. Ich ziehe da eine leicht verständliche DTD vor.
Live long and prosper,
Gunnar
Hi,
Ich ziehe da eine leicht verständliche DTD vor.
Das ehrt dich. Aber was schätzt Du, wieviele Webautoren eine DTD lesen können?*)
*) Rhetorische Frage! Wie ich hier so manche Frage interpretiere, können viele Webautoren noch nicht mal SELFHTML lesen. Und das ist deutlich lesbarer ...
Gruß, Cybaer
Weil es für HTML 5 keine DTD gibt.
Warum eigentlich nicht?Vielleicht weil man endgültig von dieser (ohnehin nie relevanten und IMHO eh arg hinrissigen) Vorstellung des W3Cs wegkommen wollte, man bräuchte eine DTD, um für HTML so etwas wie "gültig" zu definieren (jedenfalls was über die Wohlgeformtheit hinausgeht). :)
Natürlich wird man HTML 5 validieren können, und zwar über Wohlgeformtheit hinaus, das ist durchaus Absicht der Autoren!
DTD ist einfach ein mögliches Format, um eine formale Grammatik auszudrücken. Und zwar ein beschränktes und veraltetes Format. Ein Format, das an den SGML-Kontext gebunden ist. HTML 5 entstammt diesem nicht. Es gibt zwar eine XHTML-Serialisierung, aber niemand würde auf die Idee kommen, HTML 5 in einer XML-DTD auszudrücken und XHTML-5-Dokumente dagegen zu validieren. Da würde man schnell an die Grenzen stoßen und die DTD wäre genauso unvollständig wie die (X)HTML-DTD.
Außerdem ist es nicht Primärziel von HTML 5, eine Grammatik für eine Markup-Serialisierung zu spezifizieren, sondern den Aufbau des DOMs. Das ist Top-Down statt Bottom-Up.
Mathias
nein, ich find nur den doctype etwas geschacklos bzw dass sich die html5-verschlimmbesserer herrausnehmen, einen "neutralen" doctype zu erfinden, der browser wirds schon verstehen, was gemeint ist
Es sollte einem nicht validierendem Client genügen zu verstehen, dass 'html' gemeint ist.
die frage ist, warum steigt man nicht endlich mal auf validierende clients um? ;) ein xml-parser selbst ist zwar auch nicht validieren, prüft aber zumindest die wohlgeformtheit und stellt die patschen auf, wenn was nicht passt
warum nicht jeden browser zwangsläufig validieren lassen, wenn ein winziger fehler im quelltext ist: "aus die maus, mickey maus"
ich find den doctype-switch gut und eine genaue und möglichst exakte angabe sinnvoll
Umschaltung der Darstellungsmodi anhand der DOCTYPE-Angabe sinnvoll?? Sag bitte schnell, dass das nicht dein Ernst ist!
nein, um dem browser zu sagen, was er da genau vorgesetzt bekommt und vorauf sich der parser verlassen darf (siehe oben, forderung nach validierenden clients)
laienhaft gedacht:
ich weiss nicht, wie browser programmiert sind bzw wie sie arbeiten - aber ich würde anhand der dtd entsprechende module laden - "wenn in dtd irgendwas von video-element steht, lade deine routine zum videos anzeigen" - ich bin mir sicher, dass derartige routinen zusätzliche ressourcen beanspruchen, die - wenn sie nicht geladen werden - den browser schneller machen
also warum zur hölle soll die engine einen mathml-parser "anschmeißen", wenn im kompletten dokument kein einziges element vorkommt, welches irgendwelches dergleichen beinhaltet?
Weil es für HTML 5 keine DTD gibt.
das hab ich auch schon festgestellt ;)
Hi,
die frage ist, warum steigt man nicht endlich mal auf validierende clients um? ;)
Wg. der eingeführten Fehlertoleranz der IEs.
nein, um dem browser zu sagen, was er da genau vorgesetzt bekommt und vorauf sich der parser verlassen darf
Das braucht man nicht. Zumindest nicht im überschaubaren HTML-Umfeld, wo *jeder* Browserhersteller seit je her proprietäre Elemente und Attribute nutzt, die dann teilweise später standardisiert wurden, teilweise weiter proprietäre Nischen bildeten oder schlicht nur internen Zwecken dienen.
ich weiss nicht, wie browser programmiert sind bzw wie sie arbeiten - aber ich würde anhand der dtd entsprechende module laden - "wenn in dtd irgendwas von video-element steht, lade deine routine zum videos anzeigen" - ich bin mir sicher, dass derartige routinen zusätzliche ressourcen beanspruchen, die - wenn sie nicht geladen werden - den browser schneller machen
Der Browser unterstützt, was er unterstützt. Das ist überschaubar. Das Nachladen von Modulen zur Laufzeit wg. eines Standard-Tags, ist bei den Datenmengen wohl nicht weiter sinnvoll ...
Gruß, Cybaer
Yerf!
nein, um dem browser zu sagen, was er da genau vorgesetzt bekommt und vorauf sich der parser verlassen darf
Das braucht man nicht. Zumindest nicht im überschaubaren HTML-Umfeld, wo *jeder* Browserhersteller seit je her proprietäre Elemente und Attribute nutzt, die dann teilweise später standardisiert wurden, teilweise weiter proprietäre Nischen bildeten oder schlicht nur internen Zwecken dienen.
Aber ist das wirklich erstrebenswert? Man hat damals Pandoras Büchse geöffnet, aber anstelle dass man versucht sie wieder zu schließen erklärt man das Chaos zum Standard. (Ähm, Microsoft arbeitet am HTML5 Standard mit?)
Vielleicht bin ich auch einfach viel zu viel Programmierer, als dass ich micht solch einem Wischiwaschi-Standard abfinden könnte. Ein Compiler liefert mir knallharte Fehlermeldungen und genau so muss das sein...
Gruß,
Harlequin
Aber ist das wirklich erstrebenswert? Man hat damals Pandoras Büchse geöffnet, aber anstelle dass man versucht sie wieder zu schließen erklärt man das Chaos zum Standard. (Ähm, Microsoft arbeitet am HTML5 Standard mit?)
vermutlich arbeitet jeder depp mit - sie gedenken doch tatsächlich auch das embed-element zu standardisieren
object, embed, audio, video, source - ich versteh die sinnhaftigkeit immer noch nicht - ein standardisierten des object-elements und die zur verfügung stehenden plugin-schnittstellen hätte gereicht
Vielleicht bin ich auch einfach viel zu viel Programmierer, als dass ich micht solch einem Wischiwaschi-Standard abfinden könnte. Ein Compiler liefert mir knallharte Fehlermeldungen und genau so muss das sein...
so gehts mir auch
Hi,
sie gedenken doch tatsächlich auch das embed-element zu standardisieren
HTML 5 wurde erschaffen, um, anders als bei XHTML 1.1/2.0, HTML machbar zu erweitern, und gleichzeitig größtmöglich abwärtskompatibel zu sein.
Gruß, Cybaer
HTML 5 wurde erschaffen, um, anders als bei XHTML 1.1/2.0, HTML machbar zu erweitern, und gleichzeitig größtmöglich abwärtskompatibel zu sein.
Klar, embed, audio und video werden eingeführt, obwohl object reicht. Inkonsequenterweise wird aber applet entfernt.
Wo ist eigentlich marquee? Es ist in diversen Browsern implementiert und hat immerhin eine gewisse Verbreitung.
Wo ist eigentlich marquee? Es ist in diversen Browsern implementiert und hat immerhin eine gewisse Verbreitung.
<i> und <b> fliegen übrigens auch nicht raus, werden nur "umdeklariert" - <tt> fliegt aber "konsequenterweise" ;)
zudem wird <em> erweitert, wenn man <em> verschachtelt, wird der aussage mehr ausdruck verliehen, was ist also gewichtiger?:
[ ] <em>weee</em>
[ ] <em><em><em>weee</em></em></em>
[ ] <strong>weee</strong>
[ ] <em><em><em><em><em><em>weee</em></em></em></em></em></em>
Hi,
<i> und <b> fliegen übrigens auch nicht raus, werden nur "umdeklariert" - <tt> fliegt aber "konsequenterweise" ;)
Frames sind aus "technischen Gründen" obsolet (gemeint ist aber wohl: die Autoren konnten damit nicht umgehen), aber IFrames natürlich nicht (gleiche Technik, aber soll wohl heißen: die sind zu wichtig, weil so oft benutzt). :->
Gruß, Cybaer
Hi,
Wo ist eigentlich marquee? Es ist in diversen Browsern implementiert und hat immerhin eine gewisse Verbreitung.
Reines Layout, und wird deswegen in CSS 3 abgehandelt.
Gruß, Cybaer
Hi,
Aber ist das wirklich erstrebenswert?
Ist Versionitis erstrebenswert? Nochmal: Ich habe bislang mit dem Fehlen der Version keine Probleme gehabt - angefangen mit HTML "1" bis heute. Niemand hat sie - außer MS - und das aus eigenem Verschulden.
Und wie die Webstatistiken von Google & Opera zeigen: Es gibt fast keine "standardkonformen" Seiten (im Sinne des W3C) - und die wenigen, die es mittels W3C-Bepperl von sich behaupten, validieren immerhin zur Hälfte auch nicht.
Also geh mir fort der Preisung der Einhaltung eines vermeintlichen "Standards", der gegen irgendwelche nicht bekannte Probleme helfen soll, aber annähernd zu 100% ignoriert wird. Nur weil Du dich dabei wohler fühlst, ist kein Grund.
Man hat damals Pandoras Büchse geöffnet, aber anstelle dass man versucht sie wieder zu schließen erklärt man das Chaos zum Standard.
Nein. MS hat Pandoras Büchse geöffnet durch ihre extreme Fehlertoleranz. MS ist (immer noch) Marktführer. Diese Büchse wird sich auch nicht mehr schließen lassen.
(Ähm, Microsoft arbeitet am HTML5 Standard mit?)
Nein. Man teilt aber die Ziele der WHATWG.
Und: MS verspricht ja nunmehr, zukünftig standardkonform(er?) zu sein. Das wird wohl dann (schon zwangsweise - aber, s.o., auch aus Überzeugung) auch HTML 5 betreffen.
Aber WHATWG bedeutet immer noch: Apple, Mozilla, Opera. Aber eine Mitgliedschaft (dem IE-Leiter wurde der Vorsitz erfolglos angeboten) besteht AFAIK nicht. MS hat da wohl patentrechtliche Probleme ...
Vielleicht bin ich auch einfach viel zu viel Programmierer, als dass ich micht solch einem Wischiwaschi-Standard abfinden könnte. Ein Compiler liefert mir knallharte Fehlermeldungen und genau so muss das sein...
HTML ist *nicht* für Nerds erschaffen worden, die mit der Behebung von "knallharten Fehlermeldungen" ihren Lebensunterhalt verdienen wollen/müssen.
Und: HTML ist auch keine Programmiersprache. ;)
Gruß, Cybaer
PS: Vom Standpunkt des Infomatikers/Mathematikers/Logikers stimme ich dir ja zu. Aber für die war nunmal HTML *explizit nicht* gedacht. Für die gab es nämlich schon das überaus erfolgreiche SGML. Und das hat, was *Du* willst. HTML ist *bewußt* anders ...
... und auch wenn es in meiner Informatiker/Mathematiker/Logiker-Seele darob brutzelt: Das ist auch gut so.
Yerf!
Ist Versionitis erstrebenswert?
Man sollte es mit Versionen nicht übertreiben. Aber sie bieten die Möglichkeit alte Fehler zu korrigieren, indem man bei einer Angabe einer alten Version beim bisherigen Verhalten bleibt und bei einer Angabe einer neueren Version die verbesserte Funktionalität verwendet. Ohne Versionsangabe muss man immer bei dem alten Mist bleiben, der irgendwann mal "verbrochen" wurde. Meiner Meinung nach auch eines der Hauptprobleme von HTML5.
Und wie die Webstatistiken von Google & Opera zeigen: Es gibt fast keine "standardkonformen" Seiten (im Sinne des W3C) - und die wenigen, die es mittels W3C-Bepperl von sich behaupten, validieren immerhin zur Hälfte auch nicht.
Und wieviele jammern hier im Forum immer wieder rum, das die Darstellung deswegen nicht passt? Erst mal ne Menge Fehler präsentiert zu bekommen und diese beheben zu *müssen* mag erst mal unschön erscheinen, aber es wird mit einem verlässlichen Ergebnis belohnt. Und wenn man das öfters macht hat man die regeln bald intus, so viele sinds ja auch nicht.
Also geh mir fort der Preisung der Einhaltung eines vermeintlichen "Standards", der gegen irgendwelche nicht bekannte Probleme helfen soll, aber annähernd zu 100% ignoriert wird. Nur weil Du dich dabei wohler fühlst, ist kein Grund.
Tja, manche Leute haben scheinbar kein Problem damit solange an der Seite rumzupfuschen bis sie funzt. Mir ist da eine definierte Vorgehensweise anhand von Regeln wesentlich lieber.
Nein. MS hat Pandoras Büchse geöffnet durch ihre extreme Fehlertoleranz. MS ist (immer noch) Marktführer. Diese Büchse wird sich auch nicht mehr schließen lassen.
MS war da aber nicht alleine, auch Netscape hat da mit jeder Menge HTML-Erweiterungen gut nachgeholfen. Aber wieso nicht HTML4 so lassen wie es ist und etwas neues, besseres aufsetzen? Weil man dann einen Doctype bräuchte um die 2 Varianten zu unterscheiden?
(Ähm, Microsoft arbeitet am HTML5 Standard mit?)
Nein. Man teilt aber die Ziele der WHATWG.
War nur so ein Seitenhieb auf die Glühbirnenproblematik[1]...
HTML ist *nicht* für Nerds erschaffen worden, die mit der Behebung von "knallharten Fehlermeldungen" ihren Lebensunterhalt verdienen wollen/müssen.
HTML wurde für WYSIWYG-Editoren geschaffen (zumindest hat doch einer der Entwickler mal gesagt, das niemand die Tags direkt in einem Editor eingeben sollte...) Nur leider ist an der Front nie was vernünftiges rausgekommen...
Der aktuelle Trend zum CMS/Blog könnte da Besserung bringen, allerdings sollten Templates nur diejenigen Leute bauen, die auch etwas davon verstehen...
PS: Vom Standpunkt des Infomatikers/Mathematikers/Logikers stimme ich dir ja zu. Aber für die war nunmal HTML *explizit nicht* gedacht. Für die gab es nämlich schon das überaus erfolgreiche SGML. Und das hat, was *Du* willst. HTML ist *bewußt* anders ...
SGML lehne ich ab, weil es viel zu viel Freiheiten lässt, die keiner braucht und nur Fehler provozieren. XML ist genau das richtige, aber eben auch nur ein Format zur beschreibung von Formaten, also nichts konkretes. Deshalb hätte ich gern ein sauberes Dokumentvormat auf der Basis von XML. XHTML2 wäre da ein guter Anfang.
... und auch wenn es in meiner Informatiker/Mathematiker/Logiker-Seele darob brutzelt: Das ist auch gut so.
Weshalb? Wenn ich fragen darf...
Damit jeder die Möglichkeit hat im Web zu publizieren? Den meisten wäre doch schon mit einem *vernünftigen* WYSIWYG-Editor oder eben ein CMS-System, Blog, etc. gedient. Sie sollten die HTML-Tags eigentlich gar nicht zu sehen bekommen...
Gruß,
Harlequin
[1] F: Wie wechselt ein Microsoftmitarbeiter eine Glühbirne?
A: Gar nicht, Microsoft erklärt Dunkelheit zum Industriestandard.
Hi,
Man sollte es mit Versionen nicht übertreiben. Aber sie bieten die Möglichkeit alte Fehler zu korrigieren, indem man bei einer Angabe einer alten Version beim bisherigen Verhalten bleibt und bei einer Angabe einer neueren Version die verbesserte Funktionalität verwendet.
Welches Fehlverhalten war in der Geschichte von HTML derart gravierend, daß man es über die Kenntnis der HTML-Version abfangen müßte?
Außer natürlich so manche dusselige Ideen der MS-Programmierer. >;->
BTW: IE-Chef Wilson ist auch der einzige der "Browserchefs", der für eine Versionierung ist - aus eben diesem Grund.
Er meint, eine Nicht-Versionierung wäre nicht durchzuhalten. Nun, wird werden sehen ... :)
Ohne Versionsangabe muss man immer bei dem alten Mist bleiben, der irgendwann mal "verbrochen" wurde. Meiner Meinung nach auch eines der Hauptprobleme von HTML5.
Tja nun, HTML 5 wurde wg. Abwärtskompatibilität entworfen. Wenn man was neues gewollt hätte, hätte man zum inkompatiblen XHTML wechseln können. Letzteres war nicht gewollt. Ersteres schon. Deswegen sind wir heute, wo wir sind.
Und wie die Webstatistiken von Google & Opera zeigen: Es gibt fast keine "standardkonformen" Seiten (im Sinne des W3C) - und die wenigen, die es mittels W3C-Bepperl von sich behaupten, validieren immerhin zur Hälfte auch nicht.
Und wieviele jammern hier im Forum immer wieder rum, das die Darstellung deswegen nicht passt? Erst mal ne Menge Fehler präsentiert zu bekommen und diese beheben zu *müssen* mag erst mal unschön erscheinen, aber es wird mit einem verlässlichen Ergebnis belohnt.
(seufz & Gebetsmühle anwerf) Es gibt Validitätsverstöße, die No-Gos sind, und es gibt Validitätsverstöße, die problemlos sind.
Das einzige Problem ist, daß ein Anfänger sich damit nicht auskennt. Ein weiteres Problem: Hier fehlt die Bereitschaft, zu Unterscheiden. Die Aussage "ist valide" ist für Anfänger und Faule (wobei das hier niemandem zum Vorwurf gemacht werden soll - schließlich helfen wir ja kostenlos).
Also "wg. mangelnder Validität" an sich, kann man *nicht* Rückschlüsse auf die Darstellung der Seite ziehen. Eine vailde Seite kann so "zerschossen" sein, wie eine invalide Seite perfekt in der Darstellung. Es ist ein Hilfsmittel, kein Gebetsbuch ...
... und wer möchte, kann auch gerne valide HTML 5 coden. Fakt ist aber, daß die Mehrzahl nicht valide codet. Punkt. Sei es, weil man weiß, worauf zu achten ist, sei es, weil man schlampt, oder sei es, weil der Editor keinen guten Code erzeugt.
Darüber zu weinen hilft nichts. Die paar Promille Autoren anzuführen, die hier um Hilfe nachsuchen, sind auch in keinster Weise relevant in der Masse des Webs.
Tja, manche Leute haben scheinbar kein Problem damit solange an der Seite rumzupfuschen bis sie funzt. Mir ist da eine definierte Vorgehensweise anhand von Regeln wesentlich lieber.
Dann mach das. Aber was hat das mit HTML 5 zu tun? Auch HTML 5 hat Regeln.
MS war da aber nicht alleine, auch Netscape hat da mit jeder Menge HTML-Erweiterungen gut nachgeholfen.
Erweiterungen != Pfusch
Aber wieso nicht HTML4 so lassen wie es ist und etwas neues, besseres aufsetzen?
HTML 5 ist besser (sagen die Entwickler ;-)). Und neuer ist V5 auch als V4. ;->
Weil man dann einen Doctype bräuchte um die 2 Varianten zu unterscheiden?
Wozu sollte man unterscheiden? Die DTD war für Validatoren interessant. In der Geschichte der HTML-Browser hat es *zu keinem Zeitpunkt* einen Browser gegeben, der sich für eine angegebene DTD interessiert hätte, noch war dies jemals geplant.
(Ähm, Microsoft arbeitet am HTML5 Standard mit?)
Nein. Man teilt aber die Ziele der WHATWG.
War nur so ein Seitenhieb auf die Glühbirnenproblematik[1]...
Tja, mein Vertrauen in Apple, Mozilla & Opera ist höher, als in das von MS. ;)
HTML wurde für WYSIWYG-Editoren geschaffen (zumindest hat doch einer der Entwickler mal gesagt, das niemand die Tags direkt in einem Editor eingeben sollte...)
LOL.
Nur leider ist an der Front nie was vernünftiges rausgekommen...
Also als HTML das Licht der Welt erblickte, war an SGML-Tools bereits kein Mangel. Daran wäre es IMHO nicht gescheitert ...
Der aktuelle Trend zum CMS/Blog könnte da Besserung bringen, allerdings sollten Templates nur diejenigen Leute bauen, die auch etwas davon verstehen...
Klar, Blog-Engines, die zwangsweise das Web mit XHTML beglücken, der dann aber in der Praxis auch zwangsweise zu invalidem XHTML-Code führt, haben die Standardistas echt weit vorangebracht (nochmal: LOL). >:->
SGML lehne ich ab, weil es viel zu viel Freiheiten lässt, die keiner braucht und nur Fehler provozieren.
Ist doch egal, wenn man einen guten Editor verwendet ... >;->
XML ist genau das richtige, aber eben auch nur ein Format zur beschreibung von Formaten, also nichts konkretes. Deshalb hätte ich gern ein sauberes Dokumentvormat auf der Basis von XML.
Dann codiere HTML 5 halt in XHTML-Syntax. ;->
XHTML2 wäre da ein guter Anfang.
Illusorisch, weil von den Browserherstellern nicht gewollt. Punkt.
Man mag über die Gründe streiten, aber das ändert nichts mehr am Ausgang der Diskussion.
... und auch wenn es in meiner Informatiker/Mathematiker/Logiker-Seele darob brutzelt: Das ist auch gut so.
Weshalb? Wenn ich fragen darf...
Ich will jetzt nicht zu sehr ausschweifen. Darum kurz: Das WWW wurde mit HTML ein fulminanter Erfolg, in dem jeder Dödel sich mitteilen kann. das alleine ist schon Grund genug.
Damit jeder die Möglichkeit hat im Web zu publizieren? Den meisten wäre doch schon mit einem *vernünftigen* WYSIWYG-Editor oder eben ein CMS-System, Blog, etc. gedient. Sie sollten die HTML-Tags eigentlich gar nicht zu sehen bekommen...
Warum nicht? Man kann sich (heutzutage) einen gescheiten Editor holen. Aber der Tag sei verflucht, an dem Hinz & Kunz nicht mehr ohne Editor in der Lage sein sollten, Web-Dokumente zu erstellen ...
... oder meinst Du, ein Binärformat, Ansätze gibt es dazu ja, wäre von Anfang an die bessere Lösung gewesen? MS-Webword vielleicht? >;->
Gruß, Cybaer
@@Cybaer:
HTML wurde für WYSIWYG-Editoren geschaffen (zumindest hat doch einer der Entwickler mal gesagt, das niemand die Tags direkt in einem Editor eingeben sollte...)
LOL.
Was gibt es da zu lachen? http://forum.de.selfhtml.org/archiv/2007/7/t156891/#m1021502 ff. (http://forum.de.selfhtml.org/archiv/2007/7/t156891/#m1022444)
Live long and prosper,
Gunnar
PS: Ach, war das ein Thread!
Hi,
LOL.
Was gibt es da zu lachen?
Weil ich diese Aussage überaus lustig finde. Und, ja, in voller Kenntnis des Zitats von Tim Berners-Lee! :)
Vielleicht hätte man aber schon in dem Moment (bzw. einfach ganz am Anfang) sagen sollen: "Jungs, das mit dem W3C überlaßt mal bitte praktischer veranlagten Leuten." Da wäre uns wohl manches erspart geblieben ... >:->
PS: Ach, war das ein Thread!
Puh, ist dann doch mal für einen Ausdruck vorgemerkt. Sowas lese ich doch lieber an 'nem kalten Winterabend auf Papier ... ;)
... hat man hinterher auch was für'n Kamin. :)
Gruß, Cybaer
Yerf!
Welches Fehlverhalten war in der Geschichte von HTML derart gravierend, daß man es über die Kenntnis der HTML-Version abfangen müßte?
Z.B. die derzeit recht unaufgeräumten Verwendungen des Object-Elements, die Probleme machen könnten, wenn man das einmal vernünftig spezifizieren würde. Ich sehe das ganz allgemein eher in die Richtung eines neuen Standards der eben mit alten Fehlern aufräumt. Vermutlich würde für HTML daher der einfache Doctype reichen, der "neue" wäre dann ja XHTML 2 ;-)
Er meint, eine Nicht-Versionierung wäre nicht durchzuhalten. Nun, wird werden sehen ... :)
Es ist eine Frage der Weiterentwicklung. Eine Versionierung ergibt zusätzliche Möglichkeiten, aber die Entwickler von HTML5 wollen sowieso alles, das eine Versionierung vorraussetzt vermeiden und deshalb können sie sagen, das sie nicht notwendig ist...
Tja nun, HTML 5 wurde wg. Abwärtskompatibilität entworfen. Wenn man was neues gewollt hätte, hätte man zum inkompatiblen XHTML wechseln können. Letzteres war nicht gewollt. Ersteres schon. Deswegen sind wir heute, wo wir sind.
Tja "Abwärtskompatibilität"... manchmal wäre eine gekapselte Emulatorschicht und ein Neuanfang besser. Nicht nur bei HTML, auch z.B. bei Windows. MacOS hat mehrere solcher Schritte überlebt, also ganz unmöglich ist es nicht.
Ich denke ein XHTML 2 parallel zu HTML4 wäre genau das richtige. Wem die strengen Regeln auf die Nerven gehen kann ja beim alten bleiben. Die Existenz bestehender Webseiten wäre ebenfalls nicht gefährdet.
(seufz & Gebetsmühle anwerf) Es gibt Validitätsverstöße, die No-Gos sind, und es gibt Validitätsverstöße, die problemlos sind.
Über eine Trennung nach Fehler und Warning kann man ja diskutieren.
Also "wg. mangelnder Validität" an sich, kann man *nicht* Rückschlüsse auf die Darstellung der Seite ziehen. Eine vailde Seite kann so "zerschossen" sein, wie eine invalide Seite perfekt in der Darstellung. Es ist ein Hilfsmittel, kein Gebetsbuch ...
Eine valide Seite sieht aber auf jedem funktionsfähigem Browser gleich zerschossen aus. Bei einer invaliden Seite ist die Darstellung eher Glück und wenn dann jemand mal einen neuen Browser baut siehts vielleicht ganz anderes aus...
... und wer möchte, kann auch gerne valide HTML 5 coden. Fakt ist aber, daß die Mehrzahl nicht valide codet. Punkt. Sei es, weil man weiß, worauf zu achten ist, sei es, weil man schlampt, oder sei es, weil der Editor keinen guten Code erzeugt.
Die 1. sind nicht wirklich das Problem. Es sind eher die Fälle 2 und 3, vielleicht sollte man die Energie weniger in Fehlertoleranz bei den Browsern sondern mehr in die Entwicklung guter Tools zur Seitenerstellung stecken?
Darüber zu weinen hilft nichts. Die paar Promille Autoren anzuführen, die hier um Hilfe nachsuchen, sind auch in keinster Weise relevant in der Masse des Webs.
Der rest klebt ein "optimiert für IE" unter seine Seite und schimpft über die anderen Browser wie schlecht die doch sind... ;-)
Dann mach das. Aber was hat das mit HTML 5 zu tun? Auch HTML 5 hat Regeln.
Ja, aber es bietet mir nichts neues, weil viel Aufwand in die Standardisierung des aktuellen Chaos gesteckt wird anstatt wirklich neues und nützliches zu bringen. Von daher kann ich beruhigt bei XHTML 1.0 strict bleiben.
Aber wieso nicht HTML4 so lassen wie es ist und etwas neues, besseres aufsetzen?
HTML 5 ist besser (sagen die Entwickler ;-)). Und neuer ist V5 auch als V4. ;->
Dir ist sicherlich klar, dass ich auf XHTML 2 anspiele... ;-)
Wozu sollte man unterscheiden? Die DTD war für Validatoren interessant. In der Geschichte der HTML-Browser hat es *zu keinem Zeitpunkt* einen Browser gegeben, der sich für eine angegebene DTD interessiert hätte, noch war dies jemals geplant.
Spätestens wenn man einen inkompatiblen neuen Standard hat muss man unterscheiden. Die WHATWG woill das nicht, ich steh auf der Meinung, dass es aber der bessere Weg wäre...
HTML wurde für WYSIWYG-Editoren geschaffen (zumindest hat doch einer der Entwickler mal gesagt, das niemand die Tags direkt in einem Editor eingeben sollte...)
LOL.
Stammt angeblich von Tim Berners-Lee. Und ich geb ihm in dem Punkt eindeutig Recht.
Also als HTML das Licht der Welt erblickte, war an SGML-Tools bereits kein Mangel. Daran wäre es IMHO nicht gescheitert ...
Das hat nichts mit SGML-Tools zu tun. Was wir brauchen sind fähige WYSIWYG-Editoren die sauberen Code erzeugen. Ich halte das nicht für einen Widerspruch sondern durchaus für machbar (hab nur leider nicht die Zeit übrig ein solches Projekt zu starten).
Klar, Blog-Engines, die zwangsweise das Web mit XHTML beglücken, der dann aber in der Praxis auch zwangsweise zu invalidem XHTML-Code führt, haben die Standardistas echt weit vorangebracht (nochmal: LOL). >:->
Jo, hätt ich vorher drüber nachdenken sollen, die Entwickler der aktuellen CMS/Blog-Systeme sind leider noch unfähiger als die WYSIWYG-Editor Entwickler. Aber das heist nicht, das über diesen Weg unmöglich ist etwas Vernünftiges auf die Beine zu stellen. Eben ein System das von sich aus sauberen Code erzeugt ohne das sich der Text-Author drum kümmern muss.
Dann codiere HTML 5 halt in XHTML-Syntax. ;->
Oder ich bleib einfach bei XHTML 1. Einfach mal abwarten was die Zukunft bringt, wirklich was dran ändern werd ich eh nicht können.
XHTML2 wäre da ein guter Anfang.
Illusorisch, weil von den Browserherstellern nicht gewollt. Punkt.
*DAS* ist das eigentliche Problem. Wenn die Browserhersteller sagen, ein href-Attribut für jedes Element ist zu Aufwändig, dann gibt es das eben nicht. Egal wie nützlich das für den Author wäre...
Aber leider sehe ich auch keinen Weg daran etwas zu ändern (außer mit viel Manpower 2 unabhängige Browser + einen guten WYSIWYG-Editor auf Basis von XHTML2 zu bauen um HTML5 zuvorzukommen...)
Ich will jetzt nicht zu sehr ausschweifen. Darum kurz: Das WWW wurde mit HTML ein fulminanter Erfolg, in dem jeder Dödel sich mitteilen kann. das alleine ist schon Grund genug.
Aber nicht so wie es sich die Entwickler eigentlich vorgestellt haben[1]. Das man HTML direkt bearbeiten kann ist sicherlich ein nützliches feature,d as auf keinem Fall entfallen darf. Allerdings, gerade weil "Otto Normaluser" da einiges falsch machen kann sollten diese einfache Tools an die hand bekommen, die die "Drecksarbeit" der Tag-Erzeugung für ihn übernehmen.
... oder meinst Du, ein Binärformat, Ansätze gibt es dazu ja, wäre von Anfang an die bessere Lösung gewesen? MS-Webword vielleicht? >;->
Das sicher nicht.
Gruß,
Harlequin
[1] siehe das Zitat von Tim Berners-Lee, diese Grundaussage kommt auch in anderen Texten von ihm heraus.
Hi,
Eine Versionierung ergibt zusätzliche Möglichkeiten,
Es gibt Möglichkeiten, auf die ich gerne verzichte.
BTW: Interessanter Punkt, da ja auch in ECMAScript darüber gestritten wird.
aber die Entwickler von HTML5 wollen sowieso alles, das eine Versionierung vorraussetzt vermeiden und deshalb können sie sagen, das sie nicht notwendig ist...
Wobei ich nicht glaube, daß sie etwas vermeiden, um eine Versionierung zu umgehen. :)
Tja "Abwärtskompatibilität"... manchmal wäre eine gekapselte Emulatorschicht und ein Neuanfang besser. Nicht nur bei HTML, auch z.B. bei Windows. MacOS hat mehrere solcher Schritte überlebt, also ganz unmöglich ist es nicht.
Nein. Aber nicht gewollt.
Ich denke ein XHTML 2 parallel zu HTML4 wäre genau das richtige. Wem die strengen Regeln auf die Nerven gehen kann ja beim alten bleiben. Die Existenz bestehender Webseiten wäre ebenfalls nicht gefährdet.
Die Browserhersteller waren nicht willens, bzw. sahen sich generell nicht in der Lage, HTML mit XHTML 2 abzulösen. Die Gründe waren viele, und gingen bis hin zum "XML ist im Web gescheitert - wir sollten aus unseren Fehlern lernen, komplett von vorne anfangen". Gleichzeitig ging es ihnen auf den Sack, daß HTML (und mit dem stockenden XHTML auch gleich die ganze Webentwicklung) jahrelang nicht mehr vorwärts kam.
Abstrahiert würde ich sagen: Irgendwann werden wir was Neues haben. Was, kann man noch nicht sagen. Aber mom. ist die Zeit wohl noch nicht reif dafür. Übergangsweise wird HTML weiterentwickelt. Leben wir damit, und ärgern uns nicht darüber. Der menschlichen Schwächen sind so viele, da ist diese Problem wirklich eher luxuriöser Natur ... :-)
vielleicht sollte man die Energie weniger in Fehlertoleranz bei den Browsern sondern mehr in die Entwicklung guter Tools zur Seitenerstellung stecken?
Wobei ich da auch erst wirklich Hoffnung habe, wenn das "IE-Problem" erledigt ist ...
Von daher kann ich beruhigt bei XHTML 1.0 strict bleiben.
Ja natürlich. Ich besorg's mir ja auch nur so, wie ich's gerade brauch! O;->
Aber wieso nicht HTML4 so lassen wie es ist und etwas neues, besseres aufsetzen?
HTML 5 ist besser (sagen die Entwickler ;-)). Und neuer ist V5 auch als V4. ;->
Dir ist sicherlich klar, dass ich auf XHTML 2 anspiele... ;-)
Davon kannst Du ausgehen. :)
Spätestens wenn man einen inkompatiblen neuen Standard hat muss man unterscheiden.
Was man aber auch nicht am Doctype festmachen muß (und IMHO auch nicht sollte).
Die WHATWG woill das nicht, ich steh auf der Meinung, dass es aber der bessere Weg wäre...
An der Meinung ist ja auch nichts ehrenrühriges. Etwaige Spekulationen, auf der Reeperbahn würden sich demnächst dunkle Gestalten in Hinterhöfen treffen, um gegen viel Geld schmutzige XHTML-2-Drafts zu verhökern ("Mach mich heiß, Du W3C-Schlampe!"), halte selbst ich für maßlos übertrieben! ;->
Und ich geb ihm in dem Punkt eindeutig Recht.
Da fragt man sich wirklich: Wie konnte das WWW nur ohne gescheite Tools jaemals soooo erfolgreich werden. ;-)
Das hat nichts mit SGML-Tools zu tun. Was wir brauchen sind fähige WYSIWYG-Editoren die sauberen Code erzeugen.
Wir brauchen zuerst einmal Browser, bei denen WYSIWYG-Code auch wirklich darstellt, was man sieht. Wenn das gegeben ist, dann sehen wir mal weiter ...
Ich halte das nicht für einen Widerspruch sondern durchaus für machbar
Ich eigentlich auch. Aber: WYSIWYG wird immer problematisch sein, auf einem Medium, das so viele unterschiedliche Ausgabegeräte bedienen möchte (und es tut).
Ein "PDF für's Web" kann mich bislang jedenfalls nicht überzeugen ...
Aber leider sehe ich auch keinen Weg daran etwas zu ändern (außer mit viel Manpower 2 unabhängige Browser + einen guten WYSIWYG-Editor auf Basis von XHTML2 zu bauen um HTML5 zuvorzukommen...)
Wichtiges Problem: Was nützt so etwas, wenn doch so viele zufrieden sind, mit dem, was sie haben (Entwicklung mit dem IE, sieht auf dem IE gut aus, wen interessiert der Rest).
Die "Spezies" die mehr brauchen/wollen, sind ja nicht Teil des Problems.
Aber nicht so wie es sich die Entwickler eigentlich vorgestellt haben[1].
Was zumindest Tim Berner-Lee sich nicht so vorgestellt haben mag. Entwickler gab es mehr. Aber ich gebe ja zu: Meine sich über all die Jahre gewachsene Abneigung des W3Cs wg. seiner Praxisferne, bezieht sich durchaus auch auf den Großen Vorsitzenden (ohne seine geniale Grundidee damit schmälern zu wollen). Was wirklich Richtungsweisendes ist mir jetzt so spontan allerdings auch nicht weiter in Erinnerung ...
... zumindest was praxisnahe und umsetzbare, geschweige denn umgesetzte Ideen angeht.
Allerdings, gerade weil "Otto Normaluser" da einiges falsch machen kann sollten diese einfache Tools an die hand bekommen, die die "Drecksarbeit" der Tag-Erzeugung für ihn übernehmen.
Darauf, daß die Tools gar nicht zu einfach und zu gut sein können, kann man sich ganz bestimmt immer einigen. ,-)
Wobei das Markup die eine Sache ist (Dreamweaver scheint übrigens mittlerweile doch um einiges besser zu sein, als früher). Aber in der Praxis sehe ich auch bei guten Tools, daß die Nicht-Profis (und ggf. auch Profis) selbst dann noch viele Fehler machen, bzw. Raum für Verbesserungen lassen. Alles bedenken kann auch das beste Tool IMHO nicht, oder es verleidet dem Autor die Arbeit, weil sie ständig nachfragt und anmahnt. Und auch wenn das geboten wäre, damit will dann kein Laie mit arbeiten. Hauptsache, "sieht gut aus".
Na ja, wird man halt auch nicht arbeitslos. Das hat ja ebenfalls einen Wert ... ;-)
Gruß, Cybaer
Tja "Abwärtskompatibilität"... manchmal wäre eine gekapselte Emulatorschicht und ein Neuanfang besser. Nicht nur bei HTML, auch z.B. bei Windows. MacOS hat mehrere solcher Schritte überlebt, also ganz unmöglich ist es nicht.
Nein. Aber nicht gewollt.
Von wem nicht gewollt? Den Browserherstellern? Den Webautoren? Der breiten surfenden Masse?
Ich denke ein XHTML 2 parallel zu HTML4 wäre genau das richtige. Wem die strengen Regeln auf die Nerven gehen kann ja beim alten bleiben. Die Existenz bestehender Webseiten wäre ebenfalls nicht gefährdet.
Die Browserhersteller waren nicht willens, bzw. sahen sich generell nicht in der Lage, HTML mit XHTML 2 abzulösen. Die Gründe waren viele, und gingen bis hin zum "XML ist im Web gescheitert - wir sollten aus unseren Fehlern lernen, komplett von vorne anfangen". Gleichzeitig ging es ihnen auf den Sack, daß HTML (und mit dem stockenden XHTML auch gleich die ganze Webentwicklung) jahrelang nicht mehr vorwärts kam.
Übersetzung: Die Browserhersteller haben erst die Weiterentwicklung selbst behindert und sich dann darüber geärgert. Es lag sicher nicht am W3C, dass XML im Web gescheitert ist.
Abstrahiert würde ich sagen: Irgendwann werden wir was Neues haben. Was, kann man noch nicht sagen. Aber mom. ist die Zeit wohl noch nicht reif dafür. Übergangsweise wird HTML weiterentwickelt. Leben wir damit, und ärgern uns nicht darüber. Der menschlichen Schwächen sind so viele, da ist diese Problem wirklich eher luxuriöser Natur ... :-)
Übergangsweise? Das glaubst du doch wohl selbst nicht. Sauberes Markup ist im Web *von den Browserherstellern* offenbar nicht gewünscht. Also wird es entweder nach HTML 5 HTML 6, 7, etc. geben oder man verzichtet gleich ganz auf Standardisierung.
Ich hätte mir auch eher modulare Standards à la XHTML 1.1 (die modularisierte Variante) gewünscht, dann könnte man Teile separat weiterentwickeln.
Und ich geb ihm in dem Punkt eindeutig Recht.
Da fragt man sich wirklich: Wie konnte das WWW nur ohne gescheite Tools jaemals soooo erfolgreich werden. ;-)
Wenn eine Idee weithin angenommen wird, kann sie erfolgreich sein, selbst wenn die konkrete Umsetzung völliger Mist ist.
Was zumindest Tim Berner-Lee sich nicht so vorgestellt haben mag. Entwickler gab es mehr. Aber ich gebe ja zu: Meine sich über all die Jahre gewachsene Abneigung des W3Cs wg. seiner Praxisferne, bezieht sich durchaus auch auf den Großen Vorsitzenden (ohne seine geniale Grundidee damit schmälern zu wollen). Was wirklich Richtungsweisendes ist mir jetzt so spontan allerdings auch nicht weiter in Erinnerung ...
... zumindest was praxisnahe und umsetzbare, geschweige denn umgesetzte Ideen angeht.
Komisch, Dinge wie XML wurden außer im Web sehr gut angenommen, eigentlich dort auch - Feeds stehen auf XML-Füßen, Browser kennen XML-HTTP-Requests. Auch die Weiterentwicklung von DOM und CSS findet weitestgehend beim W3C statt, da haben die Browserhersteller auch offenbar kein Problem mit. XPath ist ebenfalls bei einigen implementiert, Unterstützung für SVG und MathML ist bei manchen auch eingebaut.
Gegen XHTML stemmt man sich hingegen mit Händen und Füßen - warum?
Na ja, wird man halt auch nicht arbeitslos. Das hat ja ebenfalls einen Wert ... ;-)
Gesamtwirtschaftlich gesehen nicht, Arbeit, die hätte vermieden werden können, kostet, bringt aber nichts ein.
Auch die Weiterentwicklung von DOM und CSS findet weitestgehend beim W3C statt, da haben die Browserhersteller auch offenbar kein Problem mit.
Das DOM wird nicht mehr weiterentwickelt. Stattdessen gibt es verschiedene lose Specs der W3C WebApps WG. Davon sind eigentlich nur folgende aktiv und werde implementiert:
Für vielversprechende Standards wie DOM 3 Events sehe ich wenig Zukunft.
Von CSS kann man eigentlich auch behaupten, dass es nicht mehr weiterentwickelt wird. ;)
Gegen XHTML stemmt man sich hingegen mit Händen und Füßen - warum?
Es hat keinen Mehrwert außer etwa die Einbindbarkeit von anderen XML-Sprachen.
Mathias
Yerf!
BTW: Interessanter Punkt, da ja auch in ECMAScript darüber gestritten wird.
Solange sie den Sprachkern nicht anfassen sind Änderungen ja unproblematisch, da man Objekte und deren Features abfragen kann. Allerdings hab da so was am rande mitbekommen, dass sie über Änderungen am Kern nachdenken...
Bei C-Kompilern gibts ja teilweise auch den Schalter zwischen K&R oder ANSI...
Ich denke ein XHTML 2 parallel zu HTML4 wäre genau das richtige. Wem die strengen Regeln auf die Nerven gehen kann ja beim alten bleiben. Die Existenz bestehender Webseiten wäre ebenfalls nicht gefährdet.
Die Browserhersteller waren nicht willens, bzw. sahen sich generell nicht in der Lage, HTML mit XHTML 2 abzulösen. Die Gründe waren viele, und gingen bis hin zum "XML ist im Web gescheitert - wir sollten aus unseren Fehlern lernen, komplett von vorne anfangen". Gleichzeitig ging es ihnen auf den Sack, daß HTML (und mit dem stockenden XHTML auch gleich die ganze Webentwicklung) jahrelang nicht mehr vorwärts kam.
Am SCheitern sind aber vor allem die Browserhersteller schuld, da sie es nicht annehmen wollten. Hätten sie das mal gemacht und sich noch etwas mit eingebracht müssten sie jtzt auch nicht drüber jammern, das bei HTML nichts vowärts ging (denn man hätte ja jetzt XHTML2 als Alternative)...
Abstrahiert würde ich sagen: Irgendwann werden wir was Neues haben.
Diesen Optimismus bin ich gerade dabei zu verlieren... Es gibt nur noch wenig Gebiete wo wirklich etwas neues kommt und das dann auch nur bei "Hardware" wo es einfach nicht anders geht (als Beispiel muss ich hier schon so "Innovationen" wie BluRay nennen... :-(
Leben wir damit, und ärgern uns nicht darüber. Der menschlichen Schwächen sind so viele, da ist diese Problem wirklich eher luxuriöser Natur ... :-)
In dem Fall schon, leider gibts noch merh Gebiete in denen das so läuft. Ich nenn jetzt nur mal die Automobil-Industrie... immernoch kompatibel zum altbewärten Sprit bei ähnlichem Verbrauch. (ich weis, hat jetzt nichts mit dem Thema an sich zu tun, aber spielt zumindest bei mir in die subjektiven Ansichten mit rein)
vielleicht sollte man die Energie weniger in Fehlertoleranz bei den Browsern sondern mehr in die Entwicklung guter Tools zur Seitenerstellung stecken?
Wobei ich da auch erst wirklich Hoffnung habe, wenn das "IE-Problem" erledigt ist ...
Stimmt, ohne IE wäre es einfacher solche Tools zu verkaufen (welche zu entwickeln die den IE berücksichtigen ist eher utopisch)
Spätestens wenn man einen inkompatiblen neuen Standard hat muss man unterscheiden.
Was man aber auch nicht am Doctype festmachen muß (und IMHO auch nicht sollte).
Nur woran dann? Mime-types stehen nicht in jeder Situation zur Verfügung (z.B. direktes öffnen von der HD) und ein "Raten" aufgrund des Inhalts ist fehlerträchtig und/oder aufwändig. Nicht umsonst haben die meisten Formate einen Typischen Header, meist inklusive Versionsinformation.
Mein Traum wäre natürlich immer einen externen Mime-Type zur Verfügung zu haben, aber das ist wirklich Utopie... Die einzigen Systeme die ich kenne und sowas im Ansatz hatten waren GEOS (C-64) und Amiga OS (die .info-Files)
Und ich geb ihm in dem Punkt eindeutig Recht.
Da fragt man sich wirklich: Wie konnte das WWW nur ohne gescheite Tools jaemals soooo erfolgreich werden. ;-)
Klar kann man auch mit einem "suboptimalen" Produkt erfolgreich sein. (Manchmal denk ich sogar, dass die Voraussetzung ist, man denke nur an Windows oder VHS). Aber muss es denn dabei bleiben?
Wir brauchen zuerst einmal Browser, bei denen WYSIWYG-Code auch wirklich darstellt, was man sieht. Wenn das gegeben ist, dann sehen wir mal weiter ...
Hm, dass das immer ein WYSIWYMG (what you see is what you might get) bleibt ist klar, aber wenn der Editor auf einer "guten" Engine basiert sollte das kein Problem sein. Und der IE gehört Gesetzlich verboten! ;-)
(vielleicht hätte es das w3c so machen sollen wie Sun mit Java, HTML rechtlich schützen lassen und Microsoft verklagen)
Ein "PDF für's Web" kann mich bislang jedenfalls nicht überzeugen ...
Ganz unproblematisch ist das ganze sicher nicht, aber ich bin mir sicher, das die Ergebnisse besser sind, als was Otto-Normaluser mittels Notepad und HTML-Tags zusammenschustert.
Klar muss man schauen, das man per guter Hilfe und Einführung den Anwender in einem WYSIWYG-Editor in die richtige Richtung führt. Auch wenn man auf diesem Weg "Formatierungen" per Space und Return (wie auch in Word üblich, obwohl unnötig) nicht verhindern können wird...
Wichtiges Problem: Was nützt so etwas, wenn doch so viele zufrieden sind, mit dem, was sie haben (Entwicklung mit dem IE, sieht auf dem IE gut aus, wen interessiert der Rest).
Ja... langsam stoßen wir glaub ich auf den *wirklichen* Kern des Problems. Die große Masse ist mit dem was sie hat zufrieden und fragt sich wieso man soviel Energie in Weiterentwicklung steckt. Sie übersehen dabei, das der jetzige Zustand aber nur über Weiterentwicklungen erreicht werden konnte...
Querdenker und Visionäre sind notwendig um nicht im Stillstand zu versinken.
Was wirklich Richtungsweisendes ist mir jetzt so spontan allerdings auch nicht weiter in Erinnerung ...
... zumindest was praxisnahe und umsetzbare, geschweige denn umgesetzte Ideen angeht.
Zumindest die Grundidee aus dem Zitat erlebt inzwischen ihre Erfüllung in den Wiki-Projekten. Ich denke die sind genau das, was Tim im Sinn hatte. Jeder kann ohne großen Aufwand sein Wissen oder seine Meinung veröffentlichen (und das auch noch im Browser und ohne HTML).
Gruß,
Harlequin
erklärt man das Chaos zum Standard.
Ja und nein. Natürlich kann man Techniken, die sich seit 10 Jahren durchgesetzt haben und breit implementiert sind, einfach verwerfen und eine schöne, saubere brandneue und lückenlos definierte API entwerfen. Das macht man teilweise, wo alte APIs nicht ausgebaut werden können. Die Wahrscheinlichkeit, dass alle Browserhersteller das Rad neu erfinden, zumal wenn dieselben Features unter anderem Namen schon implementiert sind, ist aber sehr gering.
Vielleicht bin ich auch einfach viel zu viel Programmierer, als dass ich micht solch einem Wischiwaschi-Standard abfinden könnte.
Was heißt denn Wischiwaschi? Wischiwaschi ist die gegenwärtige unspezifizierte (X)HTMLCSSJavaScript-Praxis.
Mathias
warum nicht jeden browser zwangsläufig validieren lassen
Genau, warum baut man nicht in jede S-Bahnen gleich einen Gleismesswagen, eine Schotterplaniermaschine und eine Bettungsreinigungsmaschine ein?
Mathias
warum nicht jeden browser zwangsläufig validieren lassen
Genau, warum baut man nicht in jede S-Bahnen gleich einen Gleismesswagen, eine Schotterplaniermaschine und eine Bettungsreinigungsmaschine ein?
weil "die bahn" ihre geleise nach entsprechenden spezifikationen fertigt und diese auch einhält, ohne dass dieses kontrolliert werden muss
wenn jeder webautor die spezifikationen einhielte und jeder browser immer absolut standardkonform arbeitete, wärs kein problem
zum thema s-bahn: soweit ich weiss fahren s-bahnen genauso wie "normale" eisenbahnen in deutschland mit 1435 mm spurweite, wenn sich die spurweite an einem grenzbahnhof ändern sollte, sagen wir auf 1600 mm, wird die lokomotive beinhart weiterfahren, es wird rumpeln, das ding entgleist und es sagt "njet, mag nicht mehr" - und genau das soll auch ein browser tun: code den er nicht versteht einfach nicht akzeptieren und den betrieb einstellen ;)
Genau, warum baut man nicht in jede S-Bahnen gleich einen Gleismesswagen, eine Schotterplaniermaschine und eine Bettungsreinigungsmaschine ein?
weil "die bahn" ihre geleise nach entsprechenden spezifikationen fertigt und diese auch einhält, ohne dass dieses kontrolliert werden muss
Doch, was meinst du, wofür die genannten Techniken da sind? Damit die Bahn die Strecke warten kann, wenn gerade kein normaler Verkehr ist. Nicht damit die Strecke gleichzeitig während des Befahrens geprüft und repariert wird. Das wäre nämlich Unsinn.
Mathias
Das wäre nämlich Unsinn.
sehe ich nicht so - ich erwarte von technischen gerätschaften einen rudimentären selbsttest - zumindest sporadisch oder beim starten
wenn ich den zündschlüssel von meiner karre drehe, sagt mir das ding auch, dass zu wenig öl drinnen ist - fürher musste man selbst mit dem messstab nachsehen und alle paartausend kilometer dran denken
wenn ich den zündschlüssel von meiner karre drehe, sagt mir das ding auch, dass zu wenig öl drinnen ist - fürher musste man selbst mit dem messstab nachsehen und alle paartausend kilometer dran denken
Genau, das Auto testet sich selbst, nicht die Straße, auf der es fährt. Schlaglöcher merkt es der Fahrer ohnehin. Entsprechend weiß der Browser, was er kann, aber muss deshalb nicht ständig Websites validieren.
Mathias
Hi,
nein, ich find nur den doctype etwas geschacklos bzw dass sich die html5-verschlimmbesserer herrausnehmen, einen "neutralen" doctype zu erfinden, der browser wirds schon verstehen, was gemeint ist
HTML benötigte ursprünglich überhaupt keinen Doctype. Das wird jetzt mit HTML 5 wieder aufgegriffen. Und bei HTML 5 ist der Doctype nur aus technischen Gründen *ggf.* geboten (s. Parallelpost).
Es *soll* keine HTML-"Versionen" mehr geben. Es wurde auch ein Versions-Attribut diskutiert - und verworfen. Es gibt zukünftig nur noch HTML - oder eben Nicht-HTML.
ich find den doctype-switch gut und eine genaue und möglichst exakte angabe sinnvoll
Zur Doctype-Sniffing-Katastrophe hat ja Gunnar schon was gesagt. Und wem soll eine Versionsangabe helfen? Die Browserhersteller finden sie ja ohnehin nicht nötig. Und ich bin in all den Jahren eigentlich auch ganz gut ohne sie ausgekommen (wenn ich wg. des überaus dämlichen Doctype-Sniffings dazu gezwungen wurde, habe ich eh einen eigenen Doctype verwendet).
Möchtest Du eigentlich bei JS und CSS auch eine Versionsangabe einführen, oder warum sollte dieser Irsinn auf HTML beschränkt bleiben? ;->
mir scheint so, als will man html 5 "irendwie durchwürgen" ohne sich über den genauen umfang im klaren zu sein und schaut mal nach, was die browserentwickler so alles implementieren
Wenn 2 Hersteller alles implementiert haben, wird HTML 5 offiziell verabschiedet. Und BTW: HTML 5 *ist* von den "Browserentwicklern" ...
Gruß, Cybaer
Yerf!
Wenn 2 Hersteller alles implementiert haben, wird HTML 5 offiziell verabschiedet.
Ich werd mich wohl schon jetzt davon verabschieden... *good bye*
Und BTW: HTML 5 *ist* von den "Browserentwicklern" ...
Könnte erklären wieso es derart weit an manchen Bedürfnissen der (Seiten-)Authoren vorbeigeht.
(z.B. die Möglichkeit alles zu verlinken. Nein, ein "magisches" <a> um Elemente ist *keine* gute Idee, haben sie aber zum Glück selber gemerkt...)
Gruß,
Harlequin
PS: ja, ich habs versucht mich damit anzufreunden, aber ein tieferes Einlesen in die Spec und die Diskussionen brachte eher Frust als Erleuchtung...
Hi,
Wenn 2 Hersteller alles implementiert haben, wird HTML 5 offiziell verabschiedet.
Ich werd mich wohl schon jetzt davon verabschieden... *good bye*
Kein Problem! Schließ die Tür, wenn Du gehst! ;->
Und BTW: HTML 5 *ist* von den "Browserentwicklern" ...
Könnte erklären wieso es derart weit an manchen Bedürfnissen der (Seiten-)Authoren vorbeigeht.
Es gibt verdammt viele Autoren. Offensichtlich teilen nicht alle *deine* "Bedürfnisse" ...
PS: ja, ich habs versucht mich damit anzufreunden, aber ein tieferes Einlesen in die Spec und die Diskussionen brachte eher Frust als Erleuchtung...
Für mich war das W3C auf dem Irrweg. Auch wenn mir vielleich tnicbht alles gefällt: Ich kann HTML 5 absolut nachvollziehen. Seine Entstehung, die Begründung, die Elemente.
Ich denke so wie die - und fühle mich damit auch entsprechend wohl. Ist ein bißchen wie "HTML is coming home ..." (bierselig röhl) ;->
Gruß, Cybaer
Hallo,
(z.B. die Möglichkeit alles zu verlinken. Nein, ein "magisches" <a> um Elemente ist *keine* gute Idee, haben sie aber zum Glück selber gemerkt...)
Die Browserhersteller sagen, die wäre zu schwer zu implementieren. Was von diesen auch ein Kritikpunkt an XHTMl 2 ist. Es gibt aber auch Leute, die Argumentieren, diese Art Feature wäre nicht unmöglich.
Naja, wer Recht hat weis ich leider nicht.
PS: ja, ich habs versucht mich damit anzufreunden, aber ein tieferes Einlesen in die Spec und die Diskussionen brachte eher Frust als Erleuchtung...
Nicht alles ist toll, aber es wird vieles standardisiert, das wir aktuell nur einfach so verwenden, weil es da ist, z.B. das window-Object. Das Fördert letztendlich doch ein wenig Interoperabilität.
@@Daniel unreg:
(z.B. die Möglichkeit alles zu verlinken. Nein, ein "magisches" <a> um Elemente ist *keine* gute Idee, haben sie aber zum Glück selber gemerkt...)
Die Browserhersteller sagen, die wäre zu schwer zu implementieren. Was von diesen auch ein Kritikpunkt an XHTMl 2 ist. Es gibt aber auch Leute, die Argumentieren, diese Art Feature wäre nicht unmöglich.
<foo onclick="[code lang=javascript]window.location.href = 'http://example.net';"><bar/></foo>[/code] ist implementiert. 'foo' kann dabei beliebige Elemente enthalten.
Warum sollte man dafür dann nicht auch <foo href="http://example.net"><bar/></foo> schreiben können?
'foo' kann auch nur für den 'a'-Elementtypen stehen, wenn man das nicht für beliebige Elemente implementieren möchte (warum auch immer?).
Wo sollen die Probleme der Implementierung eines „magischen“ 'a' liegen?
Live long and prosper,
Gunnar
Hallo,
<foo onclick="[code lang=javascript]window.location.href = 'http://example.net';"><bar/></foo>[/code] ist implementiert. 'foo' kann dabei beliebige Elemente enthalten.
Warum sollte man dafür dann nicht auch
<foo href="http://example.net"><bar/></foo>schreiben können?
'foo' kann auch nur für den 'a'-Elementtypen stehen, wenn man das nicht für beliebige Elemente implementieren möchte (warum auch immer?).
Ich verstehe schon, was du sagen willst, Eric Meyer hat vor kurzem nicht anders argumentiert.
Wo sollen die Probleme der Implementierung eines „magischen“ 'a' liegen?
Das fragst du am besten die Browserhersteller. Wenn ich mich nicht irre hat z. B. Mozilla damals angegeben, eine derartige Implementierung wäre nicht möglich.
Gruß.
Yerf!
<foo onclick="[code lang=javascript]window.location.href = 'http://example.net';"><bar/></foo>[/code] ist implementiert. 'foo' kann dabei beliebige Elemente enthalten.Warum sollte man dafür dann nicht auch
<foo href="http://example.net"><bar/></foo>schreiben können?
Eine der Begründungen war, das dann auch die Pseudoelemente (:link usw.) von CSS für alle Elemente implementiert werden müssen. Aber ob das so schwierig ist?
Wo sollen die Probleme der Implementierung eines „magischen“ 'a' liegen?
Das "magische" <a> das ich angesprochen hab war ein Gegenvorschlag als Ersatz für das href-Attribut für alle Elemente aus der HTML5 Mailingliste. Das Problem dabei ist aber vor allem das uneinheitliche DOM. Schau dir einfach mal an, was bei einer Tabelle passiert, wenn man um einige Zeilen einen Link legt... (also die was dann die direktwen Kinder von TBODY sind)
Gruß,
Harlequin
@@Cybaer:
Und BTW: HTML 5 *ist* von den "Browserentwicklern" ...
Das lässt nich nicht verheimlichen.
Live long and prosper,
Gunnar
Hallo Cybaer,
Möchtest Du eigentlich bei JS und CSS auch eine Versionsangabe einführen, oder warum sollte dieser Irsinn auf HTML beschränkt bleiben? ;->
<script type="application/javascript;version=1.8;e4x=1"> ;)
Tim
<script type="application/javascript;version=1.8;e4x=1">;)
Oh, ja!
function rot13 (x) {
var ao = 26, start = [start for each (start in [65, 97]) if (x >= start && x < start + ao)][0];
return start ? x + (x - start >= 13 ? -1 : 1) * 13 : x;
}
alert([String.fromCharCode(x) for each (x in [rot13(x) for each (x in [c.charCodeAt(c) for each (c in "Clguba va WninFpevcg!")])])].join(""));
Mathias
ein hoch darauf, dass html 5 noch früh genug stirbt und einem ordentlich durchdachten xhtml 2.0 weichen uss
Autos werden nicht Flugzeugen weichen und Eisenbahnen nicht Schiffen. Aus demselben Grund wird HTML 5 nicht XHTML 2 weichen und XHTML 2 nicht HTML 5.
Mathias
ein hoch darauf, dass html 5 noch früh genug stirbt und einem ordentlich durchdachten xhtml 2.0 weichen uss
Autos werden nicht Flugzeugen weichen und Eisenbahnen nicht Schiffen. Aus demselben Grund wird HTML 5 nicht XHTML 2 weichen und XHTML 2 nicht HTML 5.
du mit deinen verkehrsmittelvergleichen, die hinken etwas (oder rollen?)
hd dvd ist auch blu-ray gewichen, video 2000 und betamax haben auch gegen vhs "verloren"
aber wie ist es mit standards: es gibt mehrere davon und jeder will einen machen, weil er glaubt, seiner sei besser (bzw weil er den mitbewerber verdrängen will)
hd dvd ist auch blu-ray gewichen, video 2000 und betamax haben auch gegen vhs "verloren"
Ja, weil ihr Zweck im Groben derselbe war. Der Zweck von HTML 5 und XHTML 2 ist nicht derselbe, es gibt (wenn man noch den Rest der W3C-XML-Platform hinzunimmt) höchstens einige Überschneidungen. Und diese sind sich nichtmal unähnlich, sondern sind lediglich bewusst unterschiedliche Ansätze, die andere Schwerpunkte setzen und in verschiedener Hinsicht leistungsfähig sind.
Mathias
hd dvd ist auch blu-ray gewichen, video 2000 und betamax haben auch gegen vhs "verloren"
Ja, weil ihr Zweck im Groben derselbe war. Der Zweck von HTML 5 und XHTML 2 ist nicht derselbe, es gibt (wenn man noch den Rest der W3C-XML-Platform hinzunimmt) höchstens einige Überschneidungen. Und diese sind sich nichtmal unähnlich, sondern sind lediglich bewusst unterschiedliche Ansätze, die andere Schwerpunkte setzen und in verschiedener Hinsicht leistungsfähig sind.
ich dachte der sinn und zweck der verschiedensten html-derivate ist das auszeichnen von text-informationen
der sinn von html 5 scheint mir eher in richtung "auszeichnung von web 2.0 anwendungen und blogs" zu gehen - allein das "aside"-element, welches extra dafür da ist einen sidebar auszuzeichnen, schreit doch gradezu danach
es gibt einige ansätze in html 5 die ich sehr gut finde, nur der überwiegende teil der ansätze ist für mich einfach nur unverständlich - die xhtml-2.0-ansätze sind für mich teilweise zwar auch nicht ganz nachvollziehbar, der überwiegende teil stimmt aber besser mit meinen bedürfnissen überein (text logisch auszuzeichnen)
ich dachte der sinn und zweck der verschiedensten html-derivate ist das auszeichnen von text-informationen
HTML 4 war schon viel mehr als das »Auszeichnen von Text-Informationen«, es ging schon damals um Hypertext-Anwendungen. Auf XHTML 2 trifft das noch am ehesten zu, aber nur, wenn man die ganzen Zusätze wie XForms und XML Events sowie den Rattenschwanz an zugehörigen XML-Sprachen wie SVG, MathML, Ruby und RDF rausnimmt und den starken Fokus auf Hypermedialität ausblendet.
Insofern werden hier ständig Äpfeln mit Birnen verglichen. Die Neustrukturierung der Textauszeichnung bzw. Dokumentbeschreibung samt Metainfos, Hyperlinks, Medieneinbettung usw. ist die Aufgabe von XHTML 2, aber nur eine, vergleichsweise kleine Säule von HTML 5. Man kann natürlich beide in genau dieser Hinsicht vergleichen, es kommt aber, wenn man diesen fundamentalen Unterscheid nicht sieht, nichts Kluges dabei heraus, siehe die jüngste sinnlose Diskussion über object in XHTML 2 versus video in HTML 5. Wer HTML 5 bloß als Textauszeichnungssprache sieht, der hat grundsätzlich missverstanden, was der Sinn dieser Spezifikation ist.
der sinn von html 5 scheint mir eher in richtung "auszeichnung von web 2.0 anwendungen und blogs" zu gehen - allein das "aside"-element, welches extra dafür da ist einen sidebar auszuzeichnen, schreit doch gradezu danach
aside ist jeder Content, der vom Hauptcontent aus eine Neben- und Zusatzinfo darstellt. Was das notwendigerweise mit Weblogs zu tun haben muss, ist mir schleierhaft. Seitenspalten gibt es schon in religiösen mittelalterlichen Texten und in jedem heutigen Zeitungsartikel.
Mathias
Yerf!
HTML 4 war schon viel mehr als das »Auszeichnen von Text-Informationen«, es ging schon damals um Hypertext-Anwendungen.
"Hypertext" ist sicherlich ein zentraler Punkt von HTML, dafür wurde es geschaffen. Aber was siehst du in diesem Punkt als "Anwendung"? Ich denke nicht, dass es bei HTML4 um die Möglichkeit ging, Desktopanwendungen ins Web zu bringen, sondern eher um eine Vernetzung von Informationen .
Auf XHTML 2 trifft das noch am ehesten zu, aber nur, wenn man die ganzen Zusätze wie XForms und XML Events sowie den Rattenschwanz an zugehörigen XML-Sprachen wie SVG, MathML, Ruby und RDF rausnimmt und den starken Fokus auf Hypermedialität ausblendet.
Die Hypermedialität sehe ich wie gesagt als einen zentralen Bestandteil der nicht ausgeklammert werden kann. Uns der Rest ist ja optional. Gerade in dieser Modularität sehe ich auch eine der Stärken von XHTML.
Insofern werden hier ständig Äpfeln mit Birnen verglichen. Die Neustrukturierung der Textauszeichnung bzw. Dokumentbeschreibung samt Metainfos, Hyperlinks, Medieneinbettung usw. ist die Aufgabe von XHTML 2, aber nur eine, vergleichsweise kleine Säule von HTML 5.
Die mir bei der Entwicklung von HTML 5 auch etwas zu kurz kommt.
Aber das Problem ist ein anderes: du sagst, das HTML5 XHTML2 nicht verdrängen wird, aber genau das wird kommen. Was bringt ein Dokumentformat, wenn es keine Software gibt, die es unterstützt? Oder werden die Browserhersteller wenn HTML5 endlich fertig ist anfangen XHTML2 zu implementieren? Natürlich kann ich trotzdem Seiten in XHTML2 verfassen, daran werde ich genauso wenig gehindert wie daran Filme auf HD-DVD anstatt BluRay zu veröffentlichen.
Wer HTML 5 bloß als Textauszeichnungssprache sieht, der hat grundsätzlich missverstanden, was der Sinn dieser Spezifikation ist.
Was will HTML5 dann sein, ein Ersatz für Flash, als Grundlage für ein "Web 3.0"? Aus der Blickrichtung könnt ich mich sogar damit anfreunden. Allerdings würde dies auch eine *gleichberechtigte* Koexistenz von HTML5 und XHTML2 voraussetzen.
Gruß,
Harlequin
Aber was siehst du in diesem Punkt als "Anwendung"?
Eine interaktive Website. Schon HTML 4 ging mit Formularen, Scripting, Frames usw. über bloße Textauszeichnung bzw. Dokumentbeschreibung hinaus.
du sagst, das HTML5 XHTML2 nicht verdrängen wird, aber genau das wird kommen.
Diese Aussage verkennt die Lage verkennt dass HTML 5 eine Neudefinition der derzeitigen HTML-Praxis mit Zusätzen und Vereinheitlichungen leistet. Diese Plattform ist selbstständig weiter gewachsen, hat unglaublich viel Quasi-Standards hervorgebracht, die jetzt spezifiziert werden. Diese Plattform existiert und entwickelt sich durch HTML 5 höchstens weiter.
Was bringt ein Dokumentformat, wenn es keine Software gibt, die es unterstützt?
Ja, aber warum nur? Weniger, weil die Browserhersteller kein Interesse an einer konsistenten Auszeichnungssprache wie XHTML 2 haben. Sie haben wenig Interesse, eine komplett neue Plattform zu implementieren. Zumal diese Plattform in ihrer jetzigen Form auf die gegenwärtigen Fragen keine Antworten bringt. Browserquirks bei der Verarbeitung von HTML und beim Scripting - damit beschäftigt sich XHTML 2 gar nicht, weil es eine neue hypothetische Wunderwelt schafft, in der das gegenwärtige Web als Herausforderung für praxistaugliche Browser überhaupt nicht existiert. Spannend würde XHTML 2 da, wo es ein gleichwertiges DOM anbietet, das nur halbwegs die Features von HTML 5 bietet. Darauf liegt das Hauptaugenmerk von HTML 5. Man ist sogar soweit gegangen, vom DOM aus zu denken, während XHTML 2 nur eine Serialisierung kennt (bzw. der Terminus macht gar keinen Sinn, wenn man nicht vom DOM aus spezifiziert). Nun ist XHTML 2 aber nicht DOM 3 XHTML, und schon gar nicht der Versuch, bestehende JavaScript-Techniken zu standardisieren.
Oder werden die Browserhersteller wenn HTML5 endlich fertig ist anfangen XHTML2 zu implementieren?
Wer weiß. Im Grunde dürfte es kein großer Aufwand sein. Schwierig wird es bei den Zusätzen wie XForms.
Was will HTML5 dann sein, ein Ersatz für Flash, als Grundlage für ein "Web 3.0"?
Zuerst einmal eine Grundlage für User-Agents für den Umgang mit dem derzeitigen Web. Darüber hinaus stehen interaktive (bessere Formulare, Menüs, spezifische Medieneinbettung) und Scripting-Techniken im Vordergrund. Also durchaus ggf. JavaScript-intensive Webanwendungen.
Mathias
Yerf!
du sagst, das HTML5 XHTML2 nicht verdrängen wird, aber genau das wird kommen.
Diese Aussage verkennt die Lage verkennt dass HTML 5 eine Neudefinition der derzeitigen HTML-Praxis mit Zusätzen und Vereinheitlichungen leistet. Diese Plattform ist selbstständig weiter gewachsen, hat unglaublich viel Quasi-Standards hervorgebracht, die jetzt spezifiziert werden. Diese Plattform existiert und entwickelt sich durch HTML 5 höchstens weiter.
Hm, so gesehen ist "verdrängen" vielleicht das falsche Wort, aber das Ergebnis bleibt: ein HTML 5 mit breiter Unterstützung durch die Browserhersteller lässt kaum Luft für ein 2. Hypertext-Format. Dafür sind sie dann doch zu ähnlich in ihrer Anwendung, auch wenn sie unterschiedliche Ansätze verfolgen.
Ja, aber warum nur? Weniger, weil die Browserhersteller kein Interesse an einer konsistenten Auszeichnungssprache wie XHTML 2 haben. Sie haben wenig Interesse, eine komplett neue Plattform zu implementieren.
Hier überwiegen wohl vor allem wirtschaftliche Überlegungen, dass man lieber das Vorhandene weiterentwickelt, anstatt einen Stillstand inkauf zu nehmen, bis eine neue Technologie einsatzbereit ist.
Browserquirks bei der Verarbeitung von HTML und beim Scripting - damit beschäftigt sich XHTML 2 gar nicht, weil es eine neue hypothetische Wunderwelt schafft, in der das gegenwärtige Web als Herausforderung für praxistaugliche Browser überhaupt nicht existiert.
Eben das ist es, was *ich* so gut finde. Aber ich muss leider immer wieder feststellen, dass die meisten Leute da eine andere Überzeugung haben.
Manchmal ist es besser alte Zöpfe abzuschneiden, als auf eine "gewachsene" Basis mit all ihren Problemen immer noch weiter was draufzubauen. (Ein anderes bekanntes Beispiel dafür ist für mich Windows)
Nun ist XHTML 2 aber nicht DOM 3 XHTML, und schon gar nicht der Versuch, bestehende JavaScript-Techniken zu standardisieren.
Dies hätte parallel dazu in einer eigenen Arbeitsgruppe stattfinden müssen...
Was will HTML5 dann sein, ein Ersatz für Flash, als Grundlage für ein "Web 3.0"?
Zuerst einmal eine Grundlage für User-Agents für den Umgang mit dem derzeitigen Web. Darüber hinaus stehen interaktive (bessere Formulare, Menüs, spezifische Medieneinbettung) und Scripting-Techniken im Vordergrund. Also durchaus ggf. JavaScript-intensive Webanwendungen.
Nur fürchte ich, das es wohl auch für die Szenarien verwendet werden wird, für die XHTML2 besser geeignet wäre, denn wer will schon 2 Techniken erlernen, wenn eine auch reicht?
Aber ich glaub die Diskussion hier führt zu nichts... Ich werd wohl damit leben müssen, dass HTML5 die Zukunft ist, genauso wie ich mit Windows als OS auskommen muss.
Gruß,
Harlequin
Nur fürchte ich, das es wohl auch für die Szenarien verwendet werden wird, für die XHTML2 besser geeignet wäre, denn wer will schon 2 Techniken erlernen, wenn eine auch reicht?
und das sagst du mir jetzt erst - du meinst, ich hätte auf vb/asp verzichten sollen? php hätte gereicht?
Aber ich glaub die Diskussion hier führt zu nichts... Ich werd wohl damit leben müssen, dass HTML5 die Zukunft ist, genauso wie ich mit Windows als OS auskommen muss.
bei windows ist es eine marketingentscheidung, weil der 08/15-dau sonst "feuer" schreit, wenn seine uralt-software nicht mehr auf dem neuesten windows läuft
nachdem html doch eher in einen technik-affineren kontext fällt und von normalen menschen mit editoren erstellt wird, die gültigkeit des codes sowieso egal ist, spräche nichts dagegen, beides parallel zu versuchen bzw bei html 4.01 zu bleiben um xhtml weiterzuentwickeln
html 5 kann im vergleich zu html 4 nicht sonderlich viel weniger - interessanter wäre eher eine breitflächigere unterstützung von css 2.1 bzw in weiterer folge css 3 und das zwangsweise aussterben alter browser
mich kotzt es an, dass sich die leute alle 6 monate ein neues handy anschaffen, aber beim browser 8 jahre waren und das hinter dem vorwand, der ie7 hätte so viele sicherheitslücken ...
Hi,
macht es überhaupt Sinn einen Standard zu verwenden, der noch gar keiner ist?
Natürlich.
So ziemlich alle beliebten Webseitenfeatures wurden fleissig vor ihrer Standardisierung eingesetzt - deswegen wurden sie standardisiert. Das W3C hechelte der Zeit immer hinterher ...
... und konnte originär eigene Vorstellungen oft nicht verwirklichen (lassen).
Schließlich kann sich ja an HTML 5 noch so einiges ändern bis zum Release
Klar, aber wenig wahrscheinlich, daß sich grundlegendes ändert, bzw. daß die Browserimplementationen nachträglich (und auf inkompatible Weise) geändert werden müssen.
Und auch Standards sind vor Änderungen nicht gefeit (HTML 4->4.01, CSS 2->2.1).
(wann ist das eigentlich?)
Wenn zwei der gängigen Browser HTML 5 komplett implementiert haben.
Gruß, Cybaer
Hallo,
jetzt möchte ich z.b. das
video-tag benutzen.
die frage ist nur welchen Doctype soll ich benutzen?
Das spielt keine* Rolle. Es ist aber zu empfehlen, dass du den verwendest, den du auch sonst verwenden würdest, also HTML 4.01 bzw. XHTML 1.0 als Strict- oder Transitional-Variante. Der HTML 5 doctype sollte erst eingesetzte werden, wenn HTML 5 von 2 oder mehr Browsern unterstützt wird. Dann erst ist HTML 5 eine Empfehlung des W3C.
* Browser unterscheiden nicht zwischen HTML Versionen. Sie besitzen jedoch unterschiedliche Darstellungsmodi. Wenn du HTML-5-Features verwenden möchtest, solltest du darauf achten, nicht den Quirksmode zu verwenden, denn in diesem macht der IE keine Fortschritte bezüglich irgendweines Standards. In den standardkonformen Modi machen dagegen alle Browser Fortschritte in der HTML-5-Implementierung.
Gruß
Der HTML 5 doctype sollte erst eingesetzte werden, wenn HTML 5 von 2 oder mehr Browsern unterstützt wird. Dann erst ist HTML 5 eine Empfehlung des W3C.
Ich dachte, es ist das Credo der HTML-5-Entwickler, dass diese Features schon jetzt implementiert und eingesetzt werden sollen. Soll man etwa invalides HTML 4 mit HTML-5-Techniken schreiben? Oder gehts nur darum, nicht in den Quirksmode zu kommen? Soweit ich weiß triggert der HTML-5-Doctype in allen verbreiteten Browsern den standardkonformen Modus.
Mathias
Hallo,
Ich dachte, es ist das Credo der HTML-5-Entwickler, dass diese Features schon jetzt implementiert und eingesetzt werden sollen.
Ja, das stimmt.
Soll man etwa invalides HTML 4 mit HTML-5-Techniken schreiben? Oder gehts nur darum, nicht in den Quirksmode zu kommen?
Beide male ja. Von der Verwendung von <!doctype html> wird aber noch abgeraten, weil man verhindern möchte, dass sich HTML 5 damit in eine Sackgasse bewegt.
D.h. die Benutzer schreiben HTML, wie es jetzt verarbeitet wird und sind dann verärgert, wenn es später nicht mehr funktioniert.
HTML 5 verändert ja durchaus einige Teile des Parsers im Vergleich zur aktuellen Verarbeitung usw. Drum soll man ja nur verwenden, was sschon als stabil gilt.
Soweit ich weiß triggert der HTML-5-Doctype in allen verbreiteten Browsern den standardkonformen Modus.
Da hast du Recht.
Gruß.
HTML 5 verändert ja durchaus einige Teile des Parsers im Vergleich zur aktuellen Verarbeitung usw.
Sorry, aber wenn das das einzige Argument ist: Häh?
Klar, ich kann natürlich nicht erwarten, dass ein HTML-5-Dokument derzeit als HTML 5 verarbeitet wird - sondern es wird halt als unspezifizierte Tag-Soup behandelt. Halt genau das, was mit einem HTML-4-Dokument passiert, wenn ich HTML-5-Features darin einbaue - ich kann noch nicht auf die vollständige Plattform HTML 5 zählen, nur auf diese separaten Features, und zwar in seiner HTML-4-Variante.
D.h. die Benutzer schreiben HTML, wie es jetzt verarbeitet wird und sind dann verärgert, wenn es später nicht mehr funktioniert.
Ja, es gibt natürlich noch keinen wirklich HTML-5-fähigen Browser. Insofern ist dieses Szenario möglich.
Anders herum ist es aber noch dämlicher: Man zieht HTML-5-Features in eine andere Plattform, sodass jeder sie außerhalb ihres Kontexts gebraucht. Es ist genauso wahrscheinlich, dass später bei der Migration von HTML 4 mit HTML-5-Features auf wirkliches HTML 5 viel schiefgeht, weil sich die Leute an HTML 5 in HTML 4 gewöhnt haben und irreführen ließen.
Insofern halte ich die Festlegung für reichlich willkürlich. Man kann dieses Problem damit nicht umgehen. Es kommt immer auf den jeweiligen Autor an, der sich der Problematik in beiden Fällen bewusst sein muss.
Mathias
Hallo,
Insofern halte ich die Festlegung für reichlich willkürlich. Man kann dieses Problem damit nicht umgehen. Es kommt immer auf den jeweiligen Autor an, der sich der Problematik in beiden Fällen bewusst sein muss.
Ich muss mir endlich angewöhnen, endlich alle meine Quellen zu speichern :-(
Im Grunde stimme ich dir da natürlich zu.
Hmm, dieses HTML ist schon ein Sonderfall, nicht?
gruß
@@Daniel unreg:
jetzt möchte ich z.b. das
video-tag benutzen.
die frage ist nur welchen Doctype soll ich benutzen?Das spielt keine* Rolle. Es ist aber zu empfehlen, dass du den verwendest, den du auch sonst verwenden würdest, also HTML 4.01 bzw. XHTML 1.0 als Strict- oder Transitional-Variante.
Also HTML 4.01 bzw. XHTML 1.0 über etwas schreiben, was überhaupt kein HTML 4.01 bzw. XHTML 1.0 ist??
Diesen Etikettenschwindel halte ich für – ähm – bedenklich.
Live long and prosper,
Gunnar
Hallo,
Also HTML 4.01 bzw. XHTML 1.0 über etwas schreiben, was überhaupt kein HTML 4.01 bzw. XHTML 1.0 ist??
Diesen Etikettenschwindel halte ich für – ähm – bedenklich.
Sicher, es ist nicht die Ideallösung. Aber der Großteil des Webs packt diese Ettiketten auf Dokumente, die dies eben nicht sind.
Davon abgesehen geht es hier nicht wirklich um Etikettenschwindel, die Browser kennen keine HTML-Versionen, deshalb ist für sie der Doctype - in dieser Hinsicht - irrelevant. Relevant ist er höchstens für die Validierung.
Gruß
@@Daniel unreg:
Davon abgesehen geht es hier nicht wirklich um Etikettenschwindel, die Browser kennen keine HTML-Versionen, deshalb ist für sie der Doctype - in dieser Hinsicht - irrelevant. Relevant ist er höchstens für die Validierung.
Eben. Was nicht als "foo" validiert, sollte nicht das Etikett "foo" bekommen. Dann schon lieber gar keins.
Dummerweise wird das Etikett ja aber zum Unschalten der Renderungsmodi missbraucht.
Aber wenn’s denn nur um diesen Schalter geht, dann kann man doch auch einfach <!DOCTYPE html> drüberschreiben. (Das sagt ja rein gar nichts aus; nicht, dass es sich um HTML 5 handelt.) Wo soll damit das Problem sein?
Live long and prosper,
Gunnar
Hallo,
Eben. Was nicht als "foo" validiert, sollte nicht das Etikett "foo" bekommen. Dann schon lieber gar keins.
Aber wenn’s denn nur um diesen Schalter geht, dann kann man doch auch einfach
<!DOCTYPE html>drüberschreiben. (Das sagt ja rein gar nichts aus; nicht, dass es sich um HTML 5 handelt.) Wo soll damit das Problem sein?
Gerade deswegen soll man <!DOCTYPE html> nicht verwenden. Man will verhindern, dass dies als HTML 5 erkannt wird, sondern als HTML. Wäre ersteres der Fall könnten z. B. Mozilla und Microsoft mal wieder nen neuen Modus rausschleudern.
Gruß