W3C Richtlinien

[jUnit]

Schönen guten Abend euch allen,

ich habe in den letzten Tagen mit einem Kunden von mir Diskutiert, dass man sich an die W3C Richtlinien halten sollte bzw. dass man danach auch programmiert. Nun habe ich heute von diesem besagten Kunden auch eine Mail bekommen mit folgender Nachricht:

Ohne die bisherigen Verdienste des W3C in Frage stellen oder schmälern zu wollen, ist hier doch einmal eine Klarstellung mehr als angebracht:

Das sog. W3C ist lediglich ein Industriekonsortium und vefügt weltweit über weniger als 400 Mitglieder. Zum Vergleich: Das ist ungefähr halb so viel wie die Anzahl der IT- und Telekommunikationsunternehmen im gemütlichen Bundesdorf Bonn.

Das Konsortium ist keine international anerkannte Organisation und verfügt über keine „greifbare“ Rechtsform. Jeder „Kegelschwestern e. V.“ hat größere juristische Relevanz als das W3C.  Nicht einmal vertragsfähig ist das Konsortium: Es gibt keine Konsortialverträge, sondern lediglich Mitgliedschaften, Inhaber der Domain „w3c.de“ ist ein Fraunhofer-Institut. Die Konsorten übernehmen durch ihre „Mitgliedschaft“ keine Haftung oder rechtlich bindende Verpflichtungen. Insofern ist eigentlich schon die Verwendung des Begriffs „Konsortium“ irreführend. Korrekter wäre eine unverbindliche Bezeichnung wie Gremium, Arbeitskreis oder Interessengemeinschaft.

Dem zu Folge hat das W3C weder die Berechtigung noch die Möglichkeit, verbindliche Normen aufzustellen und veröffentlicht korrekter Weise auch lediglich Empfehlungen. Diese Empfehlungen, auch wenn sie von selbsternannten W3C-Priestern und deren unwissenden Jüngern als sakrosankt betrachtet und dargestellt werden, verfügen über weniger Verbindlichkeit als die 130 km/h-Richtgeschwindigkeit auf deutschen Autobahnen. Ausschließlich aus der Befolgung dieser Empfehlungen auf die Zukunftssicherheit eigener Arbeiten zu schließen, erscheint vor diesem Hintergrund zu mindest naiv.

Internetdateien ausschließlich auf „Validität“ (= Wirksamkeit, lat. validus = wirksam) entsprechend den als „Standards“ propagierten W3C-Empfehlungen auszurichten, kann im Einzelfall durchaus zu sinnlosen Einschränkungen der tatsächlich verfügbaren Möglichkeiten führen und verursacht regelmäßig, z. B. durch nach den W3C-Empfehlungen „erforderliche“ Zeilenschaltungen und Einrückungen in CSS und HTML, unnötig aufgeblähte und häufig unübersichtliche Dateien. Die häufig zu findende Behauptung, „Validität“ sei ausschließlich bei Übereinstimmung mit den W3C-Standards gegeben, kann somit als sachlich unzutreffend betrachtet werden.

Zusammenfassend lässt sich also feststellen, dass Darstellungen der W3C-Empfehlungen als verbindliche und einzig gültige Normen und Vorschriften für die Erstellung von Dateien lediglich als persönliche Meinungsäußerungen und nicht als Tatsachen zu betrachten sind. Es kann also durchaus darauf verzichtet werden, dem W3C-„Validator“ die Bedeutung eines Bundesverfassungsgerichts beizumessen.

Dessen ungeachtet bleibt es selbstverständlich jedem unbenommen, sich, wenn er es will,  für seine eigenen Internetprojekte ausschließlich an den gerade mal aktuellen Empfehlungen des W3C zu orientieren. Aus solcher Selbstbeschränkung allerdings den Anspruch der Professionalität abzuleiten, erscheint doch eher fragwürdig.

Nun meine Frage mal an euch. Haltet Ihr euch an die W3C Richtlinien ? Oder was sagt Ihr zu diesem Text?

Wünsch euch noch einen schönen Abend!

Mit freundlichen Grüßen,
jUnit

[wahsaga]

hi,

Oder was sagt Ihr zu diesem Text?

*ATOMROFL* (o.s.ä.)

Lange nicht mehr so einen schönen Haufen Unfug mit so viel Halb- oder Unwissen garniert gelesen.

Das Validität lediglich die Einhaltung eines definierten Standards bedeutet, nicht mehr und nicht weniger, weiß jeder, der sich ein wenig mit der Materie auskennt.

Die ganzen "Argumente" sind aber vollkommen an den Haaren herbeigezogen.

Das sog. W3C ist lediglich ein Industriekonsortium und vefügt weltweit über weniger als 400 Mitglieder.

Aha - als ob das was aussagen würde.

Wie viele Mitglieder haben eigentlich Bundestag und Bundesrat, dass die sich anmaßen, für uns Gesetze zu machen ...?

Das Konsortium ist keine international anerkannte Organisation

Gibt es Belege zu dieser These?
Die möchte er doch bitte mal darlegen - allerdings erst nachdem er definiert hat, wann eine Organisation "international anerkannt" ist.

und verfügt über keine „greifbare“ Rechtsform.

So ein Quark.

Jeder „Kegelschwestern e. V.“ hat größere juristische Relevanz als das W3C.

Dieser Mensch hat also offenbar noch nicht einmal verstanden, dass es hier überhaupt nicht um juristische Relevanz geht.

Ausschließlich aus der Befolgung dieser Empfehlungen auf die Zukunftssicherheit eigener Arbeiten zu schließen, erscheint vor diesem Hintergrund zu mindest naiv.

Absolut naiv ist das Gequatsche dieses Menschen, der sich einen verdammt großen Gefallen getan hätte, hätte er nur auf Dieter Nuhr gehört.

[...] verursacht regelmäßig, z. B. durch nach den W3C-Empfehlungen „erforderliche“ Zeilenschaltungen und Einrückungen in CSS und HTML, unnötig aufgeblähte und häufig unübersichtliche Dateien

Wo sind denn bitte "Zeilenschaltungen" und "Einrückungen" "erforderlich"?

Die häufig zu findende Behauptung, „Validität“ sei ausschließlich bei Übereinstimmung mit den W3C-Standards gegeben, kann somit als sachlich unzutreffend betrachtet werden.

Insbesondere, dass er hier mit "somit" auf seinen vorher geäußerten Unfug Bezug nimmt, der eigentlich so gut wie überhaupt nichts anderes aussagt, als dass dieser Mensch sich mit den syntaktischen Konventionen von HTML und CSS offenbar nicht anfreunden kann, oder nicht in der Lage ist, ihnen entsprechende Dokumente zu erstellen, ist stark belustigend.

Zusammenfassend lässt sich also feststellen, dass Darstellungen der W3C-Empfehlungen als verbindliche und einzig gültige Normen und Vorschriften für die Erstellung von Dateien lediglich als persönliche Meinungsäußerungen und nicht als Tatsachen zu betrachten sind.

Die großen Browserhersteller sind Mitglieder des W3C, und entwicklen ihre Browser so, dass sie möglichst diesen Normen folgen sollten.
Warum das "Meinungsäußerungen" sein sollten, ist mir unklar. Könntest du so gut sein, und beim Verfasser dieser Büttenrede mal nachfragen?

Es kann also durchaus darauf verzichtet werden, dem W3C-„Validator“ die Bedeutung eines Bundesverfassungsgerichts beizumessen.

Dieser Mensch hat wirklich überhaupt nicht verstanden, wozu Standards gut sind.

HTML gibt es ja übrigens m.W. auch in einer von der DIN genormten Variante - vielleicht kann sich dieser Spießer mit der besser anfreunden?

Dessen ungeachtet bleibt es selbstverständlich jedem unbenommen, sich, wenn er es will,  für seine eigenen Internetprojekte ausschließlich an den gerade mal aktuellen Empfehlungen des W3C zu orientieren. Aus solcher Selbstbeschränkung allerdings den Anspruch der Professionalität abzuleiten, erscheint doch eher fragwürdig.

Sich nicht an die Standards zu halten, finde ich alles andere als professionell.

Ich würde zu gerne das dumme Gesicht dieses Menschen sehen, wenn der mal mit XML arbeitet - auch nur dumme Normen und zu seiner Gängelung entworfene Vorschriften ... nur warum bloss will das XML-verarbeitende Programm sein Gebastel nicht akzeptieren?

gruß,
wahsaga

[Swen Wacker]

Moin,

HTML gibt es ja übrigens m.W. auch in einer von der DIN genormten Variante

ISO-Norm (aber das kommt ja aufs gleiche heraus): ISO/IEC 15445.
In dem Zusammenhang fallen mir noch ein paar ISO/IEC-Normen ein, die uns ab und an im Web begegnen begegnen: SGML ISO/IEC 8879; Javascript (ECMAScript) ISO/IEC 16262; SQL ISO/IEC 9075; UCS/Unicode: ISO/IEC 10646

Ich würde zu gerne das dumme Gesicht dieses Menschen sehen, wenn der mal mit XML arbeitet

Dabeo fällt kann mir gerade ein: Warum ist XML (noch) nicht als ISO-Norm definiert. Wegen SGML?

Viele Grüße

Swen

[Jeena Paradies]

Hallo,

Ich finde der Typ hat recht. Wir schreiben ja Seiten für _Menschen_ und nicht für irgendwelche Maschinen wie Validatoren. Ich schreibe zwar zum großen Teil valide Seiten, habe aber überhaupt keine skrupel etwas invalides einzubauen, wenn es denn die Bedienung verbessert, oder mir einen Haufen Arbeit spart.

Grüße
Jeena Paradies

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Ich finde der Typ hat recht. Wir schreiben ja Seiten für _Menschen_ und nicht für irgendwelche Maschinen wie Validatoren.

Richtig, wir schreiben Seiten für Menschen, also müssen wir uns darum kümmern wie wir Informationen so aufbereiten, dass Menschen daraus einen Nutzen ziehen können, dass sie leicht und gerne gelesen werden etc., alles das nennt man neudeutsch "Usability" (solltest du schonmal gehört haben, du kennst doch Jakob Nielsen IIRC).

Wir reden hier allerdings von HTML, also von der Verpackung der Inhalte und die sollte gewissen Normen folgen.

Wo wie wir Pakete ordentlich zuschnüren, damit nichts rausfällt, Bücher von vorne nach hinten, von links nach rechts und von oben nach unten gelesen werden so müssen wir uns auch bei HTML auf einen kleinsten gemeinsamen Nenner einigen, und der ist die HTML-DTD vom W3C.

Ich schreibe zwar zum großen Teil valide Seiten, habe aber überhaupt keine skrupel etwas invalides einzubauen, wenn es denn die Bedienung verbessert, oder mir einen Haufen Arbeit spart.

Was baust du denn da ein?

Gruß
Alexander Brock

[Jeena Paradies]

Hallo,

Wo wie wir Pakete ordentlich zuschnüren, damit nichts rausfällt, Bücher von vorne nach hinten, von links nach rechts und von oben nach unten gelesen werden so müssen wir uns auch bei HTML auf einen kleinsten gemeinsamen Nenner einigen, und der ist die HTML-DTD vom W3C.

Jo schon klar nur ganz so dogmatisch sehe ich das ganze nicht und Validität ist ja mal eine selten dumme größe für Qualität von Markup, findest du nicht?

Ich schreibe zwar zum großen Teil valide Seiten, habe aber überhaupt keine skrupel etwas invalides einzubauen, wenn es denn die Bedienung verbessert, oder mir einen Haufen Arbeit spart.

Keine Ahnung ;-), ne bei HTML fällt es mir schon schweer was zu finden, aber bei CSS fängt es doch schon mit den ganzen -moz-border-radius und opacity und so weiter an bis hin zu Browserhacks.

Grüße
Jeena Paradies

[Struppi]

» Ich schreibe zwar zum großen Teil valide Seiten, habe aber überhaupt keine skrupel etwas invalides einzubauen, wenn es denn die Bedienung verbessert, oder mir einen Haufen Arbeit spart.

Keine Ahnung ;-), ne bei HTML fällt es mir schon schweer was zu finden, aber bei CSS fängt es doch schon mit den ganzen -moz-border-radius und opacity und so weiter an bis hin zu Browserhacks.

border radius und opacity verbessern die Bedienung von Internetseiten?

Oder geht es nur um optischen "Zucker" und da halte ich validität auch nicht für sonderlich wichtig.

Struppi.

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Jo schon klar nur ganz so dogmatisch sehe ich das ganze nicht und Validität ist ja mal eine selten dumme größe für Qualität von Markup, findest du nicht?

Es ist eine notwendige Vorraussetzung, ob die Auszeichnung semantisch ist wird allerdings nicht festgestellt, wie auch. Wären von Anfang an SGML-Parser verwendet worden würden wir diese Diskussion nicht führen.

Keine Ahnung ;-), ne bei HTML fällt es mir schon schweer was zu finden, aber bei CSS fängt es doch schon mit den ganzen -moz-border-radius und opacity und so weiter an bis hin zu Browserhacks.

Gibts da nicht extra Regeln dafür, wie man Eigenschaften nennen soll wenn man welche erfindet? AFAIK ist -moz-border-radius sehr wohl valides CSS.

Gruß
Alexander Brock

[Jeena Paradies]

Hallo,

Gibts da nicht extra Regeln dafür, wie man Eigenschaften nennen soll wenn man welche erfindet? AFAIK ist -moz-border-radius sehr wohl valides CSS.

Erst ab CSS 3 so weit ich mich erinnere.

Grüße
Jeena Paradies

[Auge]

Hallo

Gibts da nicht extra Regeln dafür, wie man Eigenschaften nennen soll wenn man welche erfindet? AFAIK ist -moz-border-radius sehr wohl valides CSS.
Erst ab CSS 3 so weit ich mich erinnere.

Kann man auch vorher schon machen. Deshalb gibt es ja den (regelkonformen) Präfix '-xxx-'. Opera verwendet das ja auch: '-o-'. 'border-radius' ansich ist ja schon CSS3.

Tschö, Auge

[Cybaer]

Hi,

Kann man auch vorher schon machen. Deshalb gibt es ja den (regelkonformen) Präfix '-xxx-'.

Die Frage war: Seit wann ist dieser Präfix erlaubt?

Die 2. Frage ist: Was ist mit älteren Browsern? Alle neuen Elemente sind für ältere Browser "invalide", ebenso wie es zukünftige Standards für heutige Browser sind. Ein "DOCTYPE" für CSS habe ich noch nicht gesehen.

Insofern gilt: Sind wir nicht alle ein wenig invalide ... irgendwann? ;->

Gruß, Cy-"Gichtgriffel in spe"-baer

[Christian Seiler]

Hallo Cybaer,

Kann man auch vorher schon machen. Deshalb gibt es ja den (regelkonformen) Präfix '-xxx-'.

Die Frage war: Seit wann ist dieser Präfix erlaubt?

Die 2. Frage ist: Was ist mit älteren Browsern? Alle neuen Elemente sind für ältere Browser "invalide", ebenso wie es zukünftige Standards für heutige Browser sind. Ein "DOCTYPE" für CSS habe ich noch nicht gesehen.

Insofern gilt: Sind wir nicht alle ein wenig invalide ... irgendwann? ;->

Um das jetzt ein für allemal klar zu stellen:

a { foo: bar; }

Das da ist ein CSS-Dokument, das dem CSS-Standard in gewisser Hinsicht entspricht. Klar, der CSS-Validator wird bei diesem Dokument meckern, der ist aber auch als Hilfsmittel für den Autor gedacht und *kein* Werkzeug, was einem sagt, ob ein Dokument - sagen wir mal - "interpretierbar" ist. Im CSS2-Standard (in CSS 2.1 steht's meines Wissens genau so drin), steht:

| However, user agents must observe the rules for handling parsing errors.

Das führt einen dann auf http://www.w3.org/TR/CSS2/syndata.html#parsing-errors

Das heißt: Das CSS-Dokument ist nicht zwangsläufig "valide" im Sinne "befolgt die Standards" - allerdings schreibt der Standard vor, wie ein Browser das Dokument zu interpretieren hat, insofern würde ich durchaus von einer gewissen "Validität" sprechen, da der Standard vorschreibt, wie die Browser so ein Dokument zu interpretieren haben.

Oder anders gesagt: Ich habe kein Problem, -moz-border-radius / opacity / filter:alpha zu verwenden - und ich würde mein Dokument dennoch in gewisser Hinsicht als "valide" bezeichnen (vielleicht passt hier der XML-Begriff "wohlgeformt" besser, auch wenn es den im CSS-Kontext nicht gibt).

Oder nochmal ein anderer Ansatz: Wenn der Autor des ursprünglichen Textes bei CSS eine sehr pedantische Interpretation von »valide« zu Grunde legt, dann muss ich ihm insofern Recht geben, als dass man sich dadurch einschränkt. Allerdings ist führt diese pedantische Interpretation in diesem Zusammenhang zu nichts, denn niemand wollte dem Autor des urpsrünglichen Textes vorschlagen, sich wirklich nur auf CSS2 zu beschränken.

Und zu HTML: Ich verstehe wirklich nicht, warum es so kompliziert ist, valides HTML zu schreiben. Valides HTML heißt ja nicht, dass man CSS-Layout oder so umsetzt, es gibt wunderbar valide Seiten, die HTML-Tabellen zu Layoutzwecken derart ineinander verschachteln, dass es einen nur so schüttelt. Bei HTML-Validität kann man die Ausnahmen vmtl. an einer Hand abzählen, bei denen Validität eine Einschränkung bedeutet (mir fallen aktuell nur Framesets ohne Border ein, wenn man das in allen Browsern hinkriegen will - aber dort wäre nur das Frameset ungültig, die einzelnen Dateien nicht).

Viele Grüße,
Christian

[Cybaer]

Hi,

Insofern gilt: Sind wir nicht alle ein wenig invalide ... irgendwann? ;->
Um das jetzt ein für allemal klar zu stellen:

Du sprichst mir aus dem Herzen (und dem Verstand ;))! Meine Rede!

Denn analog zu deinen CSS-Ausführungen ...

a { foo: bar; }
Das heißt: Das CSS-Dokument ist nicht zwangsläufig "valide" im Sinne "befolgt die Standards" - allerdings schreibt der Standard vor, wie ein Browser das Dokument zu interpretieren hat, insofern würde ich durchaus von einer gewissen "Validität" sprechen, da der Standard vorschreibt, wie die Browser so ein Dokument zu interpretieren haben.

... gilt das gleiche ja für HTML. Der Standard schreibt vor: Unbekannte Tags und Attribute soll der Browser ignorieren.

Und analog spreche ich bei HTML ebenfalls von ...

Oder anders gesagt: Ich habe kein Problem, -moz-border-radius / opacity / filter:alpha zu verwenden - und ich würde mein Dokument dennoch in gewisser Hinsicht als "valide" bezeichnen (vielleicht passt hier der XML-Begriff "wohlgeformt" besser, auch wenn es den im CSS-Kontext nicht gibt).

... aus dem XML-Kontext entlehnter "Wohlgeformtheit".

Das alles ist *mannigfaltig* im Archiv sowie auf meiner (invaliden aber wohlgeformten) Website nachzulesen (hier im Forum ebenfalls ab und an mal zitiert, bzw. den URL gepostet), denn *dieser* Thread ist ja beileibe nicht der erste, der sich mit diesem Thema auseinandersetzt - und deinen "abschließenden Worten" zum Trotz (oder zum Hohn?), bestimmt auch nicht der letzte ... :-/

Und zu HTML: Ich verstehe wirklich nicht, warum es so kompliziert ist, valides HTML zu schreiben.

Ja, das verstehe ich auch nicht. Und in Anbetracht deines (für mich halt ebenfalls absolut logischen) Standpunkts, verstehe ich auch noch viel weniger, warum manche die Validität als Götzen so hochhalten, anstatt einfach zu sagen: Validität ist schön, aber kein Muß.

Denn dummerweise gilt halt: Ein bißchen valide gibt es ebensowenig, wie ein bißchen schwanger. Aber wir sind hier doch nicht im HTML-Kindergarten, der Validität und Wohlgeformtheit nicht auseinanderhalten kann?!

Ich kann es jedenfalls, und würde erwarten, daß das einige andere hier ebenfalls können - sie müßten nur wollen ...

Gruß, Cybaer

[Christian Seiler]

Hallo,

Denn analog zu deinen CSS-Ausführungen ...
[...]
... gilt das gleiche ja für HTML. Der Standard schreibt vor: Unbekannte Tags und Attribute soll der Browser ignorieren.

Nein. Der HTML4-Standard empfielt dies, schreibt es aber explizit *nicht* vor. Ein Browser, der bei einem nicht validen HTML4-Dokument abbricht, entspricht in diesem Punkt 100%ig der Spezifikation. Einer, der weitermacht, genauso. Bei XHTML wird dies dagegen zwar vorgeschrieben, wenn allerdings ein validierender Prozessor verwendet wird, dann schreibt der XML-Standard vor, dass der Prozessor meckern soll (was dann vmtl. im Endeffekt wohl nur so zu vereinbaren wäre: Warnung ausgeben, weitermachen). Ich kenne bei XHTML allerdings keinen Browser, der das umsetzt; alle mir bekannten brechen mit einer Fehlermeldung ab. Aber auch eine Warnung wäre nicht wirklich toll für den Besucher, oder? Deswegen würde ich mich bei HTML *nicht* auf den gleichen Standpunkt stellen, wie bei CSS.

Und zu HTML: Ich verstehe wirklich nicht, warum es so kompliziert ist, valides HTML zu schreiben.

Ja, das verstehe ich auch nicht. Und in Anbetracht deines (für mich halt ebenfalls absolut logischen) Standpunkts, verstehe ich auch noch viel weniger, warum manche die Validität als Götzen so hochhalten, anstatt einfach zu sagen: Validität ist schön, aber kein Muß.

Betrachte es mal von einem anderen Standpunkt: Wenn man weiß, was man tut, kann man auch ungültige Dokumente schreiben. Das Problem ist nur, dass man enorm viel Wissen braucht, um zu wissen, was man tut, deswegen halte ich bei HTML die Empfehlung, immer valide Seiten zu schreiben, grundsätzlich erst einmal für vollkommen in Ordnung - dass es keine Regel ohne Ausnahme gibt, sollte ohnehin jedem klar sein.

Denn dummerweise gilt halt: Ein bißchen valide gibt es ebensowenig, wie ein bißchen schwanger. Aber wir sind hier doch nicht im HTML-Kindergarten, der Validität und Wohlgeformtheit nicht auseinanderhalten kann?!

Ich bin mir ziemlich sicher, dass jeder hier, der sagt, Seiten sollten valide sein, keine Skrupel hätte, ungültige Seiten zu schreiben, wenn es denn wirklich mal notwendig sein sollte. Natürlich sind alle Pauschalisierungen falsch und dumm, aber diese Pauschalisierung (man sollte valide arbeiten) ist bei HTML in wirklich fast allen Fällen so derart zutreffend, dass es in meinen Augen viel zu sehr dazu verleitet, sich zu sehr aus dem Fenster der Validität zu lehnen, wenn man diese Pauschalisierung jedes mal relativiert - die Relativierung ist nämlich im Vergleich zu dem, worum es geht, so winzig, dass sie wirklich nur in Ausnahmefällen eine Rolle spielt.

Viele Grüße,
Christian

[Cybaer]

Hi,

Nein. Der HTML4-Standard empfielt dies, schreibt es aber explizit *nicht* vor. Ein Browser, der bei einem nicht validen HTML4-Dokument abbricht, entspricht in diesem Punkt 100%ig der Spezifikation.

Kannst Du dafür eine Quelle aus dem Ärmel schütteln?

Davon abgesehen: Ich sage keinem Browser, es wäre ein HTML-4-Dokument, wenn es kein HTML-4-Dokument ist. :)

Deswegen würde ich mich bei HTML *nicht* auf den gleichen Standpunkt stellen, wie bei CSS.

Ich kenne keine Stelle in der HTML-Spezifikation (nicht in der 4er, aber, das ist auf jeden Fall korrekt, nicht von vorhergehenden Spezifikationen - die nach wie vor gelten - und weiter gelten werden), wo erwähnt ist, daß Browser die Verabreitung abrrechen können. Nur eben, daß sie das ignorieren sollen (nicht müssen).

dass es keine Regel ohne Ausnahme gibt, sollte ohnehin jedem klar sein.

Da wäre ich mir nicht so sicher.

Schließlich ist es in SGML beileibe nicht "klar", daß es auch Dokumente geben kann/könnte, die nicht valide sind. Ganz im Gegenteil: Es gibt hier keinen Regelverstoß - Punkt! HTML wurde hier bewußt und gegen die Herkunft lockerer definiert.

Ich sehe diese Lamoranz also nicht als selbstverständlich - und sehe diese Selbstverstänlichkeit auch nicht in hiesigen Diskussionen ...

Ich bin mir ziemlich sicher, dass jeder hier, der sagt, Seiten sollten valide sein, keine Skrupel hätte, ungültige Seiten zu schreiben,

Ich habe Skrupel, ungültige Seiten zu schreiben.

Meine Seiten *sind* gültig - so oder so.

Sie sind nur nicht gültig gemäß dem, was das W3C fordert. Zu *meiner* DTD sind die Dokumente valide. Ohne Not würde ich nicht "lügen", und eine DTD angeben, von der ich weiß, daß sie gar nicht paßt. Eher würde ich einen Workaround für das dämliche DOCTYPE-Sniffing machen.

Aber jedem das seine ...

Natürlich sind alle Pauschalisierungen falsch und dumm, aber diese Pauschalisierung (man sollte valide arbeiten) ist bei HTML in wirklich fast allen Fällen so derart zutreffend, dass es in meinen Augen viel zu sehr dazu verleitet, sich zu sehr aus dem Fenster der Validität zu lehnen, wenn man diese Pauschalisierung jedes mal relativiert - die Relativierung ist nämlich im Vergleich zu dem, worum es geht, so winzig, dass sie wirklich nur in Ausnahmefällen eine Rolle spielt.

Spätestens wenn die Frage aufkommt, "warum sind denn die allermeisten Seiten im Web nicht valide", sollte man IMHO nicht die kleine Mühe scheuen, zu erklären, daß es dafür unterschiedliche Ursachen gibt - und diese benennen.

Gruß, Cybaer

[Swen Wacker]

Moin,

Nein. Der HTML4-Standard empfielt dies, schreibt es aber explizit *nicht* vor. Ein Browser, der bei einem nicht validen HTML4-Dokument abbricht, entspricht in diesem Punkt 100%ig der Spezifikation.

Kannst Du dafür eine Quelle aus dem Ärmel schütteln?

Zu Satz 1: http://edition-w3.de/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.1
Zu Satz 2:
Da die Spec nicht vorschreibt, wie ein Browser (Benutzerprogramm) sich verhalten soll, kann das Verhalten eines Browsers in einem solchen Fall nicht der Spec ent- oder widersprechen, finde ich.

Spätestens wenn die Frage aufkommt, "warum sind denn die allermeisten Seiten im Web nicht valide", sollte man IMHO nicht die kleine Mühe scheuen, zu erklären, daß es dafür unterschiedliche Ursachen gibt - und diese benennen.

Mir fallen als Gründe ein:

• Faulheit
• Unwissenheit
• Ignoranz
• Überheblichkeit

Das sollte 99,9% der Gründe abdecken, aus denen HTML-Dokumente nicht valide sind.

Viele Grüße

Swen Wacker

[Cybaer]

Hi,

Da die Spec nicht vorschreibt, wie ein Browser (Benutzerprogramm) sich verhalten soll, kann das Verhalten eines Browsers in einem solchen Fall nicht der Spec ent- oder widersprechen, finde ich.

Ich werte das "sollte" so, daß der Browser auch wirklich so reagieren sollte ;) - was ja auch alle HTML-Browser tun.

Wobei sich nach wie vor die Frage stellt: Warum sollte sich der Browser nur nach W3C-DTDs richten? Ich kann ihm auch andere DTDs vorsetzen (faktisch haben ja alle Browser NON-W3C-DTDs).

Das sollte 99,9% der Gründe abdecken, aus denen HTML-Dokumente nicht valide sind.

Und 100% Phantasielosigkeit beim Erstellen von "Gründe"-Listen nicht zu vergessen. *SCNR* ;->

Gruß, Cybaer

[Swen Wacker]

Moin,

Wobei sich nach wie vor die Frage stellt: Warum sollte sich der Browser nur nach W3C-DTDs richten?

Angebot und Nachfrage. Das WWW ist ein Markt mit den üblichen Regeln. Standards, Wettbewerbsregeln etc sind auch aus Sicht der Industrie schon immer hilfreich gewesen und nicht per definition böse.

Nur der Quasi-Monopolist (Netscape, Microsoft; siehe meine andere Antwort in diesen Thread von eben) könnte mit genügend Aussicht auf Erfolg auf die Idee kommen, die Standards allein zu bestimmen. Netscape hat das gemacht, MS nicht. Wir könnten jetzt darüber philosophieren, MS diese Chance verschlief oder bewusst nicht nutzte. Ich tippe auf letzteres.
Und für andere DTD besteht - jedenfalls im WWW - halt kein Markt.

Das sollte 99,9% der Gründe abdecken, aus denen HTML-Dokumente nicht valide sind.
Und 100% Phantasielosigkeit beim Erstellen von "Gründe"-Listen nicht zu vergessen. *SCNR* ;->

Wenn ich so eine Vorlage bekomme ;-) ...

Liebe Grüße

Swen Wacker

[Cybaer]

Hi,

Nur der Quasi-Monopolist (Netscape, Microsoft; siehe meine andere Antwort in diesen Thread von eben) könnte mit genügend Aussicht auf Erfolg auf die Idee kommen, die Standards allein zu bestimmen.

Und wir verdanken dieser Denkungsart einen rasanten Fortschritt der Web-Technologie ... :)

Und für andere DTD besteht - jedenfalls im WWW - halt kein Markt.

Eben - weil HTML halt so ausgelegt ist.

Wenn ich so eine Vorlage bekomme ;-) ...

:)

Gruß, Cybaer

[wahsaga]

hi,

Ich finde der Typ hat recht.

Kann ich nicht finden.

[...] habe aber überhaupt keine skrupel etwas invalides einzubauen, wenn es denn die Bedienung verbessert,

Da kann ich mir zwar gerade nur schwerlich ein anschauliches Beispiel für vorstellen - aber das wäre ja auch was anderes, als das worauf der Typ hinauswill. Er stellt nämlich Validität als etwas vollkommen überflüssiges dar - da kann man nur vermuten, dass er schlicht zu $&%! ist, valide _und_ "funktionierende" Dokumente zu erstellen.

oder mir einen Haufen Arbeit spart.

Das wiederum ist nahe an der Faulheit :-)

gruß,
wahsaga

[Jeena Paradies]

Hallo,

Da kann ich mir zwar gerade nur schwerlich ein anschauliches Beispiel für vorstellen

Ja ich auch, aber wenn es was gäbe, hätte ich keine Skrupel ;-)

• aber das wäre ja auch was anderes, als das worauf der Typ hinauswill. Er stellt nämlich Validität als etwas vollkommen überflüssiges dar

Jetzt nach nochmaligem Lesen seines Textes muss ich dir Recht geben, beim ersten drüberfliegen kam mir das nicht so vor und ich vermutete mehr "Fleisch" dahinter.

Das wiederum ist nahe an der Faulheit :-)

Ach komm das ist doch nur Menschlich ;-)

Grüße
Jeena Paradies

[Der Martin]

Hallo,

Das sog. W3C ist lediglich ein Industriekonsortium und vefügt weltweit über weniger als 400 Mitglieder. Zum Vergleich: Das ist ungefähr halb so viel wie die Anzahl der IT- und Telekommunikationsunternehmen im gemütlichen Bundesdorf Bonn.

dass unter diesen 400 Mitgliedern die finanzstärksten Unternehmen, sozusagen die creme de la creme der IT-Branche vertreten sind, interessiert deinen Kunden dabei wohl nicht.

Dem zu Folge hat das W3C weder die Berechtigung noch die Möglichkeit, verbindliche Normen aufzustellen und veröffentlicht korrekter Weise auch lediglich Empfehlungen.

Richtig. Der VDE hat in Deutschland auch keinerlei rechtliche Relevanz. Aber seine Richtlinien und Regeln werden trotzdem allgemein honoriert und anerkannt. So sehr anerkannt, dass sie zum großen Teil sogar vom DIN (Deutsches Institut für Normung) und teils sogar von der Europäischen Kommission direkt als verbindliche Norm für die EU übernommen werden.

Diese Empfehlungen, auch wenn sie von selbsternannten W3C-Priestern und deren unwissenden Jüngern als sakrosankt betrachtet und dargestellt werden, verfügen über weniger Verbindlichkeit als die 130 km/h-Richtgeschwindigkeit auf deutschen Autobahnen.

Der Rechtsstatus eines "Vereins" sagt ja auch noch lange nichts über seine Sachkompetenz aus.

Ausschließlich aus der Befolgung dieser Empfehlungen auf die Zukunftssicherheit eigener Arbeiten zu schließen, erscheint vor diesem Hintergrund zu mindest naiv.

Diese Empfehlungen, die von führenden IT-Experten der Welt ausgearbeitet und formuliert werden, einfach so für Blödsinn zu erklären, halte ich auch für "zu mindest naiv". Abgesehen davon, dass dein Kunde auffällige Schwächen in der Orthographie zeigt und sich damit schon Punkte verscherzt.

Internetdateien ausschließlich auf „Validität“ (= Wirksamkeit, lat. validus = wirksam)

falsch: validus = gesund, kräftig, im übertragenen Sinn auch: gültig, korrekt.

entsprechend den als „Standards“ propagierten W3C-Empfehlungen auszurichten, kann im Einzelfall durchaus zu sinnlosen Einschränkungen der tatsächlich verfügbaren Möglichkeiten führen

Ja, und zu der unerhörten Chance, dass die so erzeugten Dokumente in einer Mehrheit der Anzeigeprogramme (Browser) sogar reproduzierbare Ergebnisse erzeugen.

durch nach den W3C-Empfehlungen „erforderliche“ Zeilenschaltungen und Einrückungen in CSS und HTML, unnötig aufgeblähte und häufig unübersichtliche Dateien.

Quatsch. Wo haben sie denn den Unsinn her?

Zusammenfassend lässt sich also feststellen, dass Darstellungen der W3C-Empfehlungen als verbindliche und einzig gültige Normen und Vorschriften für die Erstellung von Dateien lediglich als persönliche Meinungsäußerungen und nicht als Tatsachen zu betrachten sind.

Aha. Welche anderen, verbindlicheren Normen haben wir denn dann im Webdesign, die man stattdessen heranziehen könnte?

Es kann also durchaus darauf verzichtet werden, dem W3C-„Validator“ die Bedeutung eines Bundesverfassungsgerichts beizumessen.

Richtig. Aber durchaus die Bedeutung eines "TÜV" oder einer "FSK".

Aus solcher Selbstbeschränkung allerdings den Anspruch der Professionalität abzuleiten, erscheint doch eher fragwürdig.

Aus einer solchen Missachtung des W3C den Anspruch der Professionalität abzuleiten, erscheint _mir_ allerdings sehr fragwürdig.

Nun meine Frage mal an euch. Haltet Ihr euch an die W3C Richtlinien ?

Soweit sie mir bekannt sind, ja.

Oder was sagt Ihr zu diesem Text?

Selten so gelacht.

So long,
 Martin

[Gunnar Bittersmann]

Hello out there!

Aha. Welche anderen, verbindlicheren Normen haben wir denn dann im Webdesign, die man stattdessen heranziehen könnte?

BITV, ISO 9241-10. Aber natürlich nicht „stattdessen“.

Hat der Typ einen Schimmer Ahnung, wie’s im Internet läuft? IIRC sind sämtliche RFCs keine Gesetze, dennoch tut man gut daran, sich an das in denen Festgeschriebene zu halten. Wie auch an die Empfehlungen des W3C.

See ya up the road,
Gunnar

[Ingo Turski]

Hi,

Aha. Welche anderen, verbindlicheren Normen haben wir denn dann im Webdesign, die man stattdessen heranziehen könnte?

BITV, ISO 9241-10. Aber natürlich nicht „stattdessen“.

oha, da hast Du aber einen Volltreffer gelandet. Vom Bundesministerium für Justiz veröffentlicht:

"Die Anforderungen und Bedingungen dieser Anlage basieren grundsätzlich auf den Zugänglichkeitsrichtlinien für Web-Inhalte 1.0 (Web Content Accessibility Guidelines 1.0) des World Wide Web Consortiums vom 5. Mai 1999."

"Anforderung 3: Markup-Sprachen (insbesondere HTML) und Stylesheets sind entsprechend ihrer Spezifikationen und formalen Definitionen zu verwenden."

freundliche Grüße
Ingo

[Cybaer]

Hi,

"Anforderung 3: Markup-Sprachen (insbesondere HTML) und Stylesheets sind entsprechend ihrer Spezifikationen und formalen Definitionen zu verwenden."

1. BITV ist nicht algemein bindend - nur für Behörden.
2. Es ist nicht gesagt, von *wem* die jeweilige DTD oder die Stylesprache (muß ja nicht CSS sein - ist nur momentan so) spezifiziert werden muß. :)

Gruß, Cybaer

[Ingo Turski]

Hi,

1. BITV ist nicht algemein bindend - nur für Behörden.

es geht ja nur um's Prinzip: Die Bundesregierung hat ein Gesetz herausgebracht, das einen W3C-Standard als verbindlich erklärt.

freundliche Grüße
Ingo

[Cybaer]

Hi,

es geht ja nur um's Prinzip: Die Bundesregierung hat ein Gesetz herausgebracht, das einen W3C-Standard als verbindlich erklärt.

Ist eine Verordnung ein Gesetz? Wenn ja: Warum unterscheidet das Ministerium da sprachlich? Wenn nein: Dann hat sie auch kein "Gesetz herausgebracht".

Ansonsten: Für Behörden ("Die Verordnung gilt für (...) Behörden der Bundesverwaltung") - *nicht* für den privaten wie kommerziellen Rest Deutschlands.

Das wäre ja auch noch schöner, wenn der Arbeitgeber nicht festlegen könnte/würde, wie seine Angestellten zu arbeiten hätten ...

... und welcher Schriftstücke sich diese Arbeitsanweisung als Hilfsmittel bedient, sei jedem Arbeitgeber überlassen ...

... und wenn es der Text von "Wadde hadde dudde da" ist, dann geht das auch in Ordnung. ;->

Gruß, Cybaer

[at]

Hallo.

Ansonsten: Für Behörden ("Die Verordnung gilt für (...) Behörden der Bundesverwaltung") - *nicht* für den privaten wie kommerziellen Rest Deutschlands.

Das wäre ja auch noch schöner, wenn der Arbeitgeber nicht festlegen könnte/würde, wie seine Angestellten zu arbeiten hätten ...

In vielen Bereichen ist genau das gängig und bewährt.
MfG, at

[Cybaer]

Hi,

dass unter diesen 400 Mitgliedern die finanzstärksten Unternehmen, sozusagen die creme de la creme der IT-Branche vertreten sind, interessiert deinen Kunden dabei wohl nicht.

Die sind im "praxisorientierten Think Tank" des Webs, der WHATWG auch vertreten, wo man sichum eine Abstimmungmit em W3C bemüht - mehr aber auch nicht.

Viele Innovationen kamen nicht vom W3C, das nur der Entwicklung hinterher hechelte oder ggf. praxisferne Vorschläge gemacht hat, die nicht implementiert wurden.

Das geht von HTML 2+ als Netscape noch das schnarchende W3C vor sich her trieb, über CSS 2.1 das als Reaktion auf die Realität erfolgte bis hin zu Techniken wie Ajax oder CANVAS ...

Gruß, Cy-"so what?"-baer

[Sam]

Zu den W3C Richtlinien:

Ich halte mich daran, weil diese Standards helfen, eine Seite zu erstellen, welche auf den meisten Browsern ziemlich sauber und identisch dargestellt werden.
Der Quirks- Modus hat auch sein gutes (z.B. das einfache Atribut "height:100%;") aber darauf verzichte ich lieber, wenn ich die wild- verschiedenen Anzeigeresultate in den Browsern ansehen muss.

Zu diesem belustigendem Kundenmail:

Was dieser Oberkluge Bastelprofessor da runterleiert hat mit dem effektiven Nutzen der W3C kaum was zu tun und hat mich ausserdem zu einem Lachanfall gezwungen :D:D.
OK, Verträge helfen, den Standard durchzusetzen, aber die W3C Standards sind imho wirkungsvoll genug, sodass es diese Verträge gar nicht wirklich braucht.
Wer sich wirklich mit den W3C Standards auseindandersetzt, wird viel Zeit damit verbringen, die nicht mehr gültigen Atribute der alten Seiten zu ersetzen, bzw die neue Seite zu gestalten. Dieser Umstand hat mich anfangs auch geärgert, aber schlussendlich hat es sich gelohnt: Ich weiss nun viel mehr über CSS... Wenn ich schon von CSS rede.. aufgeblähter Quellcode, durch Einrückungen usw...?
Wenn man die ganzen "nicht CSS"- Atribute in CSS und dann noch in einem externen File definiert, wird der Quellcode der eigentlichen Webseite wohl kaum aufgebläht, ausserdem kann das Stylesheed gecached werden, was auch wieder weniger Traffic verursacht... und Einrückungen braucht es wohl kaum, damit die Seite funktioniert, obwohl ich diese paar bytes verkraften kann, damit auch der Quelltext (sicher einmal JS) übersichtlich ist. Da verstehe doch einer ein Script mit mehreren hundert Zeilen ohne Einrückungen?! Quelltexte, die aus einer einzigen Zeile bestanden, hab ich afaik auch noch nie gesehen.

MfG Samuel

[Markus]

hui, wer bist denn du?!

[Sam]

hui, wer bist denn du?!

Ein nichtregistrierter Forumbenutzer ;)

PS: Warum teilst du uns nicht deine Meinung zum Thema mit?

[Markus]

hui, wer bist denn du?!

Ein nichtregistrierter Forumbenutzer ;)

PS: Warum teilst du uns nicht deine Meinung zum Thema mit?

ich habe keine dazu.

[Marc Reichelt]

Hallo Sam,

Quelltexte, die aus einer einzigen Zeile bestanden, hab ich afaik auch noch nie gesehen.

Na, dann wolln wir mal!

Ein Beispiel-PHP-Quelltext, der nur eine Zeile braucht:
<?php for($i = 0; $i < 100; $i++) { echo $i; } ?>

HTML-Datei, die nur aus einer Zeile besteht, auf Anfrage. ;-)

Grüße

Marc *SCNR* Reichelt || http://www.marcreichelt.de/

[Vinzenz Mai]

Hallo Marc,

Quelltexte, die aus einer einzigen Zeile bestanden, hab ich afaik auch noch nie gesehen.

Na, dann wolln wir mal!

Ein Beispiel-PHP-Quelltext, der nur eine Zeile braucht:
<?php for($i = 0; $i < 100; $i++) { echo $i; } ?>

mein erstes Programm (soweit ich mich erinnern kann):

10 PRINT "Hallo, Welt!"

Freundliche Grüße

Vinzenz

[Sam]

Hallo Sam,

Quelltexte, die aus einer einzigen Zeile bestanden, hab ich afaik auch noch nie gesehen.

Na, dann wolln wir mal!

Ein Beispiel-PHP-Quelltext, der nur eine Zeile braucht:
<?php for($i = 0; $i < 100; $i++) { echo $i; } ?>

HTML-Datei, die nur aus einer Zeile besteht, auf Anfrage. ;-)

Grüße

Marc *SCNR* Reichelt || http://www.marcreichelt.de/

*lach* ... Ich nehme doch an, dass du weisst, was ich damit sagen wollte :).
Nähmlich: Dass es wahrscheinlich eher selten jemanden gibt, der so codet... die Code (Geschwindigkeits)- Optimierung vor dem Hochladen auf den Webserver hat natürlich einen Quellcode mit wenigen Zeilen zurfolge.
--> Ich habe mich nicht deutlich ausgedrückt ;)

MfG Sam

[Jeena Paradies]

Hallo,

Quelltexte, die aus einer einzigen Zeile bestanden, hab ich afaik auch noch nie gesehen.
Ein Beispiel-PHP-Quelltext, der nur eine Zeile braucht:
<?php for($i = 0; $i < 100; $i++) { echo $i; } ?>

Mensch Marc, wenn du schon mit einer Zeile (und dazu noch Datensparend) angeben möchtest, dann mach das doch bitte gleich richtig:

[iframe:http://dean.edwards.name/IE7/ie7-standard-p.js]

Und lasst euch von etwaigen Umbrüchen eurer Browser nicht täuschen, es _ist_ eine Zeile. Und sie bring den IE fast auf den Stand des Mozilla (wenn auch nicht ganz).

Grüße
Jeena Paradies

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

durch nach den W3C-Empfehlungen „erforderliche“ Zeilenschaltungen und Einrückungen [...], unnötig aufgeblähte [...] Dateien.

Was hat denn der für ein Problem mit den paar Bytes? Wozu gibt es komprimierte Übertragung? Aber solange 6 (!) von 1.91 Millionen Seiten[*] das verwenden sehe ich da irgendwie schwarz für die Netzauslastung.

Gruß
Alexander Brock

[*] Abfrage der ersten 1.91Mio URLs des DMOZ

[Robert Bienert]

Moin!

Was hat denn der für ein Problem mit den paar Bytes? Wozu gibt es komprimierte Übertragung? Aber solange 6 (!) von 1.91 Millionen Seiten[*] das verwenden sehe ich da irgendwie schwarz für die Netzauslastung.

[*] Abfrage der ersten 1.91Mio URLs des DMOZ

Vielleicht liegt das daran, dass sämtliche Freehoster und Anbieter günstigen Webspaces so nützliche Dinge wie das mod_gzip oder Content-Negotiation standardmäßig nicht anbieten. Ich müsste bei mir z.B. _jede Datei_ durch PHP jagen, um sie zu komprimieren. Da stellt man sich schon die Frage zwischen Netz- und CPU-Performance bzw. Komfort.

Viele Grüße,
Robert

[Orlando]

Hallo Robert,

Vielleicht liegt das daran, dass sämtliche Freehoster und Anbieter günstigen Webspaces so nützliche Dinge wie das mod_gzip oder Content-Negotiation standardmäßig nicht anbieten. Ich müsste bei mir z.B. _jede Datei_ durch PHP jagen, um sie zu komprimieren.

Sicher? Bei mir komprimiert gzip_cnc:

| Content (encoded: 21.36 KiB / decoded: 160.46 KiB)

Da stellt man sich schon die Frage zwischen Netz- und CPU-Performance bzw. Komfort.

Nicht bei sinnvollem Caching. Auch das leistet gzip_cnc.

Das Problem ist eher, dass heutzutage jeder Furz, den man auch mit einem guten Editor als statische Seite hinbekäme mit PHP gebläht wird.

Grüße
 Roland

[Cybaer]

Hi,

Das Problem ist eher, dass heutzutage jeder Furz, den man auch mit einem guten Editor als statische Seite hinbekäme mit PHP gebläht wird.

Da PHP passende Funktionen dafür hat (http://php.net/ob_gzhandler) ist *das* diesbezügl. wohl nicht das Problem.

Zu Zeiten des "Triple Play" mit seinen Datenmengen ist es wohl eher ein Gleichgültigkeit, die viele (mich eingeschlossen) wohl hier den paar KBytes an den Tag legen (zumal "wir" ja darauf getrimmt sind), die Datenmenge ohnehin noch akzeptabel zu halten, selbt für Surfer mit älteren Browsern (ohne gzip) und Modem (die allerdings ggf. ohnehin selbst komprimieren).

Gruß, Cybaer

[Robert Bienert]

Moin!

Vielleicht liegt das daran, dass sämtliche Freehoster und Anbieter günstigen Webspaces so nützliche Dinge wie das mod_gzip oder Content-Negotiation standardmäßig nicht anbieten. Ich müsste bei mir z.B. _jede Datei_ durch PHP jagen, um sie zu komprimieren.

Sicher? Bei mir komprimiert gzip_cnc:

Klingt gut, werde ich einmal ausprobieren, glücklicherweise habe ich auch Perl für CGI-Anwendungen.

Da stellt man sich schon die Frage zwischen Netz- und CPU-Performance bzw. Komfort.

Nicht bei sinnvollem Caching. Auch das leistet gzip_cnc.

Gibt es so etwas auch für PHP? Für diejenigen, die wie ich PHP und Perl nutzen können, werde ich das mal testen.

Das Problem ist eher, dass heutzutage jeder Furz, den man auch mit einem guten Editor als statische Seite hinbekäme mit PHP gebläht wird.

Das ist durchaus richtig und entspringt wahrscheinlich der Faulheit der Programmierer: Warum soll ich erst lokal ein Preprocessing betreiben, wenn es doch auch „on the fly“ geht? Bedenke, dass nicht jeder Webprogrammierer mit make umgehen kann (wäre allerdings praktisch, erspart einem viel Arbeit).

Viele Grüße,
Robert

[hase]

Nun meine Frage mal an euch. Haltet Ihr euch an die W3C Richtlinien ? Oder was sagt Ihr zu diesem Text?

Ohne den Mann beleiden zu wollen: Klugsch***er, Laberk*pp, W*cht*gtuer. BWLer?

An was sollte man sich stattdessen halten? An die CEOs der Bochumer Webdesignagenturen?

[In Bed with Lotta in Love]

Hallo,

ich hatte auch schon Kunden die auf irgendwelche unnötigen IE-Merkwürdigkeiten bestanden. Obwohl man drei bessere Lösungen W3C-konform angeboten hatte bestand er darauf das es so gelöst wird, denn: "Unsere Kunden nutzen zu 99,9999999999999% den IE unter Windows". Wer Scheiße will, obwohl es problemlos anders geht, soll Scheiße bekommen. Nur soll er später, wenn die Einsicht kommt, nicht mir die Schuld in die Schuhe schieben. Ich hab kein Problem mit einem Folgeauftrag wenn der Dummkopf irgendwann seinen Fehler bemerkt.

[Robert Bienert]

Moin!

ich hatte auch schon Kunden die auf irgendwelche unnötigen IE-Merkwürdigkeiten bestanden. Obwohl man drei bessere Lösungen W3C-konform angeboten hatte bestand er darauf das es so gelöst wird, denn: "Unsere Kunden nutzen zu 99,9999999999999% den IE unter Windows".

Haben denn die anderen Lösungen in _allen relevanten Browsern_ halbwegs problemlos funktioniert? Wenn ja, warum will der Kunde dann auf aktuelle 0,0000000000001% seiner Kunden verzichten? Und was macht er, wenn von heute auf morgen ein Großteil der Kunden einen anderen Browser benutzt?

Wer Scheiße will, obwohl es problemlos anders geht, soll Scheiße bekommen. Nur soll er später, wenn die Einsicht kommt, nicht mir die Schuld in die Schuhe schieben. Ich hab kein Problem mit einem Folgeauftrag wenn der Dummkopf irgendwann seinen Fehler bemerkt.

Hey, sie es doch mal so: Damit verdienst du doppelt. Ist das nicht eine gute Geschäftsidee, und der Kunde ist sogar auf sie gekommen, von daher ist dieser trotz gegenteiliger Belehrung selbst daran Schuld.

Viele Grüße,
Robert

[Ingo Turski]

Hi,

Ich teile wahsagas Meinung, finde dieses Statement allerdings gar nicht mehr lustig, sondern nur völlig blödsinnig.

Dem zu Folge hat das W3C weder die Berechtigung noch die Möglichkeit, verbindliche Normen aufzustellen und veröffentlicht korrekter Weise auch lediglich Empfehlungen. Diese Empfehlungen, auch wenn sie von selbsternannten W3C-Priestern und deren unwissenden Jüngern als sakrosankt betrachtet und dargestellt werden, verfügen über weniger Verbindlichkeit als die 130 km/h-Richtgeschwindigkeit auf deutschen Autobahnen. Ausschließlich aus der Befolgung dieser Empfehlungen auf die Zukunftssicherheit eigener Arbeiten zu schließen, erscheint vor diesem Hintergrund zu mindest naiv.

Korrekt ist, dass es sich um Empfehlungen handelt. Völlig naiv ist hingegen, bei Nichteinhaltung der Empfehlungen im Umkehrschluß davon auszugehen, dass eine Seite in irgend einer Weise zukunftssicher sein könnte.
Der Mensch verkennt den Sinn dieser Empfehlungen gründlichst! Internetseiten werden von verschiedenen Browsern dargestellt. Die Browserhersteller müssen sich zwangsläufig an irgend welche Empfehlungen orientieren, um die angebotenen Seiten einheitlich darstellen zu können - und sie tun es auch immer mehr; selbst Microsoft hat diese Notwenigkeit eingesehen und versucht, mit dem IE7 einen standardkonformeren Weg zu gehen.

Früher - in den 90ern - war es noch etwas anders: da gab es den IE und Netscape. Beide Browser gingen zunächst eigene Wege und die Webseitenersteller mußten sich mit den Eigenheiten dieser beiden marktbeherrschenden Browsern arrangieren. Heraus kamen unbefriedigende Kompromisse.
Inzwischen haben wir allerdings eine Browservielfalt und ohne Regelungen wäre es weder für die Browserhersteller noch für die Webseitenersteller möglich, für eine einheitliche Darstellung von Webseiten zu sorgen.
Die Empfehlungen des W3C haben diesbezüglich normativen Charakter erhalten, dem sich kein Browserhersteller verweigert. Und: alternative Normen gibt es nicht!

Es kann also durchaus darauf verzichtet werden, dem W3C-„Validator“ die Bedeutung eines Bundesverfassungsgerichts beizumessen.

das wird auch niemand tun, der etwas Ahnung von der Materie hat.

Ein weitaus besseres Beispiel wäre mp3 - übrigens auch am Fraunhofer Institut entwickelt. ;-)
Hier hat die Industrie diesen Standard übernommen (wie die Browserhersteller die Empfehlungen des W3C) und erst nachher wurde mp3 in den ISO-Standard aufgenommen. Ohne Normierung wären die vielfältigen mp3-Geräte nicht möglich gewesen.
Übrigens ist ISO auch keine behördliche Organisation...

Dessen ungeachtet bleibt es selbstverständlich jedem unbenommen, sich, wenn er es will,  für seine eigenen Internetprojekte ausschließlich an den gerade mal aktuellen Empfehlungen des W3C zu orientieren. Aus solcher Selbstbeschränkung allerdings den Anspruch der Professionalität abzuleiten, erscheint doch eher fragwürdig.

Der Verfasser dieser Zeilen scheint sich mit den Empfehlungen des W3C nch nicht einmal näher auseinander gesetzt zu haben.
* Die aktuellen Empfehlungen sind ohnehin "Zukunftsmusik" und heute kaum praktisch einsetzbar.
* Demgegenüber sind ältere Empfehlungen wie HTML 4.01 auch heute noch gültig.
* An welche der Empfehlungen man sich orientiert, ist im DOCTYPE anzugeben.
Sich hingegen an keiner Empfehlung zu orientieren ist nicht nur unprofessionell, sondern dumm.

freundliche Grüße
Ingo

[Cybaer]

Hi,

* An welche der Empfehlungen man sich orientiert, ist im DOCTYPE anzugeben.

Ich würde gerne eine DTD angeben - aber es interessiert keinen HTML-Browser ... :-(

Sich hingegen an keiner Empfehlung zu orientieren ist nicht nur unprofessionell, sondern dumm.

Sich an eine DTD zu halten ist richtig - diese zu ignorieren ist vielleicht dumm (IMHO: sicher dumm), aber HTML ist *bewußt* so ausgelegt worden, daß möglichst wenig Aufwand betrieben werden muß, um es einfachst schreiben zu können - auchund gerade von Leuten, die sichnichttiefn die Materie einarbeiten möchten.

Wenn das jemandem nicht paßt, ist das sein gutes Recht. Er kann jederzeit eine formalistischere Markupsprache wählen (z.B. XML)

Gruß, Cybaer

[Richard Rüfenacht]

Hallo jUnit!

Nun meine Frage mal an euch. Haltet Ihr euch an die W3C Richtlinien ? Oder was sagt Ihr zu diesem Text?

Ich finde, du hättest dir beim Erfinden dieser Geschichte etwas mehr Mühe geben sollen. ;-) Zumindest dich wenigstens etwas über das W3C informieren sollen.

Welcher Kunde würde sich schon die Mühe machen, einen solchen Text zu schreiben und sich dabei auch noch als so inkompetent darstellen? Und welcher seriöse Anbieter von Leistungen würde andererseits seine Kunden derart in die Pfanne hauen und einen solchen Schwachsinn der Öffentlichkeit präsentieren?

Beste Grüsse
Richard

[JB]

Ja, ne is klar.

Das W3C hat keinerlei relevanz, schließlich sind im Multimedia-verband Bonn-Popelsdorf wichtigere Firmen versammelt als im W3C.

http://www.w3.org/Consortium/Member/List

Auszug aus der Mitgliederliste:
Apple Computer, Inc.
Microsoft Corporation
Opera Software

Damit hätten wir schonmal die drei relevanten Browserhersteller.
Alle anderen wichtigen IT-Firmen findet man auch, von IBM bis SUN.

Aber gut die Rechtsform (wobei er merkwürdigerweise davon ausgeht das es eine Deutsche sein muss) und der "admin-c" sind natürlich aussagekräftiger als die Tatsache dass sich im W3C alle Organisatonen und Firmen versammelt sidn die überhaupt mit dem Thema zu tun haben.

Aber möchtig dicke Backen hat er gemacht, Dein Kunde. Dumm nur das es absolut peinlich ist was er da vom Stapel lässt.

[JB]

Apple Computer, Inc.
Microsoft Corporation
Opera Software

Mozilla Foundation

Asche auf mein Haupt. Hab ich vergssen rein zu kopieren.

[Hopsel]

Hi JB!

Mozilla Foundation
Asche auf mein Haupt. Hab ich vergessen rein zu kopieren.

Dein Glück. Hatte schon den Knüppel ausgepackt! =)

MfG H☼psel

[Orlando]

Hallo Hopsel,

Asche auf mein Haupt.

Hatte schon den Knüppel ausgepackt! =)

Dieses Vorrecht genießt hier nur Gernot.

Grüße
 Roland

[Cybaer]

Hi,

Hatte schon den Knüppel ausgepackt! =)
Dieses Vorrecht genießt hier nur Gernot.

ROTFL

Gruß, Cybaer

[Cybaer]

Hi,

Nun meine Frage mal an euch. Haltet Ihr euch an die W3C Richtlinien ?

W3C WHAT(WG)?

Oder was sagt Ihr zu diesem Text?

Sehe ich auch so.

Gruß, Cybaer

[Tom2 (der authentifizierte)]

Hallo

Haltet Ihr euch an die W3C Richtlinien ?

Sofern sie mir bekannt sind und ich nicht anderes als sinnvoller erachte halte ich mich schon daran. Ausnahmen gibt's vor allem im Intranet, wo leider der IE den Standard vorgibt.

Oder was sagt Ihr zu diesem Text?

Der Text macht den Eindruck, als hättest du erbittert auf die W3C-Standards gepocht - und der Schreiberling erbittert versucht gegen zu halten. Vielleicht will er die Entwicklungszeit verkürzen und dadurch Geld sparen? Erklär ihm doch mal was für Vorteile es ihm bringt, wenn seine Seiten nach allgemein bekannten Best Practices (W3C Standards, Usability-Richtlinien, usw.) aufbauen lässt. Das Argument Geld zieht meist: Mehr potentielle Benutzer/Kunden, bessere und dadurch billigere Wartung und Erweiterung, sowie die Möglichkeit, die Daten maschinell weiter zu verarbeiten.

Gruss

Tom2

[Gunnar Bittersmann]

Hello out there!

Der Text macht den Eindruck, als hättest du erbittert auf die W3C-Standards gepocht

Ach wirklich? Macht er nicht eher den Eindruck, dass jUnit mal wieder ein bisschen trollen wollte? (siehe [Richard])

See ya up the road,
Gunnar

[Cybaer]

Hi,

Macht er nicht eher den Eindruck, dass jUnit mal wieder ein bisschen trollen wollte?

Also *das* steht doch wohl *absolut* außer Frage! ==:-)

Gruß, Cybaer

[wahsaga]

hi,

Vielleicht will er die Entwicklungszeit verkürzen und dadurch Geld sparen?

In dem er lange vergeblich nach den Ursachen von Darstellungsfehlern (ggf. nur in einzelnen Browsern) sucht, die möglichweise auf wirklich groben Fehlern beruhen?

Nee, also da arbeite ich wirklich schneller und effektiver, wenn ich meine Erzeugnisse vorher validiere.

gruß,
wahsaga

[Tom2 (der authentifizierte)]

Hi Wahsaga

In dem er lange vergeblich nach den Ursachen von Darstellungsfehlern (ggf. nur in einzelnen Browsern) sucht, die möglichweise auf wirklich groben Fehlern beruhen?

Wenn dem Kunden Standards egal sind, dann sind ihm auch andere Browser egal, d.h. er wählt wohl den IE als Standard.

Nee, also da arbeite ich wirklich schneller und effektiver, wenn ich meine Erzeugnisse vorher validiere.

Der Meinung bin ich auch.

Gruss

Tom2

[Cybaer]

Hi,

Nee, also da arbeite ich wirklich schneller und effektiver, wenn ich meine Erzeugnisse vorher validiere.

Ich arbeite schneller und effektiver, wenn ich vorher weiß, was ich tue. ;)

Wenn ich bei der Validierung etwaige Fehler raushaue: Gut.
Ich bin aber intelligent genug, dabei nach "richtigen Böcken" und "gewollten Abweichungen" zu unterscheiden.

Und diese Fähigkeit erwarte ich auch von einem Kollegen (sonst: Tonne oder Nachhilfe).

Gruß, Cybaer

[Cybaer]

Hi,

Mehr potentielle Benutzer/Kunden,

Der Schuß kann auch nach hinten losgehen.

bessere und dadurch billigere Wartung und Erweiterung,

Stimmt. Jemand, der nur eine Checkliste durchgehen und knöpfchendrücken kann, der ist billiger. Da ist auch einfacher Ersatz für zu finden ...

sowie die Möglichkeit, die Daten maschinell weiter zu verarbeiten.

Stimmt auch. Ist ja auch absolut üblich, Daten in z.B. XML vorzuhalten, mittels CMS daraus XHTML zu bauen (was anderes geht ja nicht billig - s.o.) und dann den XHTML-Output für Browser maschinell weiterzuverarbeiten - anstatt gleich das geeignetere XML-Original dafür zu verwenden.

Gruß, Cybaer

[molily]

Hallo,

Diese Empfehlungen, auch wenn sie von selbsternannten W3C-Priestern und deren unwissenden Jüngern als sakrosankt betrachtet und dargestellt werden, verfügen über weniger Verbindlichkeit als die 130 km/h-Richtgeschwindigkeit auf deutschen Autobahnen.

Wie gesagt: TCP/IP, HTTP usw., ohne die in der IT gar nichts ginge, verfügen auch über null Verbindlichkeit, müssen sie auch nicht. »Rough consensus, running code«! Normativ sind sie durch die Kraft des Faktischen.

Internetdateien

Was sind denn Internetdateien?

ausschließlich auf „Validität“ (= Wirksamkeit, lat. validus = wirksam) entsprechend den als „Standards“ propagierten W3C-Empfehlungen auszurichten, kann im Einzelfall durchaus zu sinnlosen Einschränkungen der tatsächlich verfügbaren Möglichkeiten führen

Klar: Nicht-standardisiertes ist Noch-nicht-standardisiertes.

Allerdings gibts im Bereich HTML/CSS überhaupt wenige Möglichkeiten, auf Proprietäres zu verzichten, schlicht weil wenig nützliche proprietäre Zusatztechniken existieren. Insofern schränkt man sich nicht ein. Es gibt höchstens einige proprietäre CSS-Eigenschaften, die man aber auch valide einbinden kann. Also, wo ist der Punkt?

Im Bereich JavaScript mag es nochmal anders sein: JavaScript und Webstandards

und verursacht regelmäßig, z. B. durch nach den W3C-Empfehlungen „erforderliche“ Zeilenschaltungen und Einrückungen in CSS und HTML

Häh? Wenn man kein Beispiel hat, einfach mal eines an den Haaren herbeiziehen?

Zusammenfassend lässt sich also feststellen, dass Darstellungen der W3C-Empfehlungen als verbindliche und einzig gültige Normen und Vorschriften für die Erstellung von Dateien lediglich als persönliche Meinungsäußerungen und nicht als Tatsachen zu betrachten sind.

Keine Ergebnisse menschlichen Denkens sind Tatsachen, sie schaffen höchstens Tatsachen. Und da hinter dem W3C mehr als eine Person mit einer unbedeutenden Meinung steckt, schafft das W3C indirekt unzählige Tatsachen.

Natürlich sind die W3C-Normen die einzig gültigen Vorschriften, ein wirkliches Alternativ-HTML, Alternativ-CSS und Alternativ-DOM gibt es nicht. Nach was könnte man sich sonst richten?

Verbindlichkeit existiert nur, sobald eine Struktur der Sanktionierung existiert. Die existiert auch bei DIN- und ISO-Normen nicht per se. Daher kann jeder freudig dagegen verstoßen. Das untergräbt aber überhaupt nicht den Sinn von technischen Standards.

Es kann also durchaus darauf verzichtet werden, dem W3C-„Validator“ die Bedeutung eines Bundesverfassungsgerichts beizumessen.

Es gibt wenig gute Gründe, nicht Validator-validen Code zu schreiben. Du wirst sicher welche nennen können, nicht?

Mathias

[Cybaer]

Hi,

Allerdings gibts im Bereich HTML/CSS überhaupt wenige Möglichkeiten, auf Proprietäres zu verzichten, schlicht weil wenig nützliche proprietäre Zusatztechniken existieren.

Und wer bestimmt, wie sinnvoll die "wenigen nützlichen proprietären" Zusatztechniken für einen sind?

Insofern schränkt man sich nicht ein.

Ich gehe davon aus, daß jeder Browserhersteller seine propritären Elemente & Attribute eingebaut hat, weil er sie a) als sinnvoll erachtet oder b) denkt, daß Webautoren sie als sinnvoll erachten könnten oder c) es andere vor ihm gemacht haben und es als sinnvoll erachtet und damit genutzt wurde (s. normative Kraft des Faktischen).

Ich gehe nicht davon aus, daß etwas eingebaut wird, wovon der Programmierer ausgeht (und inständig dafür betet), daß niemals nie jemand auch nur den Gedanken daran verschwendet, das zu nutzen. ;)

Es gibt wenig gute Gründe, nicht Validator-validen Code zu schreiben. Du wirst sicher welche nennen können, nicht?

Muß man das wirklich zum 50000stden Mal machen? OK, diese Diskussion ist ja auch nicht neu ... >:->

Gruß, Cybaer

[molily]

Hallo,

Und wer bestimmt, wie sinnvoll die "wenigen nützlichen proprietären" Zusatztechniken für einen sind?

Der Nutzer als Nutzer. Meine Erfahrung als solcher im Austausch mit anderen hat mir gezeigt, dass es wenige proprietäre Zusatztechniken breite Anwendung finden. Ich kenne keine sonderlich nützlichen, breit verwendbaren und deshalb auch verbreiteten proprietären HTML-Elemente oder -Attribute bzw. CSS-Eigenschaften, nach denen sich die Webautoren wirklich die Finger lecken. Wäre es so, hätte sicher niemand Probleme damit, diese auch zu nutzen und in diesem Punkten von den üblichen Standards abzuweichen.

Die opacity-Eigenschaft ist vielleicht eine, die momentan durch den Ajax-Hype mit den ganzen lahmen Bling-Bling-Effekten hochgekocht wird. Aber ob das eine essentielle Erweiterung ist, möchte ich in Frage stellen. Zudem ist die Eigenschaft nicht klassisch proprietär, sondern die Implementierungen sind ein Vorgriff auf CSS 3.

(...) Ich gehe nicht davon aus, daß etwas eingebaut wird, wovon der Programmierer ausgeht (und inständig dafür betet), daß niemals nie jemand auch nur den Gedanken daran verschwendet, das zu nutzen. ;)

Trotzdem stellt sich die Lage für den Webautoren vielschichtiger dar. Eine Erfindung für sich genommen unabhängig von den realen Umständen der Benutzung als sinnvoll zu erachten, ist nicht der Punkt. Er muss die mögliche Nützlichkeit damit abwägen, dass die Technik nur bei manchen Besuchern funktioniert und eventuell Alternativen nötig sind. Wenn man das mit hineinnimmt, schwindet der vermeintliche Sinn meist schnell.

Es gibt wenig gute Gründe, nicht Validator-validen Code zu schreiben. Du wirst sicher welche nennen können, nicht?

Muß man das wirklich zum 50000stden Mal machen?

Ja, und sei es auch durch Verweise auf vorige Diskussionen. Schließlich kommen immer wieder welche, die diese Frage stellen.

Mathias

[Cybaer]

Hi,

Der Nutzer als Nutzer. Meine Erfahrung als solcher im Austausch mit anderen hat mir gezeigt, dass es wenige proprietäre Zusatztechniken breite Anwendung finden.

Kommt halt drauf an. XMLHttpRequest war auch mal eine proprietäre Zusatztechnik, innerHTML im gewissen Sinne auch.

Beide sind nach wie vor proprietär, sind aber Quasi-Standard und werden mittlerweile weithin genutzt.

Wir (Du, ich & viele andere hier im Forum) sind uns doch einig, daß man mit der eingesetzten Technik nicht User von der Website ausschließen sollte. Wir sind uns aber wohl auch einig, daß nicht jedes *Zusatz*-Feature für jeden Browser nutzbar zu sein braucht. Ich denke nicht, daß es sinnvoll ist, einem Nutzer ein Zusatzfeature zu verwehren, nur weil die anderen Surfer das mit ihrem Browser nicht nutzen können.

Wäre es so, hätte sicher niemand Probleme damit, diese auch zu nutzen und in diesem Punkten von den üblichen Standards abzuweichen.

Dann ist ja gut. Bisher hatte ich das "Validität muß sein" so gedeutet, daß Validität sein muß, nicht, daß es sein sollte, man aber davon abweichen kann, wenn es einem sinnvoll erscheint. ;)

Darauf kann man sich einigen. :)

Die opacity-Eigenschaft ist vielleicht eine, die momentan durch den Ajax-Hype mit den ganzen lahmen Bling-Bling-Effekten hochgekocht wird. Aber ob das eine essentielle Erweiterung ist, möchte ich in Frage stellen.

Es ist zumindest eines der Layout-Effekte, dich ich z.Zt. sehr gerne benutze. Ich habe auch schon Code mit gut getricksten Transparenzeffekten (aus der Vor-Opacity-Ära) mit dem Opacity-CSS (ganz im Sinne semantischen Markups) wunderbar säubern können. :)

Trotzdem stellt sich die Lage für den Webautoren vielschichtiger dar. Eine Erfindung für sich genommen unabhängig von den realen Umständen der Benutzung als sinnvoll zu erachten, ist nicht der Punkt. Er muss die mögliche Nützlichkeit damit abwägen, dass die Technik nur bei manchen Besuchern funktioniert und eventuell Alternativen nötig sind. Wenn man das mit hineinnimmt, schwindet der vermeintliche Sinn meist schnell.

Du solltest meinen Standpunkt aus vielen Threads gut genug kennen, daß Du abschätzen kannst, daß meine Priorität dem Anwender gilt, nicht dem Autor.

Es gibt wenig gute Gründe, nicht Validator-validen Code zu schreiben. Du wirst sicher welche nennen können, nicht?
Muß man das wirklich zum 50000stden Mal machen?
Ja, und sei es auch durch Verweise auf vorige Diskussionen. Schließlich kommen immer wieder welche, die diese Frage stellen.

• Das FRAME-Problem hat ja Christian bereits angesprochen
• Ich nutze WBR sehr gerne, für das es nach wie vor keinen validen Ersatz ohne Nachteile gibt (wie ja im Archiv auch nachzulesen ist)
• Ich habe kein Problem damit, einer Tabelle, der ich mit CSS' height eine Höhe zugewiesen habe, dies als Fallback für ältere Non-CSS-Browser mit dem HEIGHT-Attribut ebenfalls zu tun.
• generell habe ich überhaupt kein Problem damit, veraltete Tags & Attribute als Fallback zu verwenden. Selbst wenn meine Quelltexte auf Browser träfen, die sie nicht mehr unterstützen würden: Egal - sie sind auch nicht für diese Browser gedacht.
• Ich habe auch kein Problem damit, eigene Tags und Attribute zu "erfinden", die ich aus irgendwelchen *internen* organisatorischen Gründen brauche. Ich nutze das nicht intensiv, und so extensiv wie es manche Editoren und CMS-System nutzen, ist es mir ggf. auch ein Greuel, aber die Möglichkeit als solche nutze ich durchaus.
• Ich habe auch kein Problem damit, proprietäre Tags zu nutzen, die ich als sinnvoll erachte. Das muß nicht unbedingt MARQUEE sein (Laufschriften mag ich persönlich nicht, aber ich bin auch kein "blindwütiger Laufschrifthasser", sondern erkenne durchaus an, daß es gute Gründe für Laufschriften geben kann - sowohl aus wahrnehmungspsychologischer, als auch philosophischer Sicht). Auch CANVAS würde ich jederzeit nutzen - zumal das ja eine Alternative für CANVAS-lose Browser nicht ausschließt.

etc.

Gruß, Cybaer

[molily]

Hallo,

Meine Erfahrung als solcher im Austausch mit anderen hat mir gezeigt, dass es wenige proprietäre Zusatztechniken breite Anwendung finden.

Kommt halt drauf an. XMLHttpRequest war auch mal eine proprietäre Zusatztechnik, innerHTML im gewissen Sinne auch.

Ja, wie gesagt ist JavaScript eine Sache für sich. Da geht alles drunter und drüber, weil bereits Grundlagen wie das oberste window-Objekt nichts als erfolgreiche proprietäre Erfindungen sind.

Es gibt wenig gute Gründe, nicht Validator-validen Code zu schreiben. Du wirst sicher welche nennen können, nicht?

Ich bilde da mal Gruppen:

1. Nicht standardisiertes Markup, das man benutzen muss, um einen gewissen Effekt in alten Browsern bzw. aktuellen, nicht-standardkonformen zu erreichen (height bei table, wbr (AFAIK?), border bei Frames)
2. Genuin proprietäres, aber möglicherweise breit utnerstütztes Markup (marquee)
3. Eigenes Markup bzw. Markup aus anderen, festgelegten Namensräumen, z.B. als JavaScript Trigger
4. Noch nicht W3C-standardisierte Zukunftstechniken (Canvas, Web Forms, »HTML 5«)

Alles zugestanden, aber das bestärkt mich in der Meinung, dass es in den meisten Fällen keinen überzeugenden Anreiz gibt, von validem Code abzuweichen. Die Beispiele beziehen sich größtenteils auf vergleichsweise unwahrscheinliche Spezialfälle. Deshalb könnten meiner Einschätzung nach ein Großteil der Webangebote valide sein, ohne dass sich der Autor selbst beschränken muss.

Zu 1.: Generell habe ich den Eindruck, dass sich die wenigsten noch für solche alten Browser interessieren, selbst valides Transitional-Markup wird zunehmend vermieden.
Zu 2.: Für marquee gibt es intelligentere und benutzerfreundlichere Scripte als Ersatz.
Zu 3.: Generell scheint mir das noch das realistischste Szenario, nicht HTML-validen Code zu schreiben. Allerdings hat sich da der Trend auch gewendet: Anstatt eigene Attribute einzusetzen, werden zunehmend Klassen als JavaScript-Trigger benutzt. Auch bei der semantischeren Auszeichnung geht der Trend in Richtung Beschränkung auf das HTML-Vokabular, siehe die Microformats.
Zu 4.: Ohne Zweifel tut sich da ein riesiger Bereich der wirklich nützlichen W3C-Abweichung auf. (Wobei man trotzdem gegen die DTDs der alternativen Standards der WHATWG validieren kann.) Das wird wohl in der Zukunft die häufigste Art der Abweichung sein, wenn es dem W3C nicht gelingt, diese Entwicklungen zu integrieren. Der gegenwärtige Einfluss ist da wie gesagt noch gering einzuschätzen.

Mathias

[Cybaer]

Hi,

Ich bilde da mal Gruppen:

Schön gruppiert. :-)

Alles zugestanden, aber das bestärkt mich in der Meinung, dass es in den meisten Fällen keinen überzeugenden Anreiz gibt, von validem Code abzuweichen.

Und ich sehe keinen Anreiz, validen Code zu schreiben, bei dem ich als einzigen "Sinn" die Validität als solche sehe. Es bringt mir keinen Vorteil - außer dem "Fuchsschwanz" den sich manche Webautoren - selbst auf kommerziellen Seiten - an die Site kleben ("Diese Seite ist ..."). Aber das mache ich selbst auf den Seiten von mir nicht, auf die es zutrifft. >;->

Daß ich jedem Einsteiger *dringend* nahelegen würde, die Standards *prinzipiell* zu beachten (und zwar je strikter, desto weniger Erfahrung sie haben), versteht sich hingegen von selbst (selbst mit der genauen Einhaltung der "Wohlgeformtheit" kann man ja locker auf dem Bauch landen).

Gruß, Cybaer

[Swen Wacker]

Moin,

was sagt Ihr zu diesem Text?

Der Text wirkt auf mich schlecht recherchiert, voreingenommen verfasst und in sich widersprüchlich; zudem ist er nicht wirklich flott geschrieben sondern eher krampfhaft selbstverliebt. Wenn ich den Text lese, dann sehe ich mir gegenüber einen eher verkrampft sitzenden, leicht speichelnden jungen Mann, der meint, einen richtig tollen Text geschrieben zu haben und leider nicht realisiert, dass er gerade in einer Innenwelt lebt, die nicht einfach so über alle anderen gestülpt werden kann. Der Text fordert nicht dazu heraus, sich mit ihm auseinzusetzen oder einen Gegenentwurf zu schreiben. Ich empfehle den Autor, mal was über IETF oder ISOC zu lesen. Spätestens dann wird er behaupten, das Internet könne eigentlich nicht funktionieren :-)

My 2 cents, wenn wir schon gerade über w3c reden: Wer das W3C ablehnt oder seine Rolle nach unten zu relativieren versucht, schafft damit keinen positiv zu wertende Freiheit nach dem Denkmuster "Deregulierung und der Markt brummt" sondern sägt am Stamm des Kommunikationsbaumes, auf dem er sitzt. Das WWW funktioniert (wie eigentlich jeder Dienst des Internets) aufgrund der gelebten Konvention, die selbstgegebenen Normen auch zu nutzen und damit zu beachten). Flapsig gesagt: Eine Regel, die wo nicht (mehr) beachtet wird, ist keine Regel mehr. Das unterscheidet das Modell von den nationalen oder internationalen Normgebern wie DIN&Co, die Regeln eher als Gesetze betrachten und sich nicht darum scheren müssen, ob die Regel auch praktisch relevant ist. In Folge dieses Ansatzes (der in anderen Bereichen sicherlich erfolgreich ist) neigen deren Vorschriften eher zur Perfektion als zur Praxistauglichkeit. Netzwerke funktionieren (nicht nur in der Technik) allerdings anders als gewaltengetrennte Demokratien oder über-/unterordnung-Hierarchien. Sie brauchen unbedingt akzeptiert, gelebte, Regeln. Das Netzwerk gebiert sich quasi selbst, es wird nicht befohlen.

Das Internet braucht also einen Willen zur Zusammenarbeit, der ganz bewusst nicht in Befehl und Gehorsam enden darf. Ein W3C-Standard kann also nicht sakrosant sein. Im Gegenteil: er ist permanenter Kritik unterworfen. Umgekehrt wäre es fast ein schlechtes Zeichen, wenn über einen Standard nicht mehr diskutiert wird. Das führt nicht zu Chaos (und damit zum Untergang des Netzes), solange die Teilnehmer insgesamt den Willen zur Zusammarbeit haben. Dabei ist es nicht so schlimm, wenn einer quertreibt: Macht jemand nicht, dann geht nicht das Internet unter sondern der "jemand" steht halt draußen vor der Tür und spielt nicht mehr mit - bis er wieder mitmachen will bei den Regeln.

Gruß

Swen Wacker

[Cybaer]

Hi,

Ein W3C-Standard kann also nicht sakrosant sein. Im Gegenteil: er ist permanenter Kritik unterworfen.

Hmm, heißt das jetzt: Kritik ist OK, aber man muß sich trotzdem danach richten, denn Validität muß ja sein?
Oder heißt das: Kritik ist OK, und man muß sich in den Kritikpunkten nicht nach dem W3C richten?

In der Geschichte des WWWs hat es soviel Kritik am W3C gegeben. Wenn es immer nur nach den Standards des W3C gegangen wäre, würden wir ja heute noch in Höhlen hausen ... ;->

Dabei ist es nicht so schlimm, wenn einer quertreibt: Macht jemand nicht, dann geht nicht das Internet unter sondern der "jemand" steht halt draußen vor der Tür und spielt nicht mehr mit - bis er wieder mitmachen will bei den Regeln.

So wie ich das sehe, war und ist das oft genug das W3C, das draußen steht und wieder mitmacht, indem es die Regeln ändert - sie der Praxis anpaßt, die bereits vor den Regeln existierte. 8->

Beispiele hatte ich dafür ja so einige genannt ... :)

Gruß, Cybaer

[Swen Wacker]

Moin,

Hmm, heißt das jetzt: Kritik ist OK, aber man muß sich trotzdem danach richten, denn Validität muß ja sein?
Oder heißt das: Kritik ist OK, und man muß sich in den Kritikpunkten nicht nach dem W3C richten?

Ich glaube nicht, dass es da die einfache Ja/Nein-Antwort gibt.

Das System (des Entstehens) der Recommendations ist einen fein ausgeklügeltes System zwischen akzeptierten Standard und gewolltem Fortschritt einerseits und Einfangen von Fehlentwicklungen und Fördern von Innovationen anderseits; alles zugleich auf allen möglichen Ebenen der Technik, der Usability, der Weiterentwicklung des Webs, des Rechts und der finanziellen Interessen aller Teilnehmer, garniert mit den persönlichen Vorlieben und Animositäten. Ich hatte mal vor Jahren (zusammen mit Björn Höhrmann) die große Freude, auf einer Tagung des W3C ausführlicher mit Bert Bos darüber zu sprechen - "wir hörten ihm fast dem ganzen Abend zu" wäre eine bessere Beschreibung unserer Tätigkeit in diesem Gespräch :-) - und habe danach meine Meinung über die Heiligkeit der Recommendations revidiert. Ich war bis dahin überzeugter Anhänger des niederkanzelns jeglicher Nichtvalidität, weil ich glaubte, dass jede Fehlentwicklung die Universalität des Webs gefährden würde. Ich hätte also gut in dciwam gepasst. Mittlerweile weiß ich um die praktische Unmöglichkeit, immer valide zu arbeiten und habe kein schlechtes Gewissen beim (bewusst und nach Abwägung der Argumente begangenen) kontrollierten Verstoß gegen Regeln. Nicht der Verstoß an sich ist böse, es kommt auch auf das Motiv an.

In gewisser Hinsicht und mit ein paar Abstrichen kann man die Validitätsdiskussionen auch mit Diskussionen über Rechtschreibreformen vergleichen. Ich erkenne immer wieder ähnliche Argumentationsmuster.

Ich möchte deine Frage aber lieber mit einem Bild jenseits der Rechtschreibreform beantworten:
Stell Dir vor, Du stehst an einem sonnigen Morgen um fünf Uhr in der Früh hellwach und vor jeglichem Berufsverkehr an einer roten Fußgängerampel, die Fußgängern ermöglicht, eine selten befahrene Dorfstraße zu queren. Du kennst Dich hier aus, wohnst seit Jahren in unmittelbarer Nähe und würdest jede Änderung der Situation mitbekommen. Kein anderer Fußgänger, dem Du ein schlechtes Vorbild sein könntest ist weit und breit zu sehen, kein anderer Verkehrsteilnehmer ist auf der weit und breit einsehbaren Straße zu erkennen. Gehst Du rüber oder bleibst Du stehen?
Ich finde, das rübergehen ist vertretbar. Ich finde aber auch, dass es auf die Motivlage ankommt. Wer nämlich die Abwägung, die in meinem Beispieltext suggeriert wird, vornimmt, der "darf" gegen die Regel verstoßen. Wer ohne nach links und rechts zu schauen "Weil das immer schon so geklappt hat" die Straße quert, oder wer sagt: "Mir doch egal, die Autos müssen bremsen" und blindlinks, unausgeschlafen und mit besoffenen Kopf losmarschiert, der "darf" nicht.

In der Geschichte des WWWs hat es soviel Kritik am W3C gegeben. Wenn es immer nur nach den Standards des W3C gegangen wäre, würden wir ja heute noch in Höhlen hausen ... ;->

... oder wieder in Höhlen hausen :-) Man sollte halt möglichst oft wissen was man (nicht) macht und warum man es (nicht) macht und was daraus folgen kann.

Viele Grüße

Swen Wacker

[at]

Hallo.

blindlinks

Heißt das nicht "einäugig"?
MfG, at

[Swen Wacker]

Moin,

blindlinks
Heißt das nicht "einäugig"?

Hehe, so schön bin ich selten auf Fehler aufmerksam gemacht worden :-)

Viele Grüße

Swen Wacker

[at]

Hallo.

Hehe, so schön bin ich selten auf Fehler aufmerksam gemacht worden :-)

Jetzt sollte ich vielleicht besser sagen, dass ich das auch nie wieder machen werde, bevor du noch anfängst, gezielt welche einzubauen.
MfG, at

[Swen Wacker]

Moin,

... bevor du noch anfängst, gezielt welche einzubauen.

Meine nähere Umgebung schmunzelt bei der Idee, ich könnte zielgerichtet arbeiten :-)

Viele Grüße

Swen Wacker

[Orlando]

Hallo Swen,

... bevor du noch anfängst, gezielt welche einzubauen.
Meine nähere Umgebung schmunzelt bei der Idee, ich könnte zielgerichtet arbeiten :-)

Die Gießkanne als Symbol des Kassierers. Hat was, ja. ;-)

Grüße
 Roland

[Cybaer]

Hi,

Man sollte halt möglichst oft wissen was man (nicht) macht und warum man es (nicht) macht und was daraus folgen kann.

Meine Rede! :)

Gruß, Cybaer

[Swen Wacker]

Moin,

Meine Rede! :)

Wenn wir uns dann auch einig sind, dass die Hauptrichtung Konformität ist - von wegen der grundsätzlichen Notwendigkeit zur Akzeptanz der Regeln - und der Regelverstoß die zu begründende Ausnahme ist ... :-)

Viele Grüße

Swen Wacker

[at]

Hallo.

Wenn wir uns dann auch einig sind, dass die Hauptrichtung Konformität ist - von wegen der grundsätzlichen Notwendigkeit zur Akzeptanz der Regeln - und der Regelverstoß die zu begründende Ausnahme ist ... :-)

Darin besteht vermutlich breite Einigkeit, nur bei der Akzeptanz der Begründungen wird es immer wieder Differenzen geben.
MfG, at

[Cybaer]

Hi,

Darin besteht vermutlich breite Einigkeit, nur bei der Akzeptanz der Begründungen wird es immer wieder Differenzen geben.

Wie gesagt: Ein bißchen valide gibt es ebensowenig, wie ein bißchen schwanger.

Entweder man akzeptiert prinzipiell die Möglichkeit des Abweichens von der Validität, oder man beharrt auf der Validität - und zwar Validität zu einer DTD des W3C. Denn eigentlich bedeutet Validität ja nur "Gültigkeit einer bestimmten DTD" - und das könnte ja auch meine eigene sein - oder die des Browserherstellers.

Gruß, Cybaer

[at]

Hallo.

Entweder man akzeptiert prinzipiell die Möglichkeit des Abweichens von der Validität, oder man beharrt auf der Validität

Nur weil man prinzipiell Abweichungen zulässt, wird dennoch im Einzelfall Uneinigkeit über deren Rechtfertigung bestehen, W3C hin, Browser her. Wer mit jeder Abweichung einverstanden ist, weil er ja einen Sinn in diesem Prinzip sieht, hat letzteres offenbar gar nicht verstanden.
MfG, at

[Cybaer]

Hi,

Wer mit jeder Abweichung einverstanden ist,

Ist das denn irgendjemand?

Gruß, Cybaer

[at]

Hallo.

Wer mit jeder Abweichung einverstanden ist,

Ist das denn irgendjemand?

Ich hatte deine Aussage

Ein bißchen valide gibt es ebensowenig, wie ein bißchen schwanger.

so gedeutet, als wolltest du damit sagen, es käme bei einem invaliden Dokument ja ohnehin nicht mehr darauf an, den Code möglichst sauber zu halten. Und das liefe dann auf den bekannten Quälcode hinaus.
MfG, at

[Cybaer]

Hi,

Ich hatte deine Aussage

Ein bißchen valide gibt es ebensowenig, wie ein bißchen schwanger.
so gedeutet, als wolltest du damit sagen, es käme bei einem invaliden Dokument ja ohnehin nicht mehr darauf an,

Interessant.

den Code möglichst sauber zu halten. Und das liefe dann auf den bekannten Quälcode hinaus.

Warum dort aufhören? Die Menge an Abweichungen von jeweder Norm, die einen Quellcode gänzlich unbrauchbar machen, gehen gegen unendlich ... >;->

Gruß, Cybaer

[Cybaer]

Hi,

Wenn wir uns dann auch einig sind, dass die Hauptrichtung Konformität ist - von wegen der grundsätzlichen Notwendigkeit zur Akzeptanz der Regeln - und der Regelverstoß die zu begründende Ausnahme ist ... :-)

Ja, auch da sind wir uns einig. :)

Gruß, Cybaer

[Chräcker Heller]

Hallo,

starker Tobak, in der Tat. Allerdings habe ich auch manches male schmunzeln müssen, manche Überspitzungen sind einfach zu nett.

Wie dem auch sei. Ich halte mich an die Standards, solange sie mür für die Kommunikation nicht hinderlich erscheinen ;-)

Allerdings bin ich auch der Meinung, da man in jedem regelsystem auch den Mut zum überlegtem Regelverstoss sich erlauben sollte, sonst betoniert man sich doch zu leicht fest.

Internetdateien ausschließlich auf „Validität“ (= Wirksamkeit,
lat. validus = wirksam) entsprechend den als „Standards“
propagierten W3C-Empfehlungen auszurichten, kann im Einzelfall
durchaus zu sinnlosen Einschränkungen der tatsächlich verfügbaren
Möglichkeiten führen

rausgelöst aus dem Kontex des ganzen Textes kann ich dem aber nur zustimmen. Es bedarf weit mehr Validitäts-checks als nur anhand der W3C, bis eine Seite gut und professionell ist. Allerdings ist die Validität nach dem W3C-Standart schon mal eine gute Basis ;-)

Chräcker

[Cybaer]

Hi,

starker Tobak, in der Tat. Allerdings habe ich auch manches male schmunzeln müssen, manche Überspitzungen sind einfach zu nett.

Ja, sehe ich auch so. :)

Wie dem auch sei. Ich halte mich an die Standards, solange sie mür für die Kommunikation nicht hinderlich erscheinen ;-)

Dito. ;)

Allerdings bin ich auch der Meinung, da man in jedem regelsystem auch den Mut zum überlegtem Regelverstoss sich erlauben sollte, sonst betoniert man sich doch zu leicht fest.

Dito. (Und BTW: Es ist ja auch erlaubt - es geht ja eigentlich nur um die "Jünger", die (hier) immer "Jehova" schreien ;->)

rausgelöst aus dem Kontex des ganzen Textes kann ich dem aber nur zustimmen. Es bedarf weit mehr Validitäts-checks als nur anhand der W3C, bis eine Seite gut und professionell ist. Allerdings ist die Validität nach dem W3C-Standart schon mal eine gute Basis ;-)

Zumindest keine schlechte. ;)

Gruß, Cybaer

[*Markus]

Hallo,

offensichtlich wieder nur ein Mensch, der gescheiter als der Rest der Welt sein will, aber Null Ahnung hat.
Warum glaubt er eigentlich, dass diese Standards aufgestellt werden, zum Spaß vielleicht. Den Webauftritt erstellt man ja nach den Richtlinien nicht deswegen, weil man es dem W3C recht machen will, sondern weil man möglichst viele Benutzer erreichen will, da sich die Browser ebenfalls nach dem Standard richten sollte. Andernfalls würde jeder Browserhersteller seine eigenen "Dialekte" entwickeln, was dazu führt, dass man eine Webseite gezielt für jeden Browser umschreiben müsste. Von wegen aufgeblähte Dateien.

Markus.

[Tim Tepaße]

Hallo,

mal ein ganz anderer Punkt, der mich an der gesamten Diskussion immer irritiert:

Validität wird hier immer dargestellt, als sei sie schwierig. Finde ich nicht. Finde ich eigentlich ganz und gar nicht. Vielleicht bin ich dazu zu sehr Informatiker, aber effektiv sind es nur ein paar vereinheitlichte Syntaxregeln, mehr nicht. Wenn man seinen Quellcode eh der Lesbarkeit vereinheitlicht, dann Die einzigen Punkte daran, die ich als halbwegs nervig empfinde, ist mein Lieblingsflüchtigkeitsfehlr, das ständige & und die Verschachtelung von Block- und Inlineelementen.

Ansonsten muss ich mich gedanklich schon recht anstrengen, um halbwegs aus Autorensicht praktische Verstöße gegen Validität nach DTDs zu konstruieren, meistens läuft es bei mir da auf XHTML und XML Namensräume zur eigenen Nutzung im DOM hinaus.

Was bitte ist an Validität heutzutage so schwierig? Oder was gibt es für sinnreiche Anwendungen, dagegen zu verstoßen?

Tim

[wahsaga]

hi,

Was bitte ist an Validität heutzutage so schwierig?

Du sprichst mir geradezu aus der Seele.
Was manchmal an Argumenten an den Haaren herbeigezogen wird, warum man keinen validen Code hätte erstellen können, ist oftmals geradezu abstrus.

Oder was gibt es für sinnreiche Anwendungen, dagegen zu verstoßen?

Auch da fallen mir - obwohl das als Argument "gegen Validität" noch am häufigsten gebracht wird - kaum realistische Beispiele ein ... wenn wir von ein paar proprietären CSS-Eigenschaften und ein paar CSS-Hacks mal absehen.

Auch immer wieder gerne mag ich "und wer zahlt mir diesen zusätzlichen Aufwand?" - sorry, da hat manch einer m.E. echt den falschen Job.

gruß,
wahsaga

[Robert Bienert]

Moin!

Auch immer wieder gerne mag ich "und wer zahlt mir diesen zusätzlichen Aufwand?" - sorry, da hat manch einer m.E. echt den falschen Job.

Was für Verträge macht man denn bzw. was für Code schreibt man normalerweise, dass man solche Fragen stellt bzw. stellen muss? Wenn ich rein semantisches HTML produziere, dass lediglich über CSS sein Layout erhält, spare ich viel Arbeit (=Aufwand) für Drucklayout, Mobiltelefon-Darstellung, Weiterverarbeitung, …

Viele Grüße,
Robert

[Cybaer]

Hi,

Validität wird hier immer dargestellt, als sei sie schwierig. Finde ich nicht. Finde ich eigentlich ganz und gar nicht.

Finde ich auch nicht.

Wie ich an anderer Stelle im Forum mal postete: Im Prinzip könnte auch 'n begabter Schimpanse ein valides Dokument hinbekommen.

Für jedes "grün" im Validator gibt es eine Banane. ;->

Es geht IMHO doch eher ums Prinzip.

Was bitte ist an Validität heutzutage so schwierig?

Man kann Paragraphenreiter sein (und das nicht aufgrund eines Gesetzes sondern nach gusto eine ggf. umstrittenen Vereinigung), oder auch seinen eigenen Verstand einschalten.

Oder was gibt es für sinnreiche Anwendungen, dagegen zu verstoßen?

Das möchtest Du doch bitte die Programmierer der HTML-Browser fragen, die allesamt
a) Elemente & Attribute eingebaut haben (und die nach wie vor fleißig tun - und sicher auch zukünftig tun werden), die zu keinem W3C-Standard gehören
c) diese E & A auch nicht (konsequent) abschalten, wenn man eine DTD angibt, in der diese E & A nicht enthalten sind (selbst nicht, wenn es diese Pseudo-DTD-Angabe mittels vordefinierter aber nicht ausgewerteter DOCTYPEs ist - zumindest nicht zielgerichtet ausgewerteter DOCTYPEs).

Gruß, Cybaer

[molily]

Hallo,

Was bitte ist an Validität heutzutage so schwierig?

Man kann Paragraphenreiter sein (und das nicht aufgrund eines Gesetzes sondern nach gusto eine ggf. umstrittenen Vereinigung), oder auch seinen eigenen Verstand einschalten.

Du sprichst in Rätseln.

<polemik>Generell scheint bei manchen ein Reflex anzuspringen, wenn sie irgendwelchen technischen Vereinbarungen folgen sollen: Plötzlich werden aus den ansonsten funktionierenden Bürgern mit verwaltetem Leben kleine Dissenter und Möchtegern-Abweichler, die gerade an dieser beknackten Stelle gegen halluzinierte Autoritäten aufbegehren und von Fremdbestimmung und Unterwürfigkeit faseln. »Validität? Brauche ich nicht, ich lasse mich nicht fernsteuern und kontrollieren, ich kann selbst denken!« Das ist ziemlich lachhaft und unfundiert.</>

Oder was gibt es für sinnreiche Anwendungen, dagegen zu verstoßen?

Das möchtest Du doch bitte die Programmierer der HTML-Browser fragen, die allesamt
a) Elemente & Attribute eingebaut haben, die zu keinem W3C-Standard gehören

Welche denn?

(Das letzte Mal, als wir die Frage hatten, wurden Schlaftabletten wie <nobr> usw. genannt. Kann den Thread leider nicht finden.)

(Du lenkst geschickt von Tims eigentliche Frage ab, deshalb nochmal: Angenommen es gibt solche Elemente und Attribute, was gibt es für sinnreiche Anwendungen für diese Elemente und Attribute und wie effektiv ist es, diese proprietären Sachen einzusetzen? Sprich, was hätte ich überhaupt davon, abzuweichen?)

(Es gibt z.B. einen Haufen proprietärer Event-Attribute im IE, die bei superspeziellen Rich Internet Applications nützlich sein können, wenn man sich denn auf den IE einschießen will. Eine Option für das breite Web sind sie nicht. Außerdem muss man in Zeiten von Unobtrusive JavaScript noch längst keinen invaliden HTML-Code schreiben. Wie ich auch schrieb, im Bereich JavaScript geht sowieso alles drunter und drüber. Aber im Bereich HTML/CSS?)

Mathias

[Cybaer]

Hi,

Was bitte ist an Validität heutzutage so schwierig?
Man kann Paragraphenreiter sein (und das nicht aufgrund eines Gesetzes sondern nach gusto eine ggf. umstrittenen Vereinigung), oder auch seinen eigenen Verstand einschalten.
Du sprichst in Rätseln.

Validität ist kein Selbstzweck. Ich mache seit über 10 Jahren Webseiten. Und auch wenn man etwas 10 Jahre lang falsch machen kann (OK, damals gab es nur semantischen Code und als Layoutmöglichkeit Hx, STRONG/B & IMG - man hatte ja gar nichts anderes ;)). Ich denke aber, ich weiß was ich tue. Und wenn ich eine Webseite mache, dann ist Validität als solche *kein* Kriterium für mich.

<polemik>Generell scheint bei manchen ein Reflex anzuspringen, wenn sie irgendwelchen technischen Vereinbarungen folgen sollen: (...) »Validität? Brauche ich nicht, ich lasse mich nicht fernsteuern und kontrollieren, ich kann selbst denken!« Das ist ziemlich lachhaft und unfundiert.</>

Redest Du mit mir? Ich bitte dich!

Ich code Webseiten auch HTML-4-strict-valide, mit semantischem Markup und reinem CSS-Layout (ohne Frames und/oder TABLE-Layout). Habe ich gemacht, mache ich, werde ich zukünftig auch machen.

Ich code aber auch wohlgeformte Webseiten auf Basis von HTML 4. D.h., ich beachte den W3C-Standard bezügl. z.B. des Umstands, welche Tags welche Kinder haben dürfen. Ansonsten nutze ich aber ggf. auch proprietäre Tags & Attribute, Frames, Tabellenlayout als Basis und immer auch CSS.

Mit anderen Worten:
1. Ich mache Webseiten so, wie ich es (unter Berücksichtigung verschiedenster Anforderungen) im Einzelfall als sinnvoll erachte.
2. Der Umstand, daß bei der Validierung einer meiner Seite ein fehlerfreies Ergebnis herauskommt, ist *nicht* Bestandteil meines Entscheidungsprozesses. Für den Anwender ist ein "Validitätssiegel" absolut irrelevant. Für ihn ist *einzig* eine gut nutzbare, fehlerfreie Seite von Relevanz.
3. Ich weiß, was ich tue, und kann meine Abweichungen von irgendwelchen Normen in jedem Einzelfall begründen. Ich weiß ferner, daß meine Abweichungen von der Norm in fehlerfreien Norm-Browsern keine Nachteile hervorrufen. Ich weiß aber auch, daß es ohnehin keinen Browser gibt, der wirklich und ausschließlich standardkonform ist.

(Das letzte Mal, als wir die Frage hatten, wurden Schlaftabletten wie <nobr> usw. genannt. Kann den Thread leider nicht finden.)

Wenn ich einen Zeilenumbruch partout auch in älteren Browsern verhindern möchte, dann habe ich auch kein Problem, NOBR oder NOWRAP *zusätzlich* zu verwenden - zusätzlich zu white-space:nowrap, welches ich aber *auf jeden Fall* verwende.

Andere Beispiele: s. meine Parallelantwort auf dein anderes Posting ...

Angenommen es gibt solche Elemente und Attribute, was gibt es für sinnreiche Anwendungen für diese Elemente und Attribute und wie effektiv ist es, diese proprietären Sachen einzusetzen? Sprich, was hätte ich überhaupt davon, abzuweichen?)

Ich habe davon gar nichts. Der Anwender hat davon ggf. etwas, falls er einen Browser verwendet, der diese proprietären Elemente unterstützt, oder, mangels Updatefähigkeit, gar darauf angewiesen ist (dann habe allerdings auch ich etwas davon, da das Layout der Website trotz der Browsermängel, eher meiner Intention entspricht).

Ansonsten: Auch ich bin durchaus ein solcher Anwender, spätestens dann, wenn ich mal eben mit dem Browser des Festplattenreceivers surfe, anstatt aufzustehen und den PC anzuschmeißen ...

(Es gibt z.B. einen Haufen proprietärer Event-Attribute im IE, die bei superspeziellen Rich Internet Applications nützlich sein können, wenn man sich denn auf den IE einschießen will. Eine Option für das breite Web sind sie nicht.

Generell würde ich sagen: Wenn ich eine Vorstellung so umsetzen kann, daß sie alle nutzen können, dann mache ich es so. Wenn ich vor der Entscheidung stehe, eine Vorstellung entweder gar nicht umzusetzen oder wenigstens den Nutzern mit Browser XYZ zugänglich zu machen, dann mache ich ggf. auch das - allerdings so, daß der Rest nicht darunter leiden muß ...

Gruß, Cybaer

[Swen Wacker]

Moin,

ich möchte mal deutlich machen, wo sich, glaube ich, unsere Denkansätze unterscheiden.

Für mich sind Deine Aussagen nämlich zum einen manchmal ein Widerspruch:

2. ....  Für den Anwender ist ein "Validitätssiegel" absolut irrelevant. Für ihn ist *einzig* eine gut nutzbare, fehlerfreie Seite von Relevanz.

... zum anderen stimmt dann ab und an das Wertbeziehunggefüge in meinen Augen nicht:

3. Ich weiß ferner, daß meine Abweichungen von der Norm in fehlerfreien Norm-Browsern keine Nachteile hervorrufen. Ich weiß aber auch, daß es ohnehin keinen Browser gibt, der wirklich und ausschließlich standardkonform ist.

Zu 2.
Eine vermeintlich(!) valide Seite kann eine Scheiß-HTML-Seite und immer-zweimal-mehr-Scheiß-Web-Seite sein. Jedes vierte Posting von Hajo aka Cheatah beschäftigt sich mit der falschen Zuordnung von Inhalt zu Markup. Validitor-valide allein genügt nicht, die Seite sollte bitte auch - ich nenn das jetzt mal so - "web-konform" sein. Selbst die Spec weiß um die nicht ausreichende Aussage "valide". Insoweit ist die Aussage des Satzes 1 in gewisser Hinsicht noch okay - auch wenn ich glaube, dass Du es anders gemeint hast.
Der zweite Satz ist dann aber in meinen Augen zu kurzfristig gedacht. Eine nicht valide Seite (und das kann eben mehr sein als ein Validator-TÜV-Plakete) kann - wenn ich den Spirit der Idee des Webs inhaliere, so wie ich hier angedeutet habe - nicht auf Dauer eine "gut nutzbare, fehlerfreie Seite" sein. Das mag für manche Aspekte und Betrachtungsebenen stimmen. Der Teamgeist des Webs verlangt jedoch ein wenig mehr. Bevor jetzt jemand von auf Spatzen schießenden Kanonen erwidert: ich sagte ja schon in dem eben verlinkten Statement, dass das www sich freundlicherweise von Quertreibern so schnell nicht kaputt machen lässt und diese andersherum nicht mit einem Nichterreichbarkeitsbann belegt. Man sollte sich jedoch im Klaren darüber sein, dass permanentes und intensiv begangenes Mißachten von Regeln das Netz irgendwann (faktisch wie semantisch) in Teilnetze auseinanderfallen lassen kann. Es gilt also auch im Web die Grundvermutung: Wehret den Anfängen: wenn wir anfangen, schon im kleinen falsch (oder zu kleinlich) zu denken, dann laufen wir Gefahr, wieder Stabhochspringer zu werden, der die auf Weltrekordhöhe liegende Latte unterspringt und sich anschließend brüstet, er hätte sie ja nicht immerhin nicht gerissen :-).

Das gilt natürlich nicht allein für die Webseitenhersteller, sondern auch für alle anderen Beteiligten (Browserhersteller, Nutzer, Serverbetreiber ...) auch. Und das führt mich zum zweiten Punkt, nämlich deiner Aussauge von oben, die ich hier noch mal wiederhole, da der Text nun doch etwas länger wurde - und ich kein Bock zum kürzen habe :-)

3. Ich weiß ferner, daß meine Abweichungen von der Norm in fehlerfreien Norm-Browsern keine Nachteile hervorrufen. Ich weiß aber auch, daß es ohnehin keinen Browser gibt, der wirklich und ausschließlich standardkonform ist.

Standardkonform ist für mich keine Beziehung allein zwischen Browser und HTML-Code. Webkonform wäre wahrscheinlich ein Wort, dass mein Gefühl besser zum Ausdruck bringen würde. Eine Seite sollte - und jede Seite kann das auch, wenn sie will! - die wunderschöne Idee (besser noch im Buch von TBL nachzulesen), die hinter all dem steht, wiederspiegeln.

Den Satz "Die Energie des Verstehens", der über diesem Raum hier thront, drückt das auch schön aus.

Viele Grüße

Swen Wacker

[Gunnar Bittersmann]

Hello out there!

Eine nicht valide Seite (und das kann eben mehr sein als ein Validator-TÜV-Plakete) kann - wenn ich den Spirit der Idee des Webs inhaliere, so wie ich hier angedeutet habe - nicht auf Dauer eine "gut nutzbare, fehlerfreie Seite" sein.

Warum nicht?

„# Trifft ein Benutzerprogramm auf ein Element, das es nicht erkennt, sollte es versuchen, den Inhalt des Elements darzustellen.

Trifft ein Benutzerprogramm auf ein Attribut, das es nicht erkennt, sollte es die gesamte Attributangabe ignorieren (d.h., das Attribut und dessen Wert).“ [HTML401 §B.1]

Wenn es für einige Nutzer sinnvoll ist, proprietäre Elemente/Attribute zu verwenden*, und es anderen nicht schadet, warum eigentlich nicht?

Nutzer interessieren sich für die Nutzbarkeit einer Seite, nicht für die Validität des Quelltextes. Da kann ich Cybaers Gedanken durchaus nachvollziehen.

See ya up the road,
Gunnar

* Falls es einen solchen Fall gibt. Man sollte ihn nicht künstlich hervorrufen.

[Swen Wacker]

Moin,

Hello out there!

Eine nicht valide Seite (und das kann eben mehr sein als ein Validator-TÜV-Plakete) kann - wenn ich den Spirit der Idee des Webs inhaliere, so wie ich hier angedeutet habe - nicht auf Dauer eine "gut nutzbare, fehlerfreie Seite" sein.

„# Trifft ein[...Auszüge aus der HTML-Spec...]

Ich hatte mich bemüht deutlich zu machen, dass Validität (oder besser: Konformität) nicht ausschließlich an der Spec festgemacht werden bzw. eine korrekte Syntax allein noch kein valides Dokument ergibt. Das fängt schon damit an, dass es Festlegungen in der Spec gibt, die nicht von maschinellen Validatoren überprüft werden können und endet irgendwo in dem "mehr" oder "Spirit", den ich ins www hineininterpretiert habe.

Wenn es für einige Nutzer sinnvoll ist, proprietäre Elemente/Attribute zu verwenden*, und es anderen nicht schadet, warum eigentlich nicht?

Ich mache jetzt keine Gegenrede. Ich glaube nämlich nicht, das wir weit auseinander sind. Ich versuche es nur mal anders und stelle den Modus "missionieren" ein :-)
Vor nicht mal 16 Jahren kam ein von den meisten seiner Zeitgenossen wahrscheinlich für naiv gehaltener Technik-Spinner namens Tim Berners-Lee auf die Idee, man könnte doch mal gucken, ob es möglich ist, die unterschiedlichsten, zudem noch überall verteilt liegenden Informationsquellen hard- und softwareunabhängig in einer (und dann auch noch interaktiven) Benutzerschnittstelle präsentieren zu können. Man muss sich einfach mal klar machen, dass jeder, der so was vor 15, 16 Jahren vorgeschlagen hätte, für komplett übergeschnappt erklärt worden wäre. Wenn ihm denn überhaupt eine nennenswerte Menge zugehört hätte. Genausogut hätte namlich einer vorschlagen können, dass alle Welt ab übermorgen eine Sprache spricht. Zu der Zeit hielten viele es nämlich noch für einen nicht mehr zu übertrumpfenden Höhepunkt der Standardisierung der Technik, dass man mit Telefonen unterschiedlicher Hersteller weltweit miteinander sprechen konnte! Und dann kam das WWW. Und damit tat sich ein Welt auf, die nicht mal Jules Verne hätte erahnen können. Eine Welt, in der die Hypertext-Spinnereien eines Ted Nelson nicht mal im PM-Magazin ernsthaft diskutiert worden wären, wurde greifbar.

Vielleicht muss man sich diesen gigantischen Schritt, der vor nur so wenigen Jahren vollzogen wurde, immer wieder vor Augen führen, bevor man darüber redet, ob man proprietäres im WWW machen möchte. Das Web wurde erschaffen, um genau das zu überwinden! Ich schäme mich nicht dafür, bei der Lektüre des Buches von TBL über die Erfindungs des Web an irgendeinere Stelle vor Freude geheult zu haben; einfach, weil da einer war, der dieses geniale Instrument erfunden hat. Und dann auch noch genial einfach. Und genial² wurde es sogleich erschaffen, dass es proprietäre Ausflüge überlebt. Aber das heißt eben noch lange nicht, dass proprietär im WWW damit völlig okay ist. Techniken, die das auf Universalität angelegte des Web einschränken können, sind erstmal böse(R). Und selbst wenn sie keinen Schaden anrichten werden sie nie gut(R) sein können. Gut ist nur, dass gute WWW das böse proprietäre in Maßen ertragen kann.

Diesen oder ähnlich Denkansätze haben diejenigen, die das Web mitgestalten. Die, die es nur be- oder ausnutzen, müssen sicher das, was sich hinter dem Vorhang abspielt, nicht genau verstehen. Aber sie sollten wissen, was für ein filigranes Instrument sie benutzen und dürfen deshalb immer wieder gern darauf hingewiesen werden, warum Universalität was Tolles ist. Und dann werden sie auch Verständnis für Validität haben. Web-konforme Seiten sind nämlich keine langweiligen Bleiwüsten die nur für pickelige 16-Jährige. Sie sind gelebter Fortschritt. Universalität ist kein Regelwerk, das man beiseite schieben kann sondern eine Grundeinstellung, die man hat oder nicht.

Nutzer interessieren sich für die Nutzbarkeit einer Seite, nicht für die Validität des Quelltextes. Da kann ich Cybaers Gedanken durchaus nachvollziehen.

Ich auch, wenn ich nur bis zur nächsten Ecke denken soll. Danach - und ich bis sicher, dass Cybaer das in innersten seines Herzens nicht anders sieht :-) - kann es eng werden mit einer Grundeinstellung, die allein das  vermeintliches Desinteresse einzelner Teilnehmer hochleben lässt und sich deshalb - bewusst komplett übertrieben: - auf ein "nach mir die Sintflut" reduzieren lässt.

Man merkt, die Diskussion ist weit weg von praktischen Leben an irgendeinen Dreiländereck Soziologie Philosophie und Technik. Aber manchmal ist es wichtig, sich der Wurzeln einer Idee zu besinnen und dann nachhaltiger mit ihr umzugehen.

Viele Grüße

Swen Wacker

[Cybaer]

Hi,

Vielleicht muss man sich diesen gigantischen Schritt, der vor nur so wenigen Jahren vollzogen wurde, immer wieder vor Augen führen, bevor man darüber redet, ob man proprietäres im WWW machen möchte.

Du hast "dummerweise" etwas ganz wichtiges vergessen: *Jeder*, insbes. nicht mit den Feinheiten der Informatik gesegnete Professoren (das Web war ja erstmal zum wissenschaftlichen Informationsaustausch erdacht) sollte in der Lage sein, diese Markupsprache zu benutzen. *Deswegen* wurde bewußt auf den sonst üblichen Formalismus (s. SGML) verzichtet. Deswegen war HTML so vergleichsweise einfach gehalten.Deswegen ist

  
<title>Meine Forschungsarbeit</title>  
Meine Forschungsarbeit richtet sich an ...  

ein gültiges HTML-Dokument. Deswegen sind viele (End-)Tags (sofern überhaupt existent) optional.

Und daß HTML-Browser ihnen unbekannte Tags & Attribute ignorieren sollen, ist *unverzichtbarer* Bestandteil dieser Philosophie, die ja eben, richtigerweise bemerkt, Informationen möglichst systemübergreifend vermitteln soll - auch zw. unterschiedlichen Browser-Versionen (Stichwort: Abwärtskompatibilität)

Gruß, Cybaer

[Swen Wacker]

Moin,

Vielleicht muss man sich diesen gigantischen Schritt, der vor nur so wenigen Jahren vollzogen wurde, immer wieder vor Augen führen, bevor man darüber redet, ob man proprietäres im WWW machen möchte.

[...] *Jeder*, insbes. nicht mit den Feinheiten der Informatik gesegnete Professoren (das Web war ja erstmal zum wissenschaftlichen Informationsaustausch erdacht) sollte in der Lage sein, diese Markupsprache zu benutzen. *Deswegen* wurde bewußt auf den sonst üblichen Formalismus (s. SGML) verzichtet.[...]

Das rechtfertigt keine proprietären Bestandteile im Quellcode (darum ging es ja in dem Absatz, den Du von mir zitiertest). Und es ist in meinen Augen auch keine Rechtfertigung für bewusst oder z.B. aus Faulheit herbeigeführte Regelverstöße _ohne_ nachvollziehbare Berechtigung.

Richtig, und da hättest Du meine breiteste Unterstützung gegen Regel-Korinthenkacker, ist Dein Lob auf die Robustheit und - jedenfalls anfängliche - "Übersichtlichkeit" der ersten HTML-Specs. Dieses Feature (Übersichtlichkeit) haben wir aber schon längst hinter uns gelassen. Das endete mit Netscape 2.0, der das WWW bunt machte.
Historisch gesehen, fällt mir dabei gerade ein, sollte jeder, der sich jede noch so kleine von Standard abweichende Darstellung des IE aufregt, auch vergegenwärtigen, dass Nicht-Beachtung der W3C-Regeln zur Entstehungszeit des Produktes eher ein Feature denn ein Bug gewesen ist. Mittlerweile haben sich aber alle Marktteilnehmern, so scheint mir, die Spielregeln des WWW mehr verinnerlicht. Auch der IE marschiert mittlerweile in die "richtige" Richtung. Angesichts seiner langen Zeit als faktischer Monopolist hätte Microsoft sich auch anders verhalten können.
Mit der zunehmenden Komplexität der Sprache HTML stieg aber auch die Anforderung an Regelkonformität. Browser kamen "damals" in den 90er Jahren mit handelsüblichen Glaskugeln aus. Wollten sie nur den damaligen Stand des stillschweigenden Korrigierens oder drüber-hinweg-sehens halten, müssten sie allein angesichts des Umfang von HTML und CSS mittlerweile schon mit planetengroßen Glaskugeln daherkommen.
Und damit bin ich dann wieder bei deinen Argument :-) Geblieben und sicher erhaltenswert ist hingegen die Robustheit der Browser bei Flüchtigkeitsfehlern oder anderen Nachlässigkeiten. Aber darum geht es hier eben nicht.

Viele Grüße

Swen Wacker

[Cybaer]

Hi,

um es von meiner Seite aus zu beenden:

Mit der zunehmenden Komplexität der Sprache HTML stieg aber auch die Anforderung an Regelkonformität.

Keine Frage.

Und damit bin ich dann wieder bei deinen Argument :-) Geblieben und sicher erhaltenswert ist hingegen die Robustheit der Browser bei Flüchtigkeitsfehlern oder anderen Nachlässigkeiten. Aber darum geht es hier eben nicht.

Nein, davon rede *ich* *nicht*! Darunter fällt für mich, daß Browser (manche mehr, manche weniger) fehlertolerant sind (z.B. unerlaubte Tag-Verschachtelungen erlauben).

Ich rede von einem Verhalten, welches implizit zu den Grundregeln von HTML gehört: Ignoriere unbekannte Tags & Attribute.

Inhaltlich wie fomalistisch ein gewaltiger Unterschied.

Gruß, Cybaer

[Tim Tepaße]

Hallo Cybaer,

Das möchtest Du doch bitte die Programmierer der HTML-Browser fragen, die allesamt
a) Elemente & Attribute eingebaut haben (und die nach wie vor fleißig tun - und sicher auch zukünftig tun werden), die zu keinem W3C-Standard gehören
c) diese E & A auch nicht (konsequent) abschalten, wenn man eine DTD angibt (...)

Nein. Ich frage explizit aus Sicht von Autoren von Webseiten. Und aus Autorensicht ist man daran interessiert, Webseiten zu schreiben, die in der Mehrheit der Browser funktionieren. Dass die bestehenden Standards Lücken haben, ist mir natürlich auch klar.

Nur: Was gibt es derzeit für browserübergreifend existierende HTML Elemente und Attribute, die es schön wäre benutzen zu können und an deren Nutzung man nur durch das formale Argument der Validität gehindert wird? Beispiele bitte.

(Und bitte nicht wie immer die WHAT WG anführen. Zum einen empfindet diese sich selbst als Vorstufe des W3C, WF2 ist ja schon zu Submission eingereicht, dann sind diese Weiterentwicklungen nur teilweise in einem bis zwei Browser implementiert - das nenne ich noch nicht browserübergreifend und zuguterletzt befinden sich die Specs noch sehr im Fluss.)

Tim

[Cybaer]

Hi,

Ich frage explizit aus Sicht von Autoren von Webseiten. Und aus Autorensicht ist man daran interessiert, Webseiten zu schreiben, die in der Mehrheit der Browser funktionieren.

Ich bin Webautor und daran interessiert, daß meine Seiten in möglichst vielen Browsern funktionieren.

Welche Browser (momentan) die Mehrheit bilden, ist nicht Bestandteil meines Denkschematas.

Beispiele bitte.

S. Antworten auf Molily.

das nenne ich noch nicht browserübergreifend

Das ein verwendetes einzelnes Element (egal ob HTML, CSS oder JS betreffend) browserübergreifend funktionieren muß, ist nicht Bestandteil meines Denkschematas. Vielmehr möchte ich (unter optimalen Umständen) möglichst viel für jeden Browser "herausholen". Und wenn ich für Browser X etwas implementiere und für Y etwas anderes und Z (und der W3C-Standard) beides nicht kennt aber auch keine Probleme hat, wenn ich es verwende, dann mache ich das und einige mich nicht auf den kleinsten gemeinsamen (Standard-)Nenner ...

Gruß, Cybaer

[at]

Hallo.

Bestandteil meines Denkschematas.

Könntest du mich da bitte heraus lassen.
MfG, at

[Cybaer]

Hi,

Bestandteil meines Denkschematas.
Könntest du mich da bitte heraus lassen.

Oh je - aber gerne! =;-)

Gruß, Cybaer

[at]

Hallo.

Das möchtest Du doch bitte die Programmierer der HTML-Browser fragen, die allesamt
a) Elemente & Attribute eingebaut haben (und die nach wie vor fleißig tun - und sicher auch zukünftig tun werden), die zu keinem W3C-Standard gehören
c) diese E & A auch nicht (konsequent) abschalten, wenn man eine DTD angibt, in der diese E & A nicht enthalten sind (selbst nicht, wenn es diese Pseudo-DTD-Angabe mittels vordefinierter aber nicht ausgewerteter DOCTYPEs ist - zumindest nicht zielgerichtet ausgewerteter DOCTYPEs).

Mich persönlich hätte hier Punkt b) interessiert, der aber vermutlich aufgrund seiner Stichhaltigkeit nicht in die Aufzählung gepasst hat.
MfG, at

[molily]

Hallo,

Geht es wirklich darum, dass Validität schwierig ist oder dass man sich damit in konkreter technischer Hinsicht einschränkt?

Das Ursprungsposting zielte in eine andere Richtung: »Ich lass mir doch von so Hanseln wie dem W3C nichts vorschreiben!«. Dieses rein formale »Argument« scheint mir genauso verbreitet wie bar jeder Vernunft. Wenn von »sinnlosen Einschränkungen der tatsächlich verfügbaren Möglichkeiten« die Rede ist, so scheint mir das auch rein formal und inhaltlich hohl. Im Grunde ist es dieser Gemeinplatz: Wir wissen alle, Regeln und Vorschriften schränken uns nur ein... Das Beispiel dann war ein Griff ins Klo. Insofern ist die kritische Nachfrage natürlich berechtigt, ich fürchte aber, da kommt keine inhaltliche Unterfütterung.

Mathias

[Manuel B.]

Hi,

ich habe in den letzten Tagen mit einem Kunden von mir Diskutiert, dass man sich an die W3C Richtlinien halten sollte bzw. dass man danach auch programmiert.

Da ich keine einzige Programmiersprache kenne, für die das W3C Richtlinien veröffentlich, stellen sich mir sowieso einige Fragen über die Kompentenz des Menschen, der so einen Thread aufmacht.

[Ashura]

Hallo Manuel.

Da ich keine einzige Programmiersprache kenne, für die das W3C Richtlinien veröffentlich, stellen sich mir sowieso einige Fragen über die Kompentenz des Menschen, der so einen Thread aufmacht.

Hm, JavaScript sagt dir nichts?

(Ich würde sogar XSLT dazu zählen, kann es aber mangels Kenntnis nicht einschätzen.)

Einen schönen Donnerstag noch.

Gruß, Ashura

[Manuel B.]

Hi Ashura,

Hm, JavaScript sagt dir nichts?

Ok, wieder was gelernt, ich wusst nicht, dass das W3C auch für Javascript "zuständig" ist. Aber ich lerne ja immer gerne dazu ;)

(Ich würde sogar XSLT dazu zählen, kann es aber mangels Kenntnis nicht einschätzen.)

Deshalb auch meine Aussage, das ich keine "kenne". Trotzdem sprach der OP von Programmiersprachen, wobei er IMO HTML&Co ausschliesst. Aber ich hör jetzt auf Erbsen zu zählen, über die Qualität von jUnits Beiträgen kan sich mittlerweile sowieso jeder welbst ein Bild machen ;)

[molily]

Hallo,

Ok, wieder was gelernt, ich wusst nicht, dass das W3C auch für Javascript "zuständig" ist.

Ist es auch nicht. Das W3C ist für das DOM zuständig, nicht mehr und nicht weniger. Natürlich stimmt es, dass in dem Bereich, den man üblicherweise JavaScript nennt, das DOM die entscheidene Technik ist.

Für JavaScript an sich ist niemand zuständig, weil für »JavaScript« keine greifbare technische Spezifikation existiert (außer Netscapes JavaScript aus der Prä-DOM-Ära). Siehe dazu JavaScript und Webstandards.

Mathias

[Cybaer]

Hi,

Ok, wieder was gelernt, ich wusst nicht, dass das W3C auch für Javascript "zuständig" ist.

Zuständig ist die ECMA. Und "standardisiertes JavaScript" heißt dann ECMAscript.

Gruß, Cybaer

[molily]

Hallo,

Ok, wieder was gelernt, ich wusst nicht, dass das W3C auch für Javascript "zuständig" ist.

Zuständig ist die ECMA. Und "standardisiertes JavaScript" heißt dann ECMAscript.

ECMAScript ist nicht standardisiertes JavaScript. (Beziehungsweise nur zum Teil.)

Unter JavaScript bezeichnet natürlich eine konforme Anwendung von ECMAScript. Aber wenn man diese Anwendung mit seinen Host-Objekten wie window, frames, document, history, location, Image usw. standardisieren würde, dann käme noch einmal etwas anderes heraus als ECMAScript. ECMAScript würde die Grundlagen bereitstellen und das »standardisierte JavaScript« diese Host-Objekte.

Bis heute existiert kein derartiges »standardisiertes JavaScript«. Es ist auch die Frage, ob man traditionelles Event-Handling sowie Eigenschaften und Methoden auf Dokument- bzw. Knotenebene noch standardisieren sollte. Breit genutzt werden sie auf jeden Fall, und überholt sind sie durch das DOM nur teilweise.

Mathias

[Swen Wacker]

Moin,

Da ich keine einzige Programmiersprache kenne, für die das W3C Richtlinien veröffentlich,
Hm, JavaScript sagt dir nichts?

Kann man das so sagen? DOM ist doch eher eine Schnittstelle ("a platform- and language-neutral interface that allows programs and scripts..") denn eine Sprache.

Viele Grüße

Swen Wacker

[Ashura]

Hallo Swen.

Da ich keine einzige Programmiersprache kenne, für die das W3C Richtlinien veröffentlich,
Hm, JavaScript sagt dir nichts?

Kann man das so sagen? DOM ist doch eher eine Schnittstelle ("a platform- and language-neutral interface that allows programs and scripts..") denn eine Sprache.

Richtig. Das ändert aber nichts daran, dass das W3C Richtlinien (eben DOM) für JS veröffentlicht. (Dass JavaScript gleich DOM ist, wollte ich natürlich nicht implizieren, falls dies den Anschein erweckt haben sollte.)

Einen schönen Donnerstag noch.

Gruß, Ashura

[Swen Wacker]

Moin,

Dass JavaScript gleich DOM ist, wollte ich natürlich nicht implizieren, falls dies den Anschein erweckt haben sollte.

Man konnte aber so verstehen, wie auch Manuels "Ok, wieder was gelernt, ich wusst nicht, dass das W3C auch für Javascript "zuständig" ist." nahelegt. Deshalb habe ich sicherheitshalber nachgefragt.

Viele Grüße

Swen Wacker