Preis für Homepage und Überzeugungsarbeit für Validität

[Anja]

Hallo an alle,

ein Bekannter von mir hat einen Handyladen, der eigentlich ganz gut läuft. Er möchte nun seine Geschäftstätigkeit auf Großhandel erweitern und hat mich nun gefragt, ob ich ihm den Internetauftritt gestalten kann. Natürlich muss es so günstig wie möglich sein.

Er wird mir den Auftrag nicht nur erteilen weil ich ein Bekannter von ihm bin. Er möchte im Groben einige Info-Seiten über die Firma haben, einen Shop (steht noch nicht fest ob auf ein fertiges Produkt zurückgegriffen wird oder individuell programmiert wird) und er möchte, dass online Verträge abgeschlossen werden können (wie bei www.teltex.de).

Ich habe nun folgendes Problem und hoffe hier einige Lösungsansätze zu finden.

• wie viel kann ich ihm denn ungefähr verlangen (erstmal ohne Shop und dann, sagen wir mal mit Shop wenn es nur um die Anpassung eines Produktes geht)?
  Natürlich ist es schwer aufgrund dieser spärlichen Informationen eine Schätzung abzugeben aber vielleicht kennt Ihr ja Richtwerte.

• zweite Frage: ich lege viel Wert auf valide Seiten (HTML u. CSS). Es gibt allerdings viele "Möchtegern-Profis" die nur einen Wert auf Aussehen legen.

Da der Bekannte keine Ahnung von Web-Auftritten hat wird er nur das beurteilen was er am Ende sieht. Daher muss ich ihn überzeugen, dass er bei der Auswahl des Auftragnehmers auch Wert auf valide Seiten legen soll. Es ist ja schliesslich auch so, dass ein Anbieter, der keinen Wert auf Validierung legt, viel günstiger sein kann, da er unter Umständen "Pfusch" abliefert der nur im IE läuft.

Nun bräuchte ich ein paar schlagende Argumente um ihn zu überzeugen dass Validierung wichtig ist. Natürlich wird ihn das nur jucken wenn er für sich Kostenersparnisse sieht.

Für Eure Hilfe wäre ich überaus dankbar.
Gruss
Anja

[Cheatah]

Hi,

• wie viel kann ich ihm denn ungefähr verlangen (erstmal ohne Shop und dann, sagen wir mal mit Shop wenn es nur um die Anpassung eines Produktes geht)?

über die Problematik dieser Frage sowie Hinweise auf mögliche Antworten siehe bitte Archiv.

Nun bräuchte ich ein paar schlagende Argumente um ihn zu überzeugen dass Validierung wichtig ist.

Jeder "Depp" - letztlich inklusive ihm - kann Seiten erzeugen, die auf zumindest einem System vernünftig aussehen. Um solche zu bauen, die auf _beliebigen_ Systemen einwandfrei funktionieren _und_ jeweils bestmögliches Aussehen haben, muss man die Technik im Hintergrund optimal gestalten. Für ersteres braucht man niemanden zu bezahlen, Schrott kriegt man selbst hin; wenn man also Geld bezahlt, sollte es jemand sein, der letzteres hinbekommt.

Natürlich wird ihn das nur jucken wenn er für sich Kostenersparnisse sieht.

Wer einen Schrank zusammenstückelt, der nur deswegen hält, weil nur das drin ist, was man vorher schon wusste,[1] muss sich nicht wundern, wenn es Probleme gibt, sowie man etwas anderes reintut. Das Ding dann zu reparieren wird zu einem verdammt hässlichen Flickwerk führen. Hätte man von Anfang an einen Tischler beauftragt, würde der Schrank gut aussehen, gerade stehen, und man könnte reintun was man will.

Auch Homepage-Bau ist ein Handwerk. Man kann es verstehen, oder man kann keinen Dunst davon haben. Der Unterschied besteht - wie überall - darin, dass erstere preiswerte[2] Arbeit abliefern, letztere aber billige.

Cheatah

[1] Oder weil er in der Ecke steht und somit von zwei Wänden gehalten wird.
[2] Im wörtlichen Sinne: Sie ist ihren Preis wert.

[Anja]

Hi,

über die Problematik dieser Frage sowie Hinweise auf mögliche Antworten siehe bitte Archiv.

Ich hab im Archiv bereits nachgeschaut, aber nichts sinnvolles gefunden.

Ansonsten wirklich gute Argumente. Das Beispiel gefällt mir gut, so kann ich es ihm besser veranschaulichen.

Danke

[Andreas-Lindig]

Hallo Cheatah,

Hätte man von Anfang an einen Tischler beauftragt, würde der Schrank gut aussehen, gerade stehen, und man könnte reintun was man will.

...sofern der Tischler sein Handwerk versteht. Ich glaube, du hast ein etwas rosiges Bild vom Handwerk.

Gruß, Andreas

[Cheatah]

Hi again,

... und gerade entdecke ich [pref:t=70996&m=408531], welches zum Thema passt.

Cheatah

[Thomas W.]

Hallo,

... und gerade entdecke ich [pref:t=70996&m=408531], welches zum Thema passt.

Den Preis fuer (die dort erwaehnte) SGI Onyx findest Du unter  http://www.sgi.de/products/visualization/onyx/350/ (suche nach "Euro"). Ob er solche Kunden von vornherein ausschliessen moechte, muss er selber wissen.

Gruss
Thomas

[Nina]

Hallo Anja,

• wie viel kann ich ihm denn ungefähr verlangen (erstmal ohne Shop und dann, sagen wir mal mit Shop wenn es nur um die Anpassung eines Produktes geht)?

welches produkt möchtest du da verwenden?

• zweite Frage: ich lege viel Wert auf valide Seiten (HTML u. CSS). Es gibt allerdings viele "Möchtegern-Profis" die nur einen Wert auf Aussehen legen.

DAs stimmt.

Nun bräuchte ich ein paar schlagende Argumente um ihn zu überzeugen dass Validierung wichtig ist. Natürlich wird ihn das nur jucken wenn er für sich Kostenersparnisse sieht.

Die Seiten werden wartbarer, sie werden performanter da weniger Fehlerkorrekturen der Browser notwendig sind, man steht für zukünftige Browserversionen auf der sicheren Seite.
Das ist das einzige was mir spontan einfällt.

Gruss
Nina

[at]

Hallo.

Nun bräuchte ich ein paar schlagende Argumente um ihn zu überzeugen dass Validierung wichtig ist. Natürlich wird ihn das nur jucken wenn er für sich Kostenersparnisse sieht.

Die Seiten werden wartbarer, sie werden performanter da weniger Fehlerkorrekturen der Browser notwendig sind, man steht für zukünftige Browserversionen auf der sicheren Seite.
Das ist das einzige was mir spontan einfällt.

Dann erweitere dein Wissen doch ein wenig im Archiv. Dann findest du etwa Informationen darüber, inwiefern Validierung zum Erzielen eines guten Suchmaschinen-Rankings hilreich ist.
MfG, at

[Tom]

Hello,

ein Bekannter von mir hat einen Handyladen, der eigentlich ganz gut läuft. Er möchte nun seine Geschäftstätigkeit auf Großhandel erweitern und hat mich nun gefragt, ob ich ihm den Internetauftritt gestalten kann. Natürlich muss es so günstig wie möglich sein.

Ich verweise da mal auf [pref:t=70821&m=407459]

Da wurde das Thema schon einmal durchgekaut ;-)

Liebe Grüße aus http://www.braunschweig.de

Tom

[Chräcker Heller]

Hallo,

Nun bräuchte ich ein paar schlagende Argumente um ihn zu
überzeugen dass Validierung wichtig ist.

ich weiß nicht genau, warum man einem Kunden das erklären muß? Entweder wir als Handwerker meinen, das es wichtig ist, oder eben nicht. "Wir beide" glauben, das es wichtig ist und liefern nur valide Seiten ab. Validität trägt zur Gesamtqualität bei.

Der Kunde darf ein Produkt erwarten, das wir nach unserem besten Können erarbeitet haben und das die höchste Qualiät beinhaltet, die wir in der Lage sind, abzuliefern. Mehr muß er doch gar nicht wissen. Das das Produkt vor dem Vorhang gut ist, das kann er testen. ("kucken mit die Augen" ,-)) Das das Produkt auch richtig gut ist, kann er an der Resonanz seiner Kunden ablesen. Das das Produkt auch hinter den kulissen gut erarbeitet ist, davon darf er doch bei Dir sicherlich ausgehen, oder? Wovon also möchtest Du ihn überzeugen?

Wenn andere nun besser aussehende Seiten basteln, dann liegt das doch nicht daran, das sie nicht valide arbeiten. Das würde ja bedeutet, das man anständige Seite nicht valide erstellen kann, und das kanns doch nicht sein, oder? ("Ja, ich kann auch so schöne Seiten erstellen, die wären dann aber nicht valide" ist doch kein ausprechbarer Satz....)

Ich persönlich belästige meine Kunden nicht mit solchen für ihn in seinem Geschäftsbetrieb eher uninteresanten Dingen. Vor dem Vorhang wird die Seite so gut wie ich es gerade kann, hinter den Kulissen eben auch. Weniger gibts nicht. Ich sag dem zufriedenen Kunden doch nicht stolz geschwelgt: "und hab ich auch schön valide gemacht" - das sollte doch Standard sein... hätte er bei mir weniger erwarten sollen?

Chräcker (dessen Seiten lange nicht alle valide sind, geschenkt geschenkt ;-)

[Anja]

ich weiß nicht genau, warum man einem Kunden das erklären muß? Entweder wir als Handwerker meinen, das es wichtig ist, oder eben nicht. "Wir beide" glauben, das es wichtig ist und liefern nur valide Seiten ab. Validität trägt zur Gesamtqualität bei.

Stimme ich voll und ganz zu. Es kann ja aber sein, dass er sich von einem anderen Anbieter blenden lässt der meinetwegen vor dem Vorhang genauso schöne oder weniger schöne Seiten erstellt wie ich, es jedoch viel günstiger anbieten kann da er nicht auf Validität achten muss und die Seiten meinetwegen nur für IE6 optimiert.

Dass er dadurch nicht viele Kunden gewinnt merkt er erst wenn der Seitenersteller mit dem Geld über alle Berge ist. Außerdem wird er die geringe Kundschaft nicht auf invalide Seiten zurückführen, sondern er wird sagen :"Scheiß Internet, hat nicht so viel gebracht".
Er hat schliesslich keinen Vergleich, da er nicht weiß wie viele Kunden ihm valide Seiten gebracht hätten.

Wenn andere nun besser aussehende Seiten basteln, dann liegt das doch nicht daran, das sie nicht valide arbeiten. Das würde ja bedeutet, das man anständige Seite nicht valide erstellen kann, und das kanns doch nicht sein, oder? ("Ja, ich kann auch so schöne Seiten erstellen, die wären dann aber nicht valide" ist doch kein ausprechbarer Satz....)

Habe ich auch nicht behauptet. Ich meine nur, dass es für manche einfacher ist mit Frontpage oder einem anderen Schrott-Editor eine gute invalide Site herzustellen als für jemanden der die gleiche Site allerdings valide erstellt.

Ich persönlich belästige meine Kunden nicht mit solchen für ihn in seinem Geschäftsbetrieb eher uninteresanten Dingen. Vor dem Vorhang wird die Seite so gut wie ich es gerade kann, hinter den Kulissen eben auch. Weniger gibts nicht. Ich sag dem zufriedenen Kunden doch nicht stolz geschwelgt: "und hab ich auch schön valide gemacht" - das sollte doch Standard sein... hätte er bei mir weniger erwarten sollen?

Stimme ich Dir zu, seine Anforderungen sollen erfüllt sein. Allerdings zähle ich das zu Beratungsleistung, damit er versteht warum gutes Webdesign teuer werden kann. Im Prinzip könnte er sich bei einem Templateanbieter einen Satz Schrott-Templates für 80 Euro kaufen.

Gruss
Anja

[Chräcker Heller]

Hallo,

Ah, jetzt verstehe ich ;-) Du gehst von der Prämisse aus, das gutausehende valide Webseiten schwerer und oder teurer zu erstellen sind, als nicht-valide gut aussehde Webseiten. Dann muß man das natürlich dem kunden erklären.

Ich selber gehe allerdings nicht davon aus, und meine Arbeit kostet eben was sie kostet. Sie ist sicherlich teurer als manche anderen Frontpagekleberseiten, aber sicher nicht, weil ich ab und an glatt auch valide Seiten produziere. Validität hat für mich nichst mit mehrkosten oder Mehraufwand zu tun. (Das ich zur zeit für valide Seiten länger brauche liegt nur daran, das ich da noch viel Lernbedarf habe, aber das kann ich ja nicht auf den preis abwälzen....)

Chräcker

[at]

Hallo.

Es kann ja aber sein, dass er sich von einem anderen Anbieter blenden lässt der meinetwegen vor dem Vorhang genauso schöne oder weniger schöne Seiten erstellt wie ich, es jedoch viel günstiger anbieten kann da er nicht auf Validität achten muss und die Seiten meinetwegen nur für IE6 optimiert.

In Ergänzung zu der Antwort, die du darauf bereits erhalten hast: Es kann auch sein, dass er aus anderen Gründen viel günstiger ist, etwa weil er nicht davon leben muss, er den Entwurf bereits in der Ecke liegen hat, er einen indischen Subunternehmer beschäftigt oder seine Drillinge versklavt. Dies alles sollte keine Auswirkungen auf deine Preisgestaltung haben, der ja deine eigene Kalkulation zu Grunde liegen sollte. Wenn dort allerdings die Validierung separat aufgeführt ist, solltest du deine Arbeitsweise überdenken.
MfG, at

[e7]

Hi,

Nun bräuchte ich ein paar schlagende Argumente um ihn zu überzeugen dass Validierung wichtig ist.

Naja, sonst könnte ein Großteil der potentiellen Kunden nicht auf den Shop (oder nur Website) zugreifen können (und die die könnten, gehen wieder, wenn's hässlich aussieht) und ihm dadurch viele Geschäfte durch den Lappen gehen. Du musst ihm ja nicht unbedingt sagen, dass der IE von ca. 85 % aller Besucher genutzt wird.

E7

[Anja]

Hi

Du musst ihm ja nicht unbedingt sagen, dass der IE von ca. 85 % aller Besucher genutzt wird.

GUT ;-)

Gruss
Anja

[at]

Hallo.

Du musst ihm ja nicht unbedingt sagen, dass der IE von ca. 85 % aller Besucher genutzt wird.

Warum nicht? Der Marktanteil des Kunden an seinem Gesamtmarkt dürfte deutlich geringer ausfallen. Ist er deshalb zu vernachlässigen?
MfG, at

[e7]

Hi,

Du musst ihm ja nicht unbedingt sagen, dass der IE von ca. 85 % aller Besucher genutzt wird.

Warum nicht?

Wenn irgend ein Anfänger mitbekommt, dass der IE auf fast jeden Rechner läuft, geht er automatisch davon aus dass die anderen Browser nichts taugen (sonst würden sie sich ja durchsetzen und mehr verwendet werden) und dass damit sowieso nur Freaks surfen, die eh schon alles haben und von daher aus dem potentiellen Kundenkreis herausfallen...

E7

[at]

Hallo.

Wenn irgend ein Anfänger mitbekommt, dass der IE auf fast jeden Rechner läuft, geht er automatisch davon aus dass die anderen Browser nichts taugen (sonst würden sie sich ja durchsetzen und mehr verwendet werden) und dass damit sowieso nur Freaks surfen, die eh schon alles haben und von daher aus dem potentiellen Kundenkreis herausfallen...

Sind Freaks per se keine Kunden?
MfG, at

[e7]

Hi,

Sind Freaks per se keine Kunden?

Eigentlich schon, aber die haben meistens alles schon und bestellen sich sowieso alles bei eBay weil's billiger ist...

E7

[at]

Hallo.

Eigentlich schon, aber die haben meistens alles schon und bestellen sich sowieso alles bei eBay weil's billiger ist...

*lol* Okay, dieser Argumentation muss ich mich natürlich geschlagen geben ;-)
MfG, at

[Markus Trusk]

Hola,
warum sind Validität und gutes Aussehen zwei verschiedene Dinge? Wo liegt das Problem, wenn ich gut gestaltete Grafiken in eine valide Webseite einbinde? Es tut mir leid, aber ich kann dir dabei irgendwie nicht ganz folgen?

Markus Trusk.

[Anja]

warum sind Validität und gutes Aussehen zwei verschiedene Dinge?

»»

Wer hat das behauptet?

[Cybaer]

Hi,

Natürlich muss es so günstig wie möglich sein.

Auch teure Seiten sind (leider) kein Garant für Qualität ...

• zweite Frage: ich lege viel Wert auf valide Seiten (HTML u. CSS). Es gibt allerdings viele "Möchtegern-Profis" die nur einen Wert auf Aussehen legen.

Das eine hat nichts mit dem anderen zu tun! :-)

Und, BTW, Validität ist nicht alles. Jeder "Depp" kann sich 'ne HTML-x.x-Doku besorgen, nach "Schema F" arbeiten (lassen) und das Ergebnis solange durch einen Validator schicken, bis der keine Fehler mehr  meldet. Naja, dafür könnte auch noch ein Schimpanse ausreichen ... ;->

Es gibt auch keinen Grund, proprietäre Elemente nicht zu verwenden. Hauptsache, das Dokument ist sonst OK ("wohlgeformt") und diejenigen, die davon nichts haben, müssen darunter nicht unnötigerweise leiden. :-)

Da der Bekannte keine Ahnung von Web-Auftritten hat wird er nur das beurteilen was er am Ende sieht.

Und das sollte, egal mit welchem Browser und welcher Konfiguration (IE/Mozilla/..., Scripting An/Aus, ...), halt fehlerfrei rüberkommen.

Daher muss ich ihn überzeugen, dass er bei der Auswahl des

Einfach zeigen, daß sich deine Seiten nicht aus der "Ruhe" bringen lassen.

Nun bräuchte ich ein paar schlagende Argumente um ihn zu überzeugen dass Validierung wichtig ist. Natürlich wird ihn das nur jucken wenn er für sich Kostenersparnisse sieht.

Also entweder man kann HTML, oder eben nicht. Da kann man weder Validität, noch Kosten, noch Aussehen von abhängig machen ...

Gruß, Cybaer

[molily]

Hallo,

Und, BTW, Validität ist nicht alles. Jeder "Depp" kann sich 'ne HTML-x.x-Doku besorgen, nach "Schema F" arbeiten (lassen) und das Ergebnis solange durch einen Validator schicken, bis der keine Fehler mehr  meldet. Naja, dafür könnte auch noch ein Schimpanse ausreichen ... ;->

Es gibt auch keinen Grund, proprietäre Elemente nicht zu verwenden. Hauptsache, das Dokument ist sonst OK ("wohlgeformt") und diejenigen, die davon nichts haben, müssen darunter nicht unnötigerweise leiden. :-)

Freilich gibt es solche Gründe. Die Verwendung von offen und konsensuell standardisierten Techniken bedeutet Zukunftssicherheit und Nachhaltigkeit. Selbst wenn angenommen wird, dass das invalide Markup nur zur Abwärtskompatibilität mit nicht standardkonformen Browsern eingefügt wird, wird es nach und nach zu einer Altlast, die den Code belastet und früher oder später durch einen Relaunch entsorgt werden muss. Sofern es keine essentiellen Gründe gibt, die das Einfügen von invalidem Markup gebieten, sollte man es sich gut überlegen, denn später sitzt man auf dem veralteten Code, der durch proprietäres Markup aufgeblasen ist. Das bedeutet schlechte Wartbarkeit und schlechte Skalierbarkeit.

Im Übrigen erzählt dein verlinkter Artikel ziemliche Märchen:

»Eigene DTDs [...] werden von den HTML-Browsern, trotz der dortigen Angabe des URLs der DTD, geflissentlich ignoriert« - Zum einen sind die Parser der Hypertextbrowser nicht-validierend. Sie haben sich für die DTD gar nicht zu interessieren, weil sie die Entities auch so kennen, für die restliche Verarbeitung wird die DTD nicht benötigt. Zum anderen hat es durchaus eine Relevanz, ob der Dokumentyp angegeben ist oder nicht, das sprichst du selbst weiter unten an.

»Jeder Hersteller gängiger Browser verwendet intern ohnehin mindestens eine Hersteller-spezifische DTD, die von den "offiziellen" HTML-DTDs des W3Cs, von denen es ja ebenfalls mehrere gibt, mal mehr, mal weniger abweicht« - Was hat das damit zu tun, dass kein DOCTYPE angegeben wird? »Hersteller-spezifische DTD« gibt es nicht, höchstens verschiedene Element- und Attributsätze. Darüber macht es ein fehlender DOCTYPE unmöglich, das Dokument automatisiert auf Fehler zu überprüfen, das bedeutet syntaktische Fehlerfreiheit, aber auch das ständige Bewusstsein darüber, an welchen Stellen bzw. in wie weit proprietärer Code verwendet wird.

»Anders als bei der "Mutter" der Beschreibungssprachen, SGML (worauf auch HTML beruht), bei der zu jedem Dokument verbindlich durch die real (und zuerst) existierende DTD dessen Gültigkeit (Validität) festgelegt wird, ...« - Das ist bei HTML ebenso der Fall.

»... ist es das Grundprinzip von HTML (aber auch von CSS), daß die Tags & Attribute vom Browser zu ignorieren sind, die er nicht kennt« - Das ist Unsinn, dieses »Grundprinzip« existiert nicht. Es gibt lediglich zum einen die verbreitete Praxis, dass die existierenden Browser fehlertolerant sind. Dies basiert aber nicht auf einer Norm, es gibt lediglich nicht-normative Empfehlungen, wie mit invalidem Markup umzugehen ist (http://www.w3.org/TR/html401/appendix/notes.html#notes-invalid-docs). Und das »Grundprinzip« von HTML ist es schon gar nicht (du darfst es gerne belegen).

»(Achtung: Bei Scripts ist dies nicht der Fall: sie müssen so programmiert werden, daß neue Scriptelemente von Browsern mit älteren Scriptversionen nicht interpretiert werden)« - Diese Unterscheidung ist unbegründet: Die Fehlertoleranz der Browser in Bezug auf unbekannte JavaScript-Konstrukte/-Objekte/-Methoden ist ebenfalls nicht standardisiert und es obliegt dem Browser, wie er mit fehlerhaftem/unbekannten Code umgeht. Du hast praktisch recht, dahinter steckt aber keine Notwendigkeit.

»D.h., ein ordnungsgemäßes SGML-Dokument darf wirklich nur die Elemente aufweisen, wie sie in der DTD definiert wurden, um von einer SGML-fähigen Software verarbeitet werden zu können.« - Wenn sich ein HTML-Dokument »ordnungsgemäß« nennen will, dann gilt dies im Falle eines validierenden Parsers ebenso. Es können natürlich nicht ordnungsgemäße SGML- und HTML-Dokumente existieren, genauso wie es nicht-validierende Parser gibt und fehlertolerante Parser/Prozessoren, die auch fehlerhafte SGML-Dokumente soweit es möglich ist verarbeiten.

»Ist die syntaktische Korrektheit aber gegeben, so spricht man von einem "wohlgeformten" Dokument.« - Das Konzept der Wohlgeformtheit gibt es in SGML nicht.

»Sinn dieser Lockerung war, daß ein HTML-Dokument möglichst einfach zu erstellen sein sollte, um so möglichst hohe Verbreitung zu finden« - Diese Lockerung, wie du sie beschreibst, gab es nie. Die Browser waren und sind zwar nachlässig Fehlern gegenüber, in normativer Hinsicht war dies aber nie vorgesehen, schon gar nicht vorgeschrieben und schon gar nicht mit der Absicht, dass es nichts ausmacht, dass invalide HTML-Dokumente entstehen.

»Ein SGML-Dokument bedarf, insbesondere was Planung und Erstellung der DTD angeht, eines weitaus höheren Aufwands, was auch der Grund ist, warum es vergleichsweise wenig Programme gibt, die HTML-Code prüfen: Die anfangs existenten (teuren) Validatoren kannten gar kein HTML.« - Das stimmt nicht, sobald ein validierender SGML-Parser die SGML-Deklaration und die DTD von HTML in die Finger bekommt, kann er HTML validieren. Und kostenlose validierende SGML-Parser gibt es schon seit Jahrzehnten (sgmls, m.W. auch arcsgml).

»Sie behandelten HTML-Dokumente eben wie SGML-Dokumente, ohne auf das HTML-Grundprinzip Rücksicht zu nehmen.« - Dieses Grundprinzip gibt es wie gesagt nicht und validierende SGML-Parser prüfen nunmal SGML-Dokumente gegen die DTD. Es gibt keine besondere Ausnahme für HTML, wo sollte diese auch artikuliert sein, in der SGML-Deklaration? Dann hätte das Validieren wenig Sinn.

»Hieraus dürfte sich auch der in bestimmten Kreisen verbreitete Irrglaube gebildet haben, ein HTML-Dokument habe unbedingt valide zu sein.« - Irrglaube ist ein gutes Stichwort angesichts deiner unfundierten Argumentation... Natürlich hat ein HTML-Dokumente nicht in dem Sinne valide zu sein, dass der Browser die Validität wie ein validierender SGML-Parser prüft und im Fehlerfalle abbricht. Aber er muss natürlich die Elemente und Attribute kennen, um sie verarbeiten zu können. Dass er darüber hinwegsieht, wenn ihm ein Konstrukt unbekannt ist oder fehlerhaft vorkommt, beruht auf einer informalen Vereinbarung, nicht auf einer Norm (und schon gar nicht auf einem Prinzip!).

»Und da ich fast von Anfang an dabei bin, sind neue Techniken halt einfach kumulativ hinzugekommen - sie haben das "alte Wissen" nicht verdrängt, ...« - Ja, dadurch entsteht der oben beschriebene mies wartbare Code voll Altlasten.

»Der Nachteil, daß die üblichen [...] Validatoren "meckern", weil sie leider nicht nur die Syntax prüfen [...], sondern (eben konträr zum definierten Verhalten eines HTML-Browsers) ...« - Dieses Verhalten ist nicht »definiert«, es ist historisch gewachsen und hat sich ale praktisch erwiesen.

»... auch versuchen, die Semantik zu überprüfen (also z.B.: sind die Elemente bekannt und "erwünscht", d.h. gehören sie zur einer bestimmten, ggf. auch einer vielleicht zukünftigen, noch zu schreibenden DTD =:-o)« - Ein Validator prüft lediglich, ob ein Attribut bzw. Element zum Sprachumfang gehört und an dieser Stelle im Dokumentbaum vorkommen kann. Mit Semantik im Sinne einer semantischen Stimmigkeit der Elementverwendung hat dies hingegen nichts zu tun.

Mathias

[Cybaer]

Hi,

Es gibt auch keinen Grund, proprietäre Elemente nicht zu verwenden.

Selbst wenn angenommen wird, dass das invalide Markup nur zur Abwärtskompatibilität mit nicht standardkonformen Browsern eingefügt wird, wird es nach und nach zu einer Altlast, die den Code belastet und früher oder später durch einen Relaunch entsorgt werden muss.

Aber niemand muß einen Relaunch machen für Element, die niemanden stören (zumindest weder den Surfer, noch den HTML-Browser). Na ja, außer vielleicht die Optik des Quellcodes und das Verständnis der "Validitäts-Kleriker". ;-)

Sofern es keine essentiellen Gründe gibt, die das Einfügen von invalidem Markup gebieten, sollte man es sich gut überlegen,

Yep. Man sollte allerdings generell gut überlegen, was man macht (und insbesondere, wenn man es auf die Menschheit losläßt ... =;->

denn später sitzt man auf dem veralteten Code, der durch proprietäres Markup aufgeblasen ist. Das bedeutet schlechte Wartbarkeit und schlechte Skalierbarkeit.

... wenn man nicht weiß, was man tut, könnte das passieren (passiert dann allerdings so oder so leicht =:-o).

Im Übrigen erzählt dein verlinkter Artikel ziemliche Märchen:

:))

»Eigene DTDs [...] werden von den HTML-Browsern, trotz der dortigen Angabe des URLs der DTD, geflissentlich ignoriert« - Zum einen sind die Parser der Hypertextbrowser nicht-validierend. Sie haben sich für die DTD gar nicht zu interessieren, weil sie die Entities auch so kennen, für die restliche Verarbeitung wird die DTD nicht benötigt.

Eben - meine Rede.

Zum anderen hat es durchaus eine Relevanz, ob der Dokumentyp angegeben ist oder nicht, das sprichst du selbst weiter unten an.

Dokumententyp != DTD!

»Jeder Hersteller gängiger Browser verwendet intern ohnehin mindestens eine Hersteller-spezifische DTD, die von den "offiziellen" HTML-DTDs des W3Cs, von denen es ja ebenfalls mehrere gibt, mal mehr, mal weniger abweicht« - Was hat das damit zu tun, dass kein DOCTYPE angegeben wird?

Mit dem DOCTYPE lege ich mich auf eine DTD fest. Ein Problem, wenn es sich um SGML handeln würde (dann könnte jeder Server, jede Seite eine eigene DTD haben). HTML ist aber bewußt offener gehalten (auf mehr als eine weltweite DTD), und deswegen braucht der HTML-Browser (im Gegensatz zu einem SGML-Browser) auch kein DOCTYPE mit einer bestimmten DTD (auch wenn es HTML-Browser gibt die bei solchen Angaben anfangen, mehr oder weniger "rumzuraten" -> "SGML-unwürdiges Verhalten" ;->).

Darüber macht es ein fehlender DOCTYPE unmöglich, das Dokument automatisiert auf Fehler zu überprüfen,

Keineswegs. =:-o

Ich kann a) einen guten, herkömmlichen HTML-Validator mit "meinen" Regeln versehen oder b) meinem SGML-Validator anweisen, stets eine (nämlich meine eigene) DTD zu verwenden. 8-)

Das ist Unsinn, dieses »Grundprinzip« existiert nicht.

Tja, da haben wir wohl unterschiedliche Meinungen. :)

Es gibt lediglich zum einen die verbreitete Praxis, dass die existierenden Browser fehlertolerant sind.

Das meinte ich auch gar nicht nicht.

Dies basiert aber nicht auf einer Norm, es gibt lediglich nicht-normative Empfehlungen, wie mit invalidem Markup umzugehen ist

Soso ...

»Grundprinzip« von HTML ist es schon gar nicht (du darfst es gerne belegen).

Ich habe leider die Doks meiner HTML-1.0-Zeit schon entsorgt und mit relativ schwammigen Forumlierungen wie Stefan Münzers "gemäß einer alten Übereinkunft" (sinngemäß in selfHTML, bzw. einem entsprechenden Buch von ihm gelesen), werde ich Dich ohnehin nicht beeinflussen können. ;)

Du hast praktisch recht, dahinter steckt aber keine Notwendigkeit.

Ich würde mich ja freuen (sehr sogar: diese ständige "JavaScript-Aufpasserei" ist wirklich nervig), wenn es anders wäre. Also bleibt es solange bei der normativen Kraft des Faktischen. :)

(Aus Gründen der Rückwärtskompatibilität quasi ewig?! ;-))

»Ist die syntaktische Korrektheit aber gegeben, so spricht man von einem "wohlgeformten" Dokument.« - Das Konzept der Wohlgeformtheit gibt es in SGML nicht.

Yep, ist vielleicht mißverständlich. Ich beziehe mich bereits auf HTML (bzw. natürlich auch auf XML/XHTML). SGML-Doks müssen, wie ich ja auch schrieb, unbedingt valide sein.

Diese Lockerung, wie du sie beschreibst, gab es nie.

Ich muß Dir widersprechen: HTML wurde von jeher nicht so streng gesehen, wie SGML. Daß das W3C heute einige dieser Auswüchse (sinnvoll oder nicht, sei dahingestellt - anderes Thema) wieder korrigiert, ändert nichts an der Vergangenheit. 8-)

Die Browser waren und sind zwar nachlässig Fehlern gegenüber,

Wie gesagt (und dort auch geschrieben): Die zusätzliche Fehlertoleranz der Browser meine ich damit gar nicht! Sie ist ein *zusätzlicher* Fluch/Segen.

Das stimmt nicht, sobald ein validierender SGML-Parser die SGML-Deklaration und die DTD von HTML in die Finger bekommt, kann er HTML validieren.

Klar. Es ist dann ja auch kein HTML-Dokment mehr, sondern ein SGML-Dokument. =:-o (Nasenbär! ;-))

AFAIR kamen selbst die ersten W3C-Dokumente noch ohne DOCTPE aus.

Und kostenlose validierende SGML-Parser gibt es schon seit Jahrzehnten (sgmls, m.W. auch arcsgml).

Was Du nicht sagst ... (kopfschüttel)

Nach meinen ersten HTML-Versuchen, war der erste Schritt, die Suche nach einem Validator, der zweite die Erstellung meiner persönlichen DTD (zugegebenermaßen später, mangels Notwendigkeit, nicht mehr weiter verfolgt).

Natürlich hat ein HTML-Dokumente nicht in dem Sinne valide zu sein, dass der Browser die Validität wie ein validierender SGML-Parser prüft und im Fehlerfalle abbricht.

Merci: Quod erat demonstrandum! Da hast gerade schön den Unterschied zw. einem HTML- und enem SGML-Browser beschrieben. :)

Und da ich fast von Anfang an dabei bin, sind neue Techniken halt einfach kumulativ hinzugekommen - sie haben das "alte Wissen" nicht verdrängt, ...« - Ja, dadurch entsteht der oben beschriebene mies wartbare Code voll Altlasten.

Also ich habe absolut keine Probleme. Weder mit der Wartbarkeit meines Codes, noch mit älteren Browsern ... =8-)

... und verglichen mit diveren Browser-Bug-Workarounds auch für aktuelle Browser, geradezu Peanuts. =;->

Daß meine Art zu coden sich nicht auf jedermann übertragen läßt (schon mangels Erfahrung), ist mir ja bewußt. Nur: In der Validität hängt eben nicht Gottes alleinige Glückseligkeit ... :-)

Dieses Verhalten ist nicht »definiert«, es ist historisch gewachsen und hat sich ale praktisch erwiesen.

Henne-Ei-Problem? Das gleiche Prinzip war dann für CSS gut genug, für JavaScript aber nicht? ;>

Mit Semantik im Sinne einer semantischen Stimmigkeit der Elementverwendung hat dies hingegen nichts zu tun.

Semantik steht bei mir für den *Sprachumfang* (also die erlaubten/definierten Tags & Atribute). Erliege ich hier einem Begriffsirrtum (habe gerade keinen Duden rumliegen)?

Gruß, Cybaer

[at]

Hallo.

Aber niemand muß einen Relaunch machen für Element, die niemanden stören (zumindest weder den Surfer, noch den HTML-Browser).

Das Problem hieran ist der Sachverhalt, dass sich gestört fühlende Surfer sich nicht beschweren, sondern die Seite schlicht nicht mehr besuchen oder den Besuch gar sofort abbrechen.
Und du kennst alle Browser, die in Zukunft entwickelt werden, insbesondere für Mobiltelefone etc.?

Na ja, außer vielleicht die Optik des Quellcodes und das Verständnis der "Validitäts-Kleriker". ;-)

Suchmaschinen mögen validen Code auch sehr.
MfG, at

[Cybaer]

Hi,

Das Problem hieran ist der Sachverhalt, dass sich gestört fühlende Surfer sich nicht beschweren, sondern die Seite schlicht nicht mehr besuchen oder den Besuch gar sofort abbrechen.

Und? Wollen wir mal ausprobieren, auf wievielen Browsern meine und deine Seiten so funktionieren/sich der Surfer gestört fühlt? Da bin ich aber echt gespannt ... 8-) (nein, nicht wirklich ;))

Und du kennst alle Browser, die in Zukunft entwickelt werden, insbesondere für Mobiltelefone etc.?

Nö. Mir reicht, daß sie mit meinem Code klarkommen (und das tun sie garantiert)

Suchmaschinen mögen validen Code auch sehr.

Und meine Seiten erst (wie ich meinen Logs entnehmen kann) ... :-)

Gruß, Cybaer

PS: Ich code valide im SGML-Sinn - nur eben nicht zu den offiziellen W3C-DTDs, und damit, im Sinne der W3C-Puristen, eben nicht HTML-valide, sondern "nur" wohlgeformt.

[at]

Hallo.

Und du kennst alle Browser, die in Zukunft entwickelt werden, insbesondere für Mobiltelefone etc.?

Nö. Mir reicht, daß sie mit meinem Code klarkommen (und das tun sie garantiert)

Du kennst sie nicht, garantierst aber die Funktion? Nur Mut!

Suchmaschinen mögen validen Code auch sehr.

Und meine Seiten erst (wie ich meinen Logs entnehmen kann) ... :-)

Denen kannst du entnehmen, wie deine Seiten einsortiert werden?

PS: Ich code valide im SGML-Sinn - nur eben nicht zu den offiziellen W3C-DTDs, und damit, im Sinne der W3C-Puristen, eben nicht HTML-valide, sondern "nur" wohlgeformt.

Du hast da ein paar "Anführungszeichen" verloren.
MfG, at

[Cybaer]

Hi,

Nö. Mir reicht, daß sie mit meinem Code klarkommen (und das tun sie garantiert)
Du kennst sie nicht, garantierst aber die Funktion? Nur Mut!

Keine Sorge: Ich habe schon soviele Browser kommen und gehen sehen, daß werden sich die allermeisten hier gar nicht vorstellen können. 8-)

Suchmaschinen mögen validen Code auch sehr.
Und meine Seiten erst (wie ich meinen Logs entnehmen kann) ... :-)
Denen kannst du entnehmen, wie deine Seiten einsortiert werden?

Natürlich.

Der Referrer ist ja (meistens) ein Link zur Suchmaschine. Wenn ich den zurückverfolge, kann ich sehen, wo meine Seiten einsortiert sind.

Das mache ich (und die, die meine - nicht-öffentliche - Analyse-Software nutzen) immer! Ein extrem wichtiges Mittel zur Bewertung der eigenen Seiten ... 8-)

Und sonst: Die Google-Toolbar verrät Dir ja auch das Ranking! :-)

Du hast da ein paar "Anführungszeichen" verloren.

Wo? :))

Gruß, Cybaer

PS: Für ein Satireprojekt veröffentliche ich diese Auswertug übrigens regelmäßig. Mit Rücklink zu den Suchmaschinen, wo Du ggf. (nicht immer) sehen kannst, wo die Seite im Ranking ist:
http://www.vampirehost.de/pzn/extras/x-files/
(am Freitagabend/spätestens Samstagmorgen gehen die aktuellen Januar-Einträge online)

[at]

Hallo.

Keine Sorge: Ich habe schon soviele Browser kommen und gehen sehen, daß werden sich die allermeisten hier gar nicht vorstellen können. 8-)

Nur bei den zukünftigen wird dein Erfahrungsschatz vermutlich doch noch Lücken aufweisen.
MfG, at

[Cybaer]

Hi,

Nur bei den zukünftigen wird dein Erfahrungsschatz vermutlich doch noch Lücken aufweisen.

Die Erfahrung zeigt, wie man problemlos browserübergreifend coden kann.

Sicher, für aktuelle Browser findet sich bei mir der eine oder andere Workaround für Browser-Fehler. Und neue Browser = neue Fehler (aber das ist nun eigentlich kein Problem des Codes =:-)).

Solange es sich also um einen weitgehend fehlerfreien HTML(!)-Browser handelt, solange werden die Seiten darstellbar und nutzbar sein (so wie sie momentan auch von HTML-1-Browsern oder Lynx nutzbar sind) ...

Oder wo siehst Du Fehlermöglichkeiten?

Gruß & schönes WE, Cybaer

[at]

Hallo.

Oder wo siehst Du Fehlermöglichkeiten?

Du hast sie selbst beschrieben: Fehlinterpretationen von Browsern greifen meist erst bei invalidem Code.
MfG, at

[Tim Tepaße]

Hallo Cybaer,

Zum anderen hat es durchaus eine Relevanz, ob der Dokumentyp angegeben
ist oder nicht, das sprichst du selbst weiter unten an.

Zum Beispiel verfallen Browser aufgrund unterschiedlicher DTDs in
unterschiedliche Rendermodi.

Dokumententyp != DTD!

Äh bitte? Es gibt zur Zeit  noch keine andere Methode einen Dokumententyp
festzulegen, als die der DTD. Was meinst Du also hier? Du willst doch
nicht etwa an dieser Stelle unnötig mit Begriffen knausern?

Ich habe leider die Doks meiner HTML-1.0-Zeit schon entsorgt (..)

Ich habe für Dich mal nachgeschaut. Der erste richtige Standard war
HTML 2.0 in RFC 1866: http://www.ietf.org/rfc/rfc1866.txt
Dort heißt es:

»markup in the form of a start-tag or end-tag, whose generic identifier
  is not declared is mapped to nothing during tokenization.«

...also ignoriert. Allerdings wird überall in diesem Absatz das schwächere
»should« benutzt, nicht das bindende »must« und später heißt es:

»Information providers are warned that this convention is not binding:
  unspecified behavior may result, as such markup does not conform to
  this specification.«

Ein klare Warnung für Seitenersteller.

Es gibt noch ein früheres, einem HTML Standard ähnlichen Dokument: Ein
Internet Draft auf der Stufe zum RFC. http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt

Dort wird nichts über unbekannte Elemente gesagt. Jedoch ist zu lesen:

»The name of a tag refers to an element type declaration in the HTML DTD.«

Ich denke, der Umkehrschluß dürfte klar sein.

AFAIR kamen selbst die ersten W3C-Dokumente noch ohne DOCTPE aus.

Du meinst HTML-Dokumente. Meines Wissens nach galt das nur für den
ursprünglichen (nach sechs Monaten ausgelaufenen) Internet Draft von
Tim Berners-Lee, danach war gab es immer mehr Rufe nach Doctypes, so
zum Beispiel in Raggetts HTML+. Und im ersten wirklichen Standard dann
HTML 2.0 der IETF HTML Working Group (RFC 1866) wurde dann der DOCTYPE
verpflichtend. Alles noch vor W3C-Zeiten.

Natürlich hat ein HTML-Dokumente nicht in dem Sinne valide zu sein, dass
der Browser die Validität wie ein validierender SGML-Parser prüft und im
Fehlerfalle abbricht.

Wobei dieses Verhalten anscheinend gerade für XHTML-Dokumente im Gespräch
ist, da die XML-Spec dies verlangt. Dave Hyatt versucht sich für das Webkit
gerade an einem Mittelweg.

Semantik steht bei mir für den *Sprachumfang* (also die
erlaubten/definierten Tags & Atribute). Erliege ich hier einem
Begriffsirrtum (habe gerade keinen Duden rumliegen)?

Die Semantik einer formalen Sprache ist für mich die Bedeutung der Tags
und Attribute. Ich würde das, was Du meinst, mit Grammatik bezeichnen.

Tim

[Cybaer]

Hi,

Zum Beispiel verfallen Browser aufgrund unterschiedlicher DTDs in
unterschiedliche Rendermodi.

Nein. Sie verfallen ggf. aufgrund (vordefinierter) DOCTYPE-Angaben in unterschiedliche Rendermodi (wie im genannten "Artikel" auch geschrieben). Die DTD interessiert die Browser nicht die Bohne ...

Dokumententyp != DTD!
Äh bitte? Es gibt zur Zeit  noch keine andere Methode einen Dokumententyp

Ein HTML-Dokument ist ein Überbegriff (wie SGML-Dokument, ...). Die DTD spezifiziert erst die "Möglichkeiten" des Dokuments. Ein Dok mit proprietärer MS-DTD bleibt trotzdem HTML, nur ist es nicht valide zu einer W3C-DTD (aber gleichwohl natürlich/hoffentlich zur passenden MS-DTD).

Dort wird nichts über unbekannte Elemente gesagt. Jedoch ist zu lesen:
  »The name of a tag refers to an element type declaration in the HTML DTD.«

Super! :-))

Denn in *meiner* HTML DTD sind sie ja deklariert ...

... und wenn es ein HTML-Browser wirklich bräuchte (aber wohl nie tun wird), könnte er das Dokument an dieser DTD validieren. Will er aber eben nicht, womit das ganze arg akademisch ist ... :-o

Wobei dieses Verhalten anscheinend gerade für XHTML-Dokumente im Gespräch ist, da die XML-Spec dies verlangt.

? Meines Wissens ist ein valides XML-Dok eine Möglichkeit ein wohgeformtes eine andere. Aber selbst wenn strikte Validität zu "offiziellen" DTDs verlangt würde (da seien aber wohl schon die Browserhersteller mit ihren eigenen Süppchen vor): Was hat das mit HTML zu tun? Also ich rede hier von HTML und dem oft nicht hinterfragt veröffentlichtem "das muß so sein, weil es so sein muß" ...

Gruß, Cybaer

[molily]

Hallo,

Ein HTML-Dokument ist ein Überbegriff (wie SGML-Dokument, ...). Die DTD spezifiziert erst die "Möglichkeiten" des Dokuments. Ein Dok mit proprietärer MS-DTD bleibt trotzdem HTML, nur ist es nicht valide zu einer W3C-DTD (aber gleichwohl natürlich/hoffentlich zur passenden MS-DTD).

Dort wird nichts über unbekannte Elemente gesagt. Jedoch ist zu lesen:
  »The name of a tag refers to an element type declaration in the HTML DTD.«

Super! :-))

Denn in *meiner* HTML DTD sind sie ja deklariert ...

Du ziehst dich aus der Affäre, denn es ist nicht anhand der zitierten Quellen begründbar, dass eine andere DTD als die der besagten Spezifikation gemeint ist.
Wenn du der Meinung bist, dass alles, was sich selbst HTML nennt (und evtl. ein paar Eigenschaften mit HTML teilt und in einem Leseprogramm dargestellt wird, das sich Hypertextbrowser nennt), tatsächlich auch HTML ist und in jeder Hinsicht gleichwertig zu anderem HTML ist, erübrigt sich diese Diskussion natürlich, weil der Begriff »Validität« dann absolut gar nichts mehr mit Standardkonformität bzw. den Vorteilen der Orientierung an konsensuellen Standards zu tun hat.

Mathias

[Cybaer]

Hi,

Denn in *meiner* HTML DTD sind sie ja deklariert ...
Du ziehst dich aus der Affäre, denn es ist nicht anhand der zitierten Quellen begründbar, dass eine andere DTD als die der besagten Spezifikation gemeint ist.

So gesehen gäbe es dann auch gar keine HTML-Browser, weil so ziemlich alle (mehr oder weniger) nicht (in deinem Sinne) "standardkonform" sind? =:-o

(...) »Validität« dann absolut gar nichts mehr mit Standardkonformität bzw. den Vorteilen der Orientierung an konsensuellen Standards zu tun hat.

? Die Validität ergibt sich einzig aus der DTD.

Gruß & schönes WE, Cybaer

[molily]

Hallo,

Selbst wenn angenommen wird, dass das invalide Markup nur zur Abwärtskompatibilität mit nicht standardkonformen Browsern eingefügt wird, wird es nach und nach zu einer Altlast, die den Code belastet und früher oder später durch einen Relaunch entsorgt werden muss.

Aber niemand muß einen Relaunch machen für Element, die niemanden stören (zumindest weder den Surfer, noch den HTML-Browser). Na ja, außer vielleicht die Optik des Quellcodes und das Verständnis der "Validitäts-Kleriker". ;-)

Ich meinte eher, dass, wenn sich die Seite weiterentwickelt, dieser Code in neuen Konzepten nicht mehr brauchbar ist und sich in diese nicht einschmiegt. Je unflexibler der Code durch solches Markup wird und die Trennung und Rationalisierung der unterschiedlichen Komponenten eingeschränkt wird, desto eher muss der Gesamtcode bei einem Relaunch grundlegend verändert werden anstatt dass die Veränderung nur eine Komponente erfasst (etwa das Stylesheet).

Sofern es keine essentiellen Gründe gibt, die das Einfügen von invalidem Markup gebieten, sollte man es sich gut überlegen,

Yep. Man sollte allerdings generell gut überlegen, was man macht (und insbesondere, wenn man es auf die Menschheit losläßt ... =;->

denn später sitzt man auf dem veralteten Code, der durch proprietäres Markup aufgeblasen ist. Das bedeutet schlechte Wartbarkeit und schlechte Skalierbarkeit.

... wenn man nicht weiß, was man tut, könnte das passieren (passiert dann allerdings so oder so leicht =:-o).

Ja, unter diesen Voraussetzungen ist es natürlich verantwortbar. Leider hat dein Artikel meiner Auffassung nach eine etwas andere Aussage. Vielleicht ist es auch nicht absichtlich und nur eine mögliche Wirkung, aber die Argumentation läuft darauf hinaus, dass man sich über Validität keine so großen Gedanken machen sollte bzw. ihr nicht so große Bedeutung zumessen sollte. Und das greift für sich genommen m.E. zu kurz.

»Jeder Hersteller gängiger Browser verwendet intern ohnehin mindestens eine Hersteller-spezifische DTD, die von den "offiziellen" HTML-DTDs des W3Cs, von denen es ja ebenfalls mehrere gibt, mal mehr, mal weniger abweicht« - Was hat das damit zu tun, dass kein DOCTYPE angegeben wird?

Mit dem DOCTYPE lege ich mich auf eine DTD fest. Ein Problem, wenn es sich um SGML handeln würde (dann könnte jeder Server, jede Seite eine eigene DTD haben)

Es handelt sich um SGML. Jeder kann eigene Hypertextauszeichnungssprachen schreiben, die mehr oder weniger an W3C-HTML angelehnt sind und mehr oder weniger in Hypertextbrowsern funktionieren, und gegen entsprechende DTDs validieren. (Einige machen das sogar, um den Schein der Konformität zu wahren.) Niemand ist auf die eine einzige HTML-DTD festgelegt. Ich verstehe nicht, worauf du hinauswillst, denn auch hier verhält sich HTML nicht anders als irgendeine anderes SGML-Derivat.

HTML ist aber bewußt offener gehalten (auf mehr als eine weltweite DTD)

Wer sollte das entschieden haben? Die Browserhersteller, indem sie durch das Einfügen eigener Elemente und Attribute den W3C-Standard geöffnet haben? Vorher war der Standard aber nicht offen und er schlug auch nicht vor, HTML wie eine Basissprache zu behandeln, auf der jeder seine eigene Hypertextsprache aufbauen kann.
Darüber hinaus sind auch von anderen SGML-Sprachen eigene Abkömmlinge möglich, die dem Original mehr oder weniger nahe kommen, insofern sind auch dort verschiedene DTDs möglich. Nur enstanden sie anders.

und deswegen braucht der HTML-Browser (im Gegensatz zu einem SGML-Browser) auch kein DOCTYPE mit einer bestimmten DTD

Was ist ein »SGML-Browser«?

Darüber macht es ein fehlender DOCTYPE unmöglich, das Dokument automatisiert auf Fehler zu überprüfen,

Ich kann a) einen guten, herkömmlichen HTML-Validator mit "meinen" Regeln versehen oder b) meinem SGML-Validator anweisen, stets eine (nämlich meine eigene) DTD zu verwenden. 8-)

Ok, da gebe ich dir recht, das hatte ich nicht bedacht.

Das ist Unsinn, dieses »Grundprinzip« existiert nicht.

Tja, da haben wir wohl unterschiedliche Meinungen. :)

Verzeihung, aber was ist das denn für eine absurde Argumentation? Du kannst meinetwegen ein subjektives Verständnis von HTML haben und diese Technik dementsprechend verwenden, nur hat das nichts mit rationaler Auseinandersetzung zu tun, bei der es um gute Argumente, nicht um unbegründete Bauchmeinungen geht. Du könntest wahrscheinlich gute Argumente dafür nennen, warum es angemessen ist, HTML so zu verstehen. Nichtsdestoweniger unterstellst du HTML hier ein objektives »Grundprinzip«, das sich vermutlich derjenige ausgedacht haben soll, der HTML erfunden/entwickelt hat.
Anstatt deine Aussage zu belegen, ziehst du dich in diesem Punkt weitesgehend kommentarlos darauf zurück, dass es ja deine subjektive Auffassung sei und daher aus sich heraus wahr und begründet ist. Das ist wirklich enttäuschend.

Dies basiert aber nicht auf einer Norm, es gibt lediglich nicht-normative Empfehlungen, wie mit invalidem Markup umzugehen ist

Soso ...

Was soll dieser Kommentar? Du kannst meine Aussage gerne widerlegen.

»Grundprinzip« von HTML ist es schon gar nicht (du darfst es gerne belegen).

Ich habe leider die Doks meiner HTML-1.0-Zeit schon entsorgt

Die Spezifikationen zu 1992er-Versionen von HTML stehen noch im Netz, zu HTML 2 bis 4 ebenfalls, darauf könntest du dich bspw. beziehen. Am besten natürlich auf halbwegs ausgereifte (HTML 2) bzw. heute direkt relevante Versionen (HTML 4). Wo lässt sich darin dieses Grundprinzip finden?

und mit relativ schwammigen Forumlierungen wie Stefan Münzers "gemäß einer alten Übereinkunft" (sinngemäß in selfHTML, bzw. einem entsprechenden Buch von ihm gelesen), werde ich Dich ohnehin nicht beeinflussen können. ;)

Das stimmt, weil ich gerne möglichst handfeste Begründungen statt nur Hypothesen hören möchte. Dass eine Art historisch gewachsene informale »Übereinkunft« existiert, habe ich ferner nicht angezweifelt, die sprach Selfhtml vermutlich an.

Du hast praktisch recht, dahinter steckt aber keine Notwendigkeit.

Ich würde mich ja freuen (sehr sogar: diese ständige "JavaScript-Aufpasserei" ist wirklich nervig), wenn es anders wäre. Also bleibt es solange bei der normativen Kraft des Faktischen. :)

(Aus Gründen der Rückwärtskompatibilität quasi ewig?! ;-))

Im Prinzip ja, strenggenommen müsste jedes JavaScript die Existenz nahezu jedes grundlegenden Objektes bzw. jeder Methode abfragen, das bzw. die erst nach JavaScript 1.0 eingebaut wurde. Das wäre natürlich praktisch Overkill und die wenigsten Scripte achten darauf, Netscape 2 zu berücksichtigen usw.

Diese Lockerung, wie du sie beschreibst, gab es nie.

Ich muß Dir widersprechen: HTML wurde von jeher nicht so streng gesehen, wie SGML.

Was bedeutet das, »HTML wurde nicht so streng gesehen«? In welcher Hinsicht, wenn nicht hinsichtlich der Browserverarbeitung? Wo waren die Spezifikationen früher im Bezug auf Validität weniger streng?

Daß das W3C heute einige dieser Auswüchse (sinnvoll oder nicht, sei dahingestellt - anderes Thema) wieder korrigiert, ändert nichts an der Vergangenheit. 8-)

Ich wüsste nicht, dass es dem W3C um weniger Fehlertoleranz geht (von XHTML einmal abgesehen), was meinst du also? Proprietäres Markup?

Die Browser waren und sind zwar nachlässig Fehlern gegenüber,

Wie gesagt (und dort auch geschrieben): Die zusätzliche Fehlertoleranz der Browser meine ich damit gar nicht! Sie ist ein *zusätzlicher* Fluch/Segen.

Ok. Dann weiß ich aber nicht, was du überhaupt mit deinem Aussagen über das »Grundprinzip« u.ä. sagen willst.

Das stimmt nicht, sobald ein validierender SGML-Parser die SGML-Deklaration und die DTD von HTML in die Finger bekommt, kann er HTML validieren.

Klar. Es ist dann ja auch kein HTML-Dokment mehr, sondern ein SGML-Dokument. =:-o (Nasenbär! ;-))

Ähm... häh? Jedes HTML-Dokument ist ein SGML-Dokument.

AFAIR kamen selbst die ersten W3C-Dokumente noch ohne DOCTPE aus.

Das stimmt. Allerdings weiß ich nicht, welche Bedeutung dieser Umstand heute hat bzw. angesichts der späteren Entwicklung hat. Seitdem sind über zehn Jahre vergangen und das HTML von heute hat mit dem HTML von damals extrem wenig zu tun. Die Konformität zur DTD und die Abstammung von SGML ist spätestens seit HTML 2 ein Kernbestandteil dessen, was HTML ausmacht (siehe etwa die Definition http://www.w3.org/MarkUp/html-spec/html-spec_2.html#GLOSS18).

Und kostenlose validierende SGML-Parser gibt es schon seit Jahrzehnten (sgmls, m.W. auch arcsgml).

Was Du nicht sagst ... (kopfschüttel)

Was soll dieser Kommentar sagen? Bleibe doch einmal sachlich.

Nach meinen ersten HTML-Versuchen, war der erste Schritt, die Suche nach einem Validator, der zweite die Erstellung meiner persönlichen DTD (zugegebenermaßen später, mangels Notwendigkeit, nicht mehr weiter verfolgt).

Wenn du damit sagen willst, dass du damals keinen kostenlosen validierenden SGML-Parser gefunden hattest, dann hast du sgmls o.ä. wahrscheinlich einfach nur nicht gefunden, sie existierten auf jeden Fall schon.

Natürlich hat ein HTML-Dokumente nicht in dem Sinne valide zu sein, dass der Browser die Validität wie ein validierender SGML-Parser prüft und im Fehlerfalle abbricht.

Merci: Quod erat demonstrandum! Da hast gerade schön den Unterschied zw. einem HTML- und enem SGML-Browser beschrieben. :)

Nein, ich habe den Unterschied zwischen validierenden und nicht-validierenden Parsern beschrieben. Ein »SGML-Browser«, also ein auf einer anderen von SGML abgeleiteten Markupsprache basierender Client, hätte ebenfalls keinen validierenden Parser. Du wolltest aber ein Unterschied zwischen HTML einerseits und SGML *an sich* andererseits herausstellen, der alleine schon deshalb nicht funktioniert, weil HTML eine von SGML abgeleitete Sprache ist und SGML »an sich« nur eine Metasprache ist.

Und da ich fast von Anfang an dabei bin, sind neue Techniken halt einfach kumulativ hinzugekommen - sie haben das "alte Wissen" nicht verdrängt, ...« - Ja, dadurch entsteht der oben beschriebene mies wartbare Code voll Altlasten.

Also ich habe absolut keine Probleme. Weder mit der Wartbarkeit meines Codes, noch mit älteren Browsern ... =8-)

Ja, das lässt sich nur, wie du auch sagst, schwer verallgemeinern.

... und verglichen mit diveren Browser-Bug-Workarounds auch für aktuelle Browser, geradezu Peanuts. =;->

Das stimmt, ich sehe diese Workarounds prinzipiell ebenso skeptisch wie das Weiterbenutzen von altem Code, es ist m.E. ebenfalls wenig nachhaltig.

Mit Semantik im Sinne einer semantischen Stimmigkeit der Elementverwendung hat dies hingegen nichts zu tun.

Semantik steht bei mir für den *Sprachumfang* (also die erlaubten/definierten Tags & Atribute). Erliege ich hier einem Begriffsirrtum (habe gerade keinen Duden rumliegen)?

Schon klar, wie du es meintest, ich wollte lediglich darauf hinweisen, dass es hier noch eine Differenzierung gibt: Sich auf den normativen Sprachumfang zu beschränken, bedeutet nicht, dass die Kombination dieser syntaktischen Einheiten letztlich einen Sinn ergibt. Wenn im allgemeinen von semantischem Markup gesprochen wird, dann ist nicht (nur) gemeint, dass es nur die definierten Elemente und Attribute in entsprechenden definierten formalen Kontexten verwendet, sondern dass es die Textauszeichnung auch semantisch ist (eine Überschrift wird mit hX ausgezeichnet, Absätze mit p, Listen mit ol/ul usw.).

Mathias

[Cybaer]

Hi,

Ich meinte eher, dass, wenn sich die Seite weiterentwickelt, dieser Code in neuen Konzepten nicht mehr brauchbar ist und sich in diese nicht einschmiegt.

Hmm, wir sind möglicherweise unterschiedlicher Auffassung, was "alte Technik" überhaupt ist?!

<FONT> & Co. mögen da zwar auch drunter fallen (gleichwohl: "unerwünscht" heißt ja nicht "ungültig"!), ich denke da aber z.B. auch daran:

• Abschluß einer Tabellenzeile ggf. mit BR ("valide": Tabelle ergibt keine Endloszeile aufBrowsern, die TABLE nicht kennen oder die Erkennung "abgeschaltet" haben)
• WBR nach Trennungsstrich im Wort ("unvalide" da proprietär: Beliebte Browser brechen den Text besser um)
• H1-H6 statt der insbesondere von "WYSIWYG"-Editoren gerne genutzten FONT- und CSS-Elementen (*mächtig* "valide ;-) - dieSuchmaschnenen freut es zudem)

Ja, unter diesen Voraussetzungen ist es natürlich verantwortbar. Leider hat dein Artikel meiner Auffassung nach eine etwas andere Aussage.

Die ist *auf keinen Fall* gewollt! (Ich gestehe: Früher war das noch eher "mißzuverstehen" - er wurde schon "nachgebessert" - ich grüble weiter ... ;-))

Vielleicht ist es auch nicht absichtlich und nur eine mögliche Wirkung, aber die Argumentation läuft darauf hinaus, dass man sich über Validität keine so großen Gedanken machen sollte bzw. ihr nicht so große Bedeutung zumessen sollte.

Validität ist das ein und alles, aber eben IMHO im SGML-Sinne. Was in der Öffentlichkeit (auch und gerade hierim Forum) aber unter HTML-Validität "segelt", greift eben IMHO zu kurz, da es halt viele HTML-DTDs nebeneinander gibt, die (eben anders als bei SGML) keinen Browser wirklich interessieren. :-(

Deswegen: "HTML-Validät" (im gebräuchlichen Sinne) ist fein, aber beileiber kein Kriterium um seiner selbst willen. "Wohlgeformt" reicht aus (valide zu einer, und sei es eingebildeten, DTD, nicht aber zu einer der W3C-DTDs).

»Jeder Hersteller gängiger Browser verwendet intern ohnehin mindestens eine Hersteller-spezifische DTD, die von den "offiziellen" HTML-DTDs des W3Cs, von denen es ja ebenfalls mehrere gibt, mal mehr, mal weniger abweicht« - Was hat das damit zu tun, dass kein DOCTYPE angegeben wird?

Ich kann natürlich einen DOCTYPE angeben, nur interessieren sich die Browser nicht dafür (also speziell nicht für meine DTD).

Es handelt sich um SGML. Jeder kann eigene Hypertextauszeichnungssprachen schreiben, die mehr oder weniger an W3C-HTML angelehnt sind und mehr oder weniger in Hypertextbrowsern funktionieren, und gegen entsprechende DTDs validieren. (Einige machen das sogar, um den Schein der Konformität zu wahren.)

Das habe ich früher auch gemacht. Mittlerweile ist mir das aber zu heikel, da einige Browser zwar *versuchen*, den DOCTYPE zu entschlüsseln, aber in Wirklichkeit *raten*, was (vielleicht) zu tun sei. :-(((

Niemand ist auf die eine einzige HTML-DTD festgelegt. Ich verstehe nicht, worauf du hinauswillst,

Nach meiner Antwort fiel mir auch noch ein, daß wir möglicherweise aneinander vorbeireden. :-o

Mich stört, daß hier (aber auch sonst - am besten noch von Leuten, die SGML nur vielleicht dem Namen nach kennen) "Validität" gleichgesetzt wird mit "Valide zur aktuellen W3C-DTD - möglichst 4-strict". Nicht mehr, nicht weniger.

Tja, da haben wir wohl unterschiedliche Meinungen. :)
Verzeihung, aber was ist das denn für eine absurde Argumentation?

Von mir aus gar keine! :-)

Im Zweifel bin ich immer Praktiker, nicht Theoretiker/Bürokrat. ;->

ein objektives »Grundprinzip«, das sich vermutlich derjenige ausgedacht haben soll, der HTML erfunden/entwickelt hat.

Keine Ahnung. Ich in erst seit Mosaic 2.0 dabei (zur Zeit von Netscape Navigator 0.irgendwas).

Und da haben Dinge wie W3C, "offizielle" DTDs & Co. halt noch so gar keine Rolle gespielt. Nicht daß wir uns mißverstehen: Ist ja vieles sinnvoll und gut, was seitdem so geschehen ist - und der "Wilde Westen" ist gottseidank Vegangenheit. Aber es könnten sich einige der hiesigen Poster IMHO durchaus etwas "entspannen" (zumal Deutschland ohnehn mehr Bürokraten hat, als gut tut).

Was soll dieser Kommentar? Du kannst meine Aussage gerne widerlegen.

Warum? Ich bin nicht Jesus, der die Welt bekehrt. =;-)

So ist meine Auffassung, Du kannst drüber lästern, drüber nachdenken, sie unterstützen, oder alles oder irgendwas dazwischen - as you like. :-))

Das stimmt, weil ich gerne möglichst handfeste Begründungen statt nur Hypothesen hören möchte. Dass eine Art historisch gewachsene informale »Übereinkunft« existiert, habe ich ferner nicht

Mir scheint er Grat zw. "formal" ("Standard"?!) und "informal" arg klein - faktisch arg null.

Wenn ich Webseiten für die Theorie machen müßte, sähen siegewiß anders aus. Müßiges Diskussionsobjekt ...

Im Prinzip ja, strenggenommen müsste jedes JavaScript die Existenz nahezu jedes grundlegenden Objektes bzw. jeder Methode abfragen, das bzw. die erst nach JavaScript 1.0 eingebaut wurde. Das wäre natürlich praktisch Overkill und die wenigsten Scripte achten darauf, Netscape 2 zu berücksichtigen usw.

Also ich *prinzipiell* schon. Soll nicht heißen, daß alle Funktionalität bei mir auf NS2 gegeben ist, aber wo es geht/noch praktikabel ist, baue ich Eigenschaften höherer Versionen abwärtskompatibel nach, bzw. das *mindeste* ist, daß sie keine Fehler produzieren (wenn der Anwender schon keinen Nutzen vom Script hat)!

Was bedeutet das, »HTML wurde nicht so streng gesehen«? In welcher Hinsicht, wenn nicht hinsichtlich der Browserverarbeitung? Wo waren die Spezifikationen früher im Bezug auf Validität weniger streng?

Keine Angabe der DTD, keine Nutzung selbiger wie bei SGML, selbst wenn angegeben. Also "Scheißegal-Prinzip". :-o

Ich wüsste nicht, dass es dem W3C um weniger Fehlertoleranz geht (von XHTML einmal abgesehen), was meinst du also? Proprietäres Markup?

Eben. Ausschließlich darum.

Das stimmt. Allerdings weiß ich nicht, welche Bedeutung dieser Umstand heute hat bzw. angesichts der späteren Entwicklung hat. Seitdem sind über zehn Jahre vergangen und das HTML von heute hat mit dem HTML von damals extrem wenig zu tun.

Na ja ...

Was soll dieser Kommentar sagen? Bleibe doch einmal sachlich.

Sorry, aber ein unnötiger Hinweis für jemanden, der SGML ja kennt (wie Du ja nachgelesen hast). =;-)

Aber keine Sorge: Sowas meine ich nicht "böse" - ich bin eine *äußerst* friedliebende, stetige Frohnatur! ;-))))

Das stimmt, ich sehe diese Workarounds prinzipiell ebenso skeptisch wie das Weiterbenutzen von altem Code, es ist m.E. ebenfalls wenig nachhaltig.

Si si! "Seiten für die Theorie" != "Seiten für die Praxis".

Gruß, Cybaer

[molily]

Hallo,

Ich meinte eher, dass, wenn sich die Seite weiterentwickelt, dieser Code in neuen Konzepten nicht mehr brauchbar ist und sich in diese nicht einschmiegt.

Hmm, wir sind möglicherweise unterschiedlicher Auffassung, was "alte Technik" überhaupt ist?!

<FONT> & Co. mögen da zwar auch drunter fallen (gleichwohl: "unerwünscht" heißt ja nicht "ungültig"!),

Der entscheidende Punkt ist, dass unfähig gegenüber neueren Techniken sind, schlichtweg ineffizient.

ich denke da aber z.B. auch daran:

• Abschluß einer Tabellenzeile ggf. mit BR ("valide": Tabelle ergibt keine Endloszeile aufBrowsern, die TABLE nicht kennen oder die Erkennung "abgeschaltet" haben)

Das betrifft höchstens Browser aus 1993, das ist wirklich zu krass.
»Erkennung von Tabellen abgeschaltet« - alle Browser, die meines Wissens dazu fähig sind, linearisieren problemlos ohne br-Elemente am Zellenende. Dann müsste schon mutwillig th,td {display:inline} ins Benutzerstylesheet geschrieben werden, damit es Endloszeilen gibt.

• WBR nach Trennungsstrich im Wort ("unvalide" da proprietär: Beliebte Browser brechen den Text besser um)

Dazu gibt es kompatiblere CSS-Möglichkeiten. Was ist am Umbruch so schlimm?

• H1-H6 statt der insbesondere von "WYSIWYG"-Editoren gerne genutzten FONT- und CSS-Elementen (*mächtig* "valide ;-) - dieSuchmaschnenen freut es zudem)

Was ist an dieser Technik alt?

Vielleicht ist es auch nicht absichtlich und nur eine mögliche Wirkung, aber die Argumentation läuft darauf hinaus, dass man sich über Validität keine so großen Gedanken machen sollte bzw. ihr nicht so große Bedeutung zumessen sollte.

Validität ist das ein und alles, aber eben IMHO im SGML-Sinne. Was in der Öffentlichkeit (auch und gerade hierim Forum) aber unter HTML-Validität "segelt", greift eben IMHO zu kurz, da es halt viele HTML-DTDs nebeneinander gibt, die (eben anders als bei SGML)

Dazu habe ich bereits etwas gesagt und du hast es offenbar ignoriert, da du deine bereits kritisierten Aussagen nur widerholst.

keinen Browser wirklich interessieren. :-(

Das stimmt nicht. Nicht jede Markupsprache, die sich HTML nennt, ist auch ein Standard - die Vorteile des Verwendens von standardisierten Techniken habe ich bereits in zwei Postings zuvor geschildert. Es ist irreführend, zu verbreiten, dass jeder proprietäre HTML-Dialekt einer Firma gleichwertig mit den öffentlichen, herstellerübergreifenden HTML-Standards ist und es ganz gleich ist, ob man sich daran orientiert oder nicht. Du versuchst mal eben zu verwischen, dass es einen Unterschied zwischen der Verwendung von W3C-HTML und anderen proprietären Dialekten gibt, die die Standards und die allgemeinen Browserverhältnisse teilweise beachten, teilweise aber ihr eigenes Süppchen kochen. Sicherlich kann sich jeder eine eigene DTD schreiben (bei jder SGML-Sprache, wie gesagt) und Dokumente schreiben, die gegen diese validieren. Doch das ist gar nicht die Frage.

Deswegen: "HTML-Validät" (im gebräuchlichen Sinne) ist fein, aber beileiber kein Kriterium um seiner selbst willen.

Ist es auch nicht. Wie gesagt.

"Wohlgeformt" reicht aus (valide zu einer, und sei es eingebildeten, DTD, nicht aber zu einer der W3C-DTDs).

Dazu habe ich mich schon vor zwei Postings geäußert.

Es handelt sich um SGML. Jeder kann eigene Hypertextauszeichnungssprachen schreiben, die mehr oder weniger an W3C-HTML angelehnt sind und mehr oder weniger in Hypertextbrowsern funktionieren, und gegen entsprechende DTDs validieren. (Einige machen das sogar, um den Schein der Konformität zu wahren.)

Das habe ich früher auch gemacht. Mittlerweile ist mir das aber zu heikel, da einige Browser zwar *versuchen*, den DOCTYPE zu entschlüsseln, aber in Wirklichkeit *raten*, was (vielleicht) zu tun sei. :-(((

Das sollte dir zeigen, dass sie davon ausgehen, dass die Browser Dokumente erwarten, die öffentlichen und den Browsern bekannten Standards folgen und sich als solche Dokumente ausweisen.

Mich stört, daß hier (aber auch sonst - am besten noch von Leuten, die SGML nur vielleicht dem Namen nach kennen) "Validität" gleichgesetzt wird mit "Valide zur aktuellen W3C-DTD - möglichst 4-strict". Nicht mehr, nicht weniger.

Ich denke, die Hintergründe sind diesen Leuten durchaus bekannt, vor allem die Existenz verschiedener proprietärer HTML-Dialekte. Natürlich ist Validität zu irgendeiner DTD an sich irrelevant, es geht in nahezu allen Fällen, in denen von der Notwendigkeit von Validität gesprochen wird, um Konformität zu allgemein anerkannten Standards sowie die Vorteile, die sich aus der Beachtung dessen ergeben. Und im Bezug auf HTML ist das W3C federführend und vereinigt die Interessen verschiedener namhafter Firmen und Organisationen in den HTML-Standards.

Im Zweifel bin ich immer Praktiker, nicht Theoretiker/Bürokrat. ;-> [...]
Und da haben Dinge wie W3C, "offizielle" DTDs & Co. halt noch so gar keine Rolle gespielt. Nicht daß wir uns mißverstehen: Ist ja vieles sinnvoll und gut, was seitdem so geschehen ist - und der "Wilde Westen" ist gottseidank Vegangenheit. Aber es könnten sich einige der hiesigen Poster IMHO durchaus etwas "entspannen" (zumal Deutschland ohnehn mehr Bürokraten hat, als gut tut).

Jaja, ein rhetorischer Trick, kein sachliches Argument. Wenn ein Dokument sich proprietären Markups bedient und dies hier angezweifelt wird, hat nichts mit Theorie und Bürokratie zu tun, sondern in der Regel mit tatsächlich fehlender Kompatibilität und mangelnder Nachhaltigkeit.

Das stimmt, weil ich gerne möglichst handfeste Begründungen statt nur Hypothesen hören möchte. Dass eine Art historisch gewachsene informale »Übereinkunft« existiert, habe ich ferner nicht

Mir scheint er Grat zw. "formal" ("Standard"?!) und "informal" arg klein - faktisch arg null.

In welcher Hinsicht? Quasistandards sind zeitabhängige Moden, die sich nur dadurch legitimieren, dass gerade bestimmte Browser mit entsprechenden eigenen Auffassungen von HTML/CSS/JavaScript verbreitet sind. Dem informalen Quasistandard zu folgen, heißt, ein Webauthoring zu betreiben, dass sich vollkommen an den gegenwärtigen Verhältnissen orientiert und weder in die Zukunft schaut noch aus vergangenen Entwicklungen lernt. Das hat wie gesagt wenig damit zu tun, ob effiziente, zukunftssichere und über den Tellerrand hinaus funktionsfähige Techniken eingesetzt werden.

Wenn ich Webseiten für die Theorie machen müßte, sähen siegewiß anders aus. Müßiges Diskussionsobjekt ...

Nein, ganz und gar nicht. Zwischen Theorie und Praxis bestehen nicht nur einseitige Wirkungszusammenhänge.

Mathias

[Cybaer]

Hi,

<FONT> & Co. mögen da zwar auch drunter fallen (gleichwohl: "unerwünscht" heißt ja nicht "ungültig"!),
Der entscheidende Punkt ist, dass unfähig gegenüber neueren Techniken sind, schlichtweg ineffizient.

Da wirst Du von mir auch keinen Widerspruch hören. =:-)

Das betrifft höchstens Browser aus 1993, das ist wirklich zu krass.

Stört aber auch keinen.

»Erkennung von Tabellen abgeschaltet« - alle Browser, die meines Wissens dazu fähig sind, linearisieren problemlos ohne br-Elemente am Zellenende.

Vielleicht, vielleicht auch nicht. Und bei den "Gurken", die z.B. die Opera-Programmierer in schöner Endlosigkeit in ihre Software basteln, gehe ich lieber sicher (prinzipiell stimme ich Dir aber zu: Ich würde auch nie sagen, daß jemand schlecht codet, nur weil er solche "Alt-Petitessen" nicht macht =;-)).

• WBR nach Trennungsstrich im Wort ("unvalide" da proprietär: Beliebte Browser brechen den Text besser um)
  Dazu gibt es kompatiblere CSS-Möglichkeiten.

Für CSS-Browser. Aber egal: Gibt es? Cool, habe ich übersehen. Wonach muß ich suchen?

Was ist am Umbruch so schlimm?

Nix. Aber der Nicht-Umbruch geht mir auf den Senkel, da ein entsprechend häufigerer Umbruch im Blocksatz harmonischer wirkt, und ansonsten der Rand nicht so ausgefranst ist (aber war ja nur ein Beispiel).

• H1-H6 statt der insbesondere von "WYSIWYG"-Editoren gerne genutzten FONT- und CSS-Elementen (*mächtig* "valide ;-) - dieSuchmaschnenen freut es zudem)
  Was ist an dieser Technik alt?

Aus deiner und meiner Sicht: Nichts.

Aus der Sicht vieler heutiger, unerfahrenerer Web-Autoren, sieht das mitunter leider, leider ganz anders aus. :-((

Es ist irreführend, zu verbreiten, dass jeder proprietäre HTML-Dialekt einer Firma gleichwertig mit den öffentlichen, herstellerübergreifenden HTML-Standards ist und es ganz gleich ist, ob man sich daran orientiert oder nicht.

Ich denke nicht, daß ich das verbreite. Ich denke vielmehr, daß ich verbreite, daß öfentliches, herstellerübergreifendes HTML die Regel ist, der es nicht "wehtut", wenn man auch proprietäre Elemente mit Bedacht verwendet.

Sicherlich kann sich jeder eine eigene DTD schreiben (bei jder SGML-Sprache, wie gesagt) und Dokumente schreiben, die gegen diese validieren. Doch das ist gar nicht die Frage.

Nicht deine Frage, aber meine "Frage".

Das sollte dir zeigen, dass sie davon ausgehen, dass die Browser Dokumente erwarten, die öffentlichen und den Browsern bekannten Standards folgen und sich als solche Dokumente ausweisen.

Und das in Verbindung mit einem Microschrott-Produkt - ich fall gleich hintenüber ... =;-)

Streiche "Standards folgen", setze "herumdilettieren". ;->

Und im Bezug auf HTML ist das W3C federführend und vereinigt die Interessen verschiedener namhafter Firmen und Organisationen in den HTML-Standards.

... die nachwievor diese Standards (CSS inklusive) fleissig proprietär erweitern (zumal das W3C doch ohnehin kein bindendes Normierungs-Institut a la ISO oder DIN ist, oder?)

Jaja, ein rhetorischer Trick, kein sachliches Argument. Wenn ein Dokument sich proprietären Markups bedient und dies hier angezweifelt wird, hat nichts mit Theorie und Bürokratie zu tun, sondern in der Regel mit tatsächlich fehlender Kompatibilität und mangelnder Nachhaltigkeit.

Über einen bestimmten Fall läßt sich reden, mit der Schrotflinte auf alles schießen, was sich bewegt, ist IMHO seltenst eine adäquate Handlung ... =:-o

Das hat wie gesagt wenig damit zu tun, ob effiziente, zukunftssichere und über den Tellerrand hinaus funktionsfähige Techniken eingesetzt werden.

Maxime 1: Stört es irgendeinen HTML-Browser?
Maxime 2: Könnte es einen zukünftigen HTML-Browser stören?
Maxime 3: Bringt es mir/dem Surfer einen Nutzen?

Wenn ich Webseiten für die Theorie machen müßte, sähen siegewiß anders aus. Müßiges Diskussionsobjekt ...
Nein, ganz und gar nicht. Zwischen Theorie und Praxis bestehen nicht nur einseitige Wirkungszusammenhänge.

Nun denn, die Standpunkte dürften hinreichend theoretisiert sein. :-)

Zeige mir doch einfach an Beispielen, wo ich proprietären/invaliden Code verwende, der sich nicht nur in d(ein)er Theorie, sondern in der Praxis negativ auswirkt (bzw. ggf. zukünftig negativ auswirken könnte). Bei einem Code, der prinzipiell darauf ausgelegt ist, auf "1993er-Browsern" nutzbar zu sein, und alle (D)HTML/CSS/Script-Neuerungen nur optional nutzt, aber nicht zwingend darauf angewiesen ist, würde mich das echt interessieren ... :-o

Gruß & schönes WE, Cybaer