W3C konform
- Ersteller Cyberbob
- Erstellt am
Also meiner Meinung nach, wäre es schön, wenn sich alle Webseitenersteller an die Standards halten. Dann würden es die Browserhersteller vielleicht auch und alles würde leichter werden.
Ich versuche auch alle (neuen *hust*) Seiten W3C konform zu schreiben. Das ist mit unter aber schon ein Aufwand - gerade bei so etwas wie onlienshops die das vielleicht von Haus aus gar nicht liefern.
Letztendlich wird das bei hohem Aufwand irgendwann auch unrentabel.
Also;
Ideal wäre natürlich wenn alles W3C konform ist.
Aufgrund des zu erwartenden Aufwands und dem geringen Nutzen, würde ich aber einfach zusehen, dass Du so dicht wie möglich drankomst - einfach auch um sauberen "Code" zu haben.
Ich versuche auch alle (neuen *hust*) Seiten W3C konform zu schreiben. Das ist mit unter aber schon ein Aufwand - gerade bei so etwas wie onlienshops die das vielleicht von Haus aus gar nicht liefern.
Letztendlich wird das bei hohem Aufwand irgendwann auch unrentabel.
Also;
Ideal wäre natürlich wenn alles W3C konform ist.
Aufgrund des zu erwartenden Aufwands und dem geringen Nutzen, würde ich aber einfach zusehen, dass Du so dicht wie möglich drankomst - einfach auch um sauberen "Code" zu haben.
Hy
Hab mal den www.fahnen-nostalgieshop.de bei Seitwert durchlaufen lassen und hab nun 217 fehler gefunden.
Hab leider nicht so viel Ahnung von html.
gruss
Cyberbob
Hab mal den www.fahnen-nostalgieshop.de bei Seitwert durchlaufen lassen und hab nun 217 fehler gefunden.
Hab leider nicht so viel Ahnung von html.
gruss
Cyberbob
Besser ist da wohl https://validator.w3.org/check?uri=...(detect+automatically)&doctype=Inline&group=0
Bzw. noch besser, wenn Du Dir das entsprechende Tdiy HTML Validator Plugin für Firefox holst (wen Du Firefox nutzt).
Viele Fehler wiederholen sich da aber, schaus Dir einfach mal in Ruhe an und behebe es, wenn immer mal Zeit ist. Da sind, wenn ich es richtig überflogen habe, auch fehler drin, die die Funktionalität der Seite einschränken.
ich hab so ein Programm noch nicht gesehen.
Aber wenn du dir den BeschreibungsText von den Fehler durchliest, dann findet man die Fehler eigentlich recht schnell. Wenn du ein Problem mit dem Div-End-Tag hast, dann kann es sein, dass du einen zu viel eingebaut hast. Also dass er ein Div schließen will, es aber keins mehr zu schließen gibt.
Es kann allerdings auch sein, dass der Fehler nur aus einem Fehler weiter vorne resultiert. Also würde ich dir raten, die Fehler von oben nach unten abzuarbeiten. Das erste ist mal die xhtml-Deklinierung am Anfang. Da steht sogar bei der Fehlermeldung dabei, was GENAU du da machen musst
bei weiteren fragen zu den Fehler schreib hier nur, hier gibts genug xHTML-Freakx
Aber wenn du dir den BeschreibungsText von den Fehler durchliest, dann findet man die Fehler eigentlich recht schnell. Wenn du ein Problem mit dem Div-End-Tag hast, dann kann es sein, dass du einen zu viel eingebaut hast. Also dass er ein Div schließen will, es aber keins mehr zu schließen gibt.
Es kann allerdings auch sein, dass der Fehler nur aus einem Fehler weiter vorne resultiert. Also würde ich dir raten, die Fehler von oben nach unten abzuarbeiten. Das erste ist mal die xhtml-Deklinierung am Anfang. Da steht sogar bei der Fehlermeldung dabei, was GENAU du da machen musst
bei weiteren fragen zu den Fehler schreib hier nur, hier gibts genug xHTML-Freakx
Hi,
in dem Link von paulrene sind doch schon Hilfen bei für so gut wie jeden Fehler.
Versuche die einfach mal durchzuarbeiten...
zB:
Da sieht man doch, das das "_blank" kein Anführungszeichen vor dem Wort hat...
muss quasi target="_blank" sein... schon ist ein Fehler ausgemerzt. Und der gleihce Fehler kommt mehrmals im Dokument durch.
Versuhc einfach die Liste durchzuarbeiten und checke dann immer wieder. Die Liste wird dann immer kürzer und nach einer Weile hoffentlich ganz leer... und dann ist alles konform...
-Flori-
Aber 217 Fehler in nem transitional-Dokument is schon hart... bei strict wärens ja sogar 250 oder mehr... wow... Was hast du denn für die Webseite, also Design und CMS bezahlt?
Nachtrag:
Achja, würde dir empfehlen, die Javascript Fehler vielleicht erstmal außen vor zu lassen und dich erstmal um die Fehler im HTML selbst zu kümmern...
in dem Link von paulrene sind doch schon Hilfen bei für so gut wie jeden Fehler.
Versuche die einfach mal durchzuarbeiten...
zB:
Code:
Line 540, Column 496: an attribute specification must start with a name or name token.
…4e08f24ff29439ee1517bc2"target=_blank">Versandkosten</a></noscript></p>Da sieht man doch, das das "_blank" kein Anführungszeichen vor dem Wort hat...
muss quasi target="_blank" sein... schon ist ein Fehler ausgemerzt. Und der gleihce Fehler kommt mehrmals im Dokument durch.
Versuhc einfach die Liste durchzuarbeiten und checke dann immer wieder. Die Liste wird dann immer kürzer und nach einer Weile hoffentlich ganz leer... und dann ist alles konform...
-Flori-
Aber 217 Fehler in nem transitional-Dokument is schon hart... bei strict wärens ja sogar 250 oder mehr...
wow... Was hast du denn für die Webseite, also Design und CMS bezahlt?Nachtrag:
Achja, würde dir empfehlen, die Javascript Fehler vielleicht erstmal außen vor zu lassen und dich erstmal um die Fehler im HTML selbst zu kümmern...
KeinKommentar
Stolzer Webbi :-)
- 13 Juni 2006
- 2.077
- 190
Naja, bindet man Werbung oder einen Bookmark-Dienst ein, hat es sich meistens schon mit der W3C-Konformität.
Ist mir auch relativ egal. Ich merze nur Fehler aus (versuche es zumindest), die Funktionalität, Darstellung & Co. behindern. Ansonsten habe ich wichtigeres zu tun. Muß allerdings auch zugeben, daß mir die Kenntnisse fehlen, einen besonderen Ehrgeiz in diese Richtung zu entwickeln. Das würde ja zur Lebensaufgabe mutieren. Erfreulicherweise hält sich die Zahl der Fehler auch in Grenzen (auf der Startseite 7; auf irgendeiner Menüseite sind es aber deutlich mehr).
Bei manchen Meldungen frage ich mich allerdings, ob der Validator bescheuert ist oder ich. Der will mir z.B. verbieten, nach dem Schließen des Heads den Body zu öffnen. Ist allerdings nur folgerichtig, weil er schon bei </head> meckert, weil er meint, den hätte ich gar nicht geöffnet. Aber naja... wird schon an meinem Unverständnis liegen.
Immerhin ist mein css sauber.
Ist mir auch relativ egal. Ich merze nur Fehler aus (versuche es zumindest), die Funktionalität, Darstellung & Co. behindern. Ansonsten habe ich wichtigeres zu tun. Muß allerdings auch zugeben, daß mir die Kenntnisse fehlen, einen besonderen Ehrgeiz in diese Richtung zu entwickeln. Das würde ja zur Lebensaufgabe mutieren. Erfreulicherweise hält sich die Zahl der Fehler auch in Grenzen (auf der Startseite 7; auf irgendeiner Menüseite sind es aber deutlich mehr).
Bei manchen Meldungen frage ich mich allerdings, ob der Validator bescheuert ist oder ich. Der will mir z.B. verbieten, nach dem Schließen des Heads den Body zu öffnen. Ist allerdings nur folgerichtig, weil er schon bei </head> meckert, weil er meint, den hätte ich gar nicht geöffnet. Aber naja... wird schon an meinem Unverständnis liegen.
Immerhin ist mein css sauber.
Ich persönlich mache immer W3C konform.
Das liegt daran, dass dieses eine Norm ist, an die sich eigentlich jeder Web-Developer halten sollte.
Es gibt in der Computertechnik so viele Normen, stellen wir uns dochmal vor, die Normen für z.B. Computergehäuse würde nicht eingehalten werden und wir müssten uns zu jedem Mainboard immer ein passendes Gehäuse kaufen etc.
Oder auch bei den Protokollen (z.B. TCP/IP). Es ist für mich eine wichtige Sache und eigentlich sollte jeder sich daran halten.
Aber das ist denke ich nur meine Meinung.
Das liegt daran, dass dieses eine Norm ist, an die sich eigentlich jeder Web-Developer halten sollte.
Es gibt in der Computertechnik so viele Normen, stellen wir uns dochmal vor, die Normen für z.B. Computergehäuse würde nicht eingehalten werden und wir müssten uns zu jedem Mainboard immer ein passendes Gehäuse kaufen etc.
Oder auch bei den Protokollen (z.B. TCP/IP). Es ist für mich eine wichtige Sache und eigentlich sollte jeder sich daran halten.
Aber das ist denke ich nur meine Meinung.
ice-breaker
return void
- 27 April 2006
- 6.257
- 585
Man sollte durchaus versuchen die Seite W3C-Konform zu machen, leider ist es nicht immer möglich, gerade wenn man HTML-Markup noch für JavaScript mit Informationen auszeichnen muss.
Genauso sollte aber auch Wert auf Semantisches HTML gelegt werden, was ich teilweise sogar wichtiger als die W3C-Normen finde. Denn wer mal mit dem Handy unterwegs ist, oder wer auf Screenreader angewiesen ist, wird mit diesen tollen Tabellen-Layouts oder sonstigem nicht semantischem Zeug versagen.
Genauso sollte aber auch Wert auf Semantisches HTML gelegt werden, was ich teilweise sogar wichtiger als die W3C-Normen finde. Denn wer mal mit dem Handy unterwegs ist, oder wer auf Screenreader angewiesen ist, wird mit diesen tollen Tabellen-Layouts oder sonstigem nicht semantischem Zeug versagen.
Tyrell
iчɔʇıq
- 24 Mai 2006
- 716
- 173
Ja, alles andere zeugt von dilettantischer Vorgehensweise seitens der Betreiber.
Es würde Dir möglicherweise leicher fallen, wenn Du die Seite in HTML 4 statt XHTML 1.0 gestaltest und was ich jetzt schnell bei der Validator-Ausgabe gesehen habe, beziehen sich viele Fehler auf Inline-Javascript, da solltest Du versuchen den JS-Code in externe Dateien auszulagern oder folgendermaßen zu schreiben:
Das ist die Variante, welche XHTML-Parser und sehr alte Browser berücksichtigt.
Auch sollte man bedenken, dass XHTML auch andere Änderungen mit sich bringt, welche aber bei aktuellen Browsern (IE ausgenommen), nur sichtbar werden, wenn man als Content-Type "application/xml" oder "application/xhtml+xml" sendet (statt "text/html").
HTML:
<script type="text/javascript"><!--//--><![CDATA[//><!--
...
//--><!]]></script>Auch sollte man bedenken, dass XHTML auch andere Änderungen mit sich bringt, welche aber bei aktuellen Browsern (IE ausgenommen), nur sichtbar werden, wenn man als Content-Type "application/xml" oder "application/xhtml+xml" sendet (statt "text/html").
Zuletzt bearbeitet:
KeinKommentar
Stolzer Webbi :-)
- 13 Juni 2006
- 2.077
- 190
Na, da trägst aber schon etwas dick auf. Du stellst - was nicht ganz untypisch für Deutschland und Umgebung ist - Regeln und Form über den Inhalt. Ich weiß ja nicht, wie Du das hältst, wenn Du im I-Net einkaufst, aber ich schaue nicht zuerst auf den Quelltext, sondern auf Preise, AGB, inhaltliche Kompetenz usw.. Selbst die Rechtschreibung ist mit wichtiger als der Code.
Wenn aber funktionale Fehler offenbar werden, überschreitet das bei mir eine Grenze.
Das ist einer der Gründe für den guten Ruf von beispielsweise deutschen Ingenieurleistungen.
Das Problem liegt einfach darin, dass man nur durch Einhaltung von Standards einigermaßen sicher sein kann, dass etwas das heute funktioniert auch in Zukunft noch funktioniert.
Wenn momentan keine funktionalen Fehler auftreten muss das nicht heißen, dass es auch beim nächsten Browser so bleibt.
- 20 April 2006
- 22.682
- 1.316
Also ich sehe zuerst auf den Quellcode (eine Webseite mit 30 Fehlern springt nunmal sofort ins Auge), danach auf die Rechtschreibung (wenn einer der deutschen Sprache nicht mächtig ist, dann sehe ich hier klar Vorsicht angebracht). Erst danach seh ich auf Design (hat einer nur ein paar rechtige Kästen, geh ich davon aus, dass das Abzocke ist, weil er sich kein proffesionelles Design leisten kann/will). Zum Schluss les ich erstmal, was überhaupt mir an Content angeboten wird.
Mir ist klar, dass ein Otto-Normal-Verbraucher, der nicht mal weiß, was "HTML" ist, geschweige dem, wie er den Quellcode anzeigen kann, natürlich nicht so vorgeht.
Ich habe zumindest das Wissen und ich geh eben anders ran. Logisch, ein Profi auf seinem Gebiet sieht Sachen immer anders. Das kannst du auf jeden Bereich anwenden und ist nicht auf Webauftreten beschränkt.
Ein guter (Code [Struktur, Syntax], Design [sinnvolle Anordnung, Grafiken], Content [Rechtschreibung, Interpunktion, Ausdruck]) Webauftritt sagt eben was über den aus, der ihn erstellt hat:
Wurden ordentliche Überlegungen angestellt, wie das Projekt fertig aussehen soll? Wieviel Zeit wurde in die Planung gesteckt, bevor die erste Codezeile geschrieben wurde und der Designer den ersten Pixel gepinselt hat? Wurde das Projekt von einem proffesionellen Team umgesetzt oder wusste der 1-Mann-Noob-Programmierungbetrieb mal nicht weiter und hat 20 andere verschiedene Leute mal draufgucken lassen, nur um kostenfrei sein Problem gelöst zu kriegen? Wurde ordentlich getestet (@KeinKommentar: das sind dann deine funktionialen Fehler, die du das erst bemerkst)? Oder ist das Projekt schnellschnell online genommen; so nach dem Motto "Fehler kann man ja im laufenden Betrieb immer noch beheben"?
Ok, hab ich wieder groß einen Aufsatz geschrieben
Nochmal kurz: Ordentlicher Code sagt viel mehr aus, als nur "ich beheb halt schnell ein paar Validator-Fehler".
Tyrell
iчɔʇıq
- 24 Mai 2006
- 716
- 173
Mag sein. Ich behaupte einfach mal, dass ich vom Fach bin. Daher sehe ich solche Sachen etwas strenger. Ob das nun typisch für Deutschland und Umgebung ist, halte ich für ein Klischee - kann also etwas dran sein. Dass ich Form über Inhalt stelle, habe ich an keiner Stelle erwähnt, das entspringt frei deiner Interpretation. Trotzdem bleibe ich dabei - wer keinen sauberen Code erzeugt, wirkt unprofessionell. Und selbst wenn es Amazon ist (>1200 Fehler auf der Startseite), zeigt es, dass sich die Verantwortlichen nicht mit den Standards auseinander gesetzt haben. Um wieder darauf zurückzukommen, dass ich vom Fach bin: Wer sich nicht an Standards hält, bekommt früher oder später Probleme. Meistens später, dafür umso teurer. Das ist ein Erfahrungswert.
In der IT wurden in den letzten 30 Jahren ausschließlich Frickel-Lösungen entwickelt, die günstig waren und funktionierten. Bei den meisten Systemen hat man später festgestellt, dass man lieber einen Tausender mehr investiert hätte, dann wäre alles viel besser. Im Endeffekt bin ich dankbar dafür, denn die Korrekturen dieser Systeme kosten weltweit Milliarden. Dieses Geld geht an die Leute, welche diese Korrekturen durchführen. Z.B. diejenigen, die vom Fach sind
KeinKommentar
Stolzer Webbi :-)
- 13 Juni 2006
- 2.077
- 190
Hacker, beim Lesen Deines ersten Absatzes habe ich zuerst gedacht, Du willst mich auf die Schippe nehmen, so "weltfemd" wirkte der Text auf mich. Mittlerweile denke ich aber, Du hast das ernst gemeint.... Wenn Du jetzt noch schreibst, Du gibst 30% mehr für eine Sache aus, weil der Code der entsprechenden Seite "am schönsten" ist, bin sogar bereit, auch das zu glauben.
An sich ist alles schlüssig, was ihr schreibt. Wir betrachten die Sache nur aus verschiedenen Blickwinkeln. Ich habe eher die Sicht des User, Käufers, Verbrauchers eingenommen. Der schaut nicht in den Quelltext oder läßt den Codechecker drüberlaufen. Solange alles funzt, ist dem das völlig egal. Und auch völlig zurecht. Daher hat in der Gegenrichtung restlos W3C-konformer Code keine so hohe Priorität für mich. Ich meine, ich habe mich zwar auch schon mal über den Checker gesetzt und alle Fehler behoben, die ich mit erträglichem Aufwand beseitigen konnte. So ist ja nun nicht. Aber Inhalte erachte ich insgesamt als wichtiger.
Hinzu kommt, daß ja nur ein kleiner Teil der Leute die Sachen wirklich selbst programmieren. Im gewissen Sinne geht der Vorwurf dann an Deine eigene Zunft, Tyrell. Wenn Du Dir einfach mal den Code meiner Seite anschaust, wirst Du - völlig zurecht - die Hände vors Gesicht schlagen. Und ich habe nie darauf geachtet, daß es möglichst billig wird. Ich wollte es schon so gut wie möglich haben. Das jetzt zu korrigieren, wäre in der Tat mit dem von Dir angesprochenen unverhältnismäßigen Aufwand verbunden. Nur interessieren die Unzulänglichkeiten weder google noch meine Besucher. Die wollen sich nicht über sauberen Code informieren, sondern über Redensarten.
Aber vermutlich sprechen wir auch von verschiedenen Größenordnungen. Der Threadersteller schien eher von kleinen Seiten zu sprechen (ich auf jeden Fall), Du kommst mit amazon und Investitionen im hohen Bereich.
Naja, sind wir nicht alle in irgendeinem Bereich "Fachidioten" mit der entsprechenden, für Außenstehende etwas seltsam anmutenden Sicht auf die Dinge?
btw: Aus reinem Zufall habe ich bei meiner neuen Spielwiese strict als doctype erwischt. Zufall meint, daß ich darauf nicht geachtet habe... Wäre es angesichts meiner - ich will es mal "praxisnahen" nennen - Sichtweise besser, auf transi umzustellen?
An sich ist alles schlüssig, was ihr schreibt. Wir betrachten die Sache nur aus verschiedenen Blickwinkeln. Ich habe eher die Sicht des User, Käufers, Verbrauchers eingenommen. Der schaut nicht in den Quelltext oder läßt den Codechecker drüberlaufen. Solange alles funzt, ist dem das völlig egal. Und auch völlig zurecht. Daher hat in der Gegenrichtung restlos W3C-konformer Code keine so hohe Priorität für mich. Ich meine, ich habe mich zwar auch schon mal über den Checker gesetzt und alle Fehler behoben, die ich mit erträglichem Aufwand beseitigen konnte. So ist ja nun nicht. Aber Inhalte erachte ich insgesamt als wichtiger.
Hinzu kommt, daß ja nur ein kleiner Teil der Leute die Sachen wirklich selbst programmieren. Im gewissen Sinne geht der Vorwurf dann an Deine eigene Zunft, Tyrell. Wenn Du Dir einfach mal den Code meiner Seite anschaust, wirst Du - völlig zurecht - die Hände vors Gesicht schlagen. Und ich habe nie darauf geachtet, daß es möglichst billig wird. Ich wollte es schon so gut wie möglich haben. Das jetzt zu korrigieren, wäre in der Tat mit dem von Dir angesprochenen unverhältnismäßigen Aufwand verbunden. Nur interessieren die Unzulänglichkeiten weder google noch meine Besucher. Die wollen sich nicht über sauberen Code informieren, sondern über Redensarten.
Aber vermutlich sprechen wir auch von verschiedenen Größenordnungen. Der Threadersteller schien eher von kleinen Seiten zu sprechen (ich auf jeden Fall), Du kommst mit amazon und Investitionen im hohen Bereich.
Naja, sind wir nicht alle in irgendeinem Bereich "Fachidioten" mit der entsprechenden, für Außenstehende etwas seltsam anmutenden Sicht auf die Dinge?
btw: Aus reinem Zufall habe ich bei meiner neuen Spielwiese strict als doctype erwischt. Zufall meint, daß ich darauf nicht geachtet habe... Wäre es angesichts meiner - ich will es mal "praxisnahen" nennen - Sichtweise besser, auf transi umzustellen?
Zuletzt bearbeitet:
Tyrell
iчɔʇıq
- 24 Mai 2006
- 716
- 173
Man sollte immer schauen, in welchen Dimensionen sich die Seite bewegt. Wenn es sich um eine Privatseite handelt, ist es mir relativ egal, wie der Quellcode aussieht. Da trifft es wirklich niemanden, wenn ein paar Fehler drin sind.
Bei kommerziellen oder öffentlichen Seiten schaut das anders aus. Menschen mit körperlichen Einschränkungen sind evtl. auf einen Screenreader angewiesen. Bei syntaktisch und semantisch falschem Seitenaufbau wird das Benutzen der Website zu einer Tortur. Natürlich kann man sagen, man schert sich nicht weiter um ein paar blinde Surfer - wie viele sind das schon? Aber der Gedanke, das Internet so zu gestalten, dass es alle benutzen können, ist meiner Ansicht nach erstrebenswert. Sicherlich können die Leute auf ein paar Privatseiten verzichten, aber vielleicht will auch ein Blinder mal einen Telefonanschluss bestellen oder eine Bahnverbindung suchen. Da wirds dann schonmal schwierig.
Falscher Quellcode bringt Probleme mit sich. Manchmal größere, kleinere, verborgene, offensichtliche, manchmal erst nach Jahren. Diese Probleme verursachen Kosten, sind unwirtschaftlich und auch unsozial - sie schließen andere Menschen aus.
In den kleinen privat-Dimensionen ist es eine Frage, ob man noch ein bisschen Zeit reininvestiert und vernünftigen Code schreibt. Bei größeren und kommerziellen Projekten ist es stets eine Kostenfrage. Und die Kosten werden üblicherweise so gering wie möglich gehalten.
Und zur Sicht als User und Verkäufer: Damals wurden die Seiten stets "für den Internetexplorer optimiert". Was soviel hieß wie: Es wurde solange gepuzzelt, bis zumindest im IE die Seite einigermaßen anzeigbar war. Auch diese Holzhammermethode ist irgendwann ausgestorben. Man hat den Firmen immer erzählt, dass z.B. Apple-User die Seite nicht anzeigen können, diese aber nur 1-2% der Benutzer ausmachten. Irgendwann hat man dann festgestellt, dass Apple-User aber die meiste Kohle hatten und eher potentielle Käufer waren (die dann den Webshop aber nicht nutzen konnten), als der verarmte IE-Benutzer. Das hat sich rumgesprochen und mittlerweile lassen sich die wenigsten Unternehmen damit über den Tisch ziehen. Irgendwann werden sie auch feststellen, dass schlechter Code Kosten nach sich zieht und auch das wird sich dann irgendwann ändern.
Bei kommerziellen oder öffentlichen Seiten schaut das anders aus. Menschen mit körperlichen Einschränkungen sind evtl. auf einen Screenreader angewiesen. Bei syntaktisch und semantisch falschem Seitenaufbau wird das Benutzen der Website zu einer Tortur. Natürlich kann man sagen, man schert sich nicht weiter um ein paar blinde Surfer - wie viele sind das schon? Aber der Gedanke, das Internet so zu gestalten, dass es alle benutzen können, ist meiner Ansicht nach erstrebenswert. Sicherlich können die Leute auf ein paar Privatseiten verzichten, aber vielleicht will auch ein Blinder mal einen Telefonanschluss bestellen oder eine Bahnverbindung suchen. Da wirds dann schonmal schwierig.
Falscher Quellcode bringt Probleme mit sich. Manchmal größere, kleinere, verborgene, offensichtliche, manchmal erst nach Jahren. Diese Probleme verursachen Kosten, sind unwirtschaftlich und auch unsozial - sie schließen andere Menschen aus.
In den kleinen privat-Dimensionen ist es eine Frage, ob man noch ein bisschen Zeit reininvestiert und vernünftigen Code schreibt. Bei größeren und kommerziellen Projekten ist es stets eine Kostenfrage. Und die Kosten werden üblicherweise so gering wie möglich gehalten.
Und zur Sicht als User und Verkäufer: Damals wurden die Seiten stets "für den Internetexplorer optimiert". Was soviel hieß wie: Es wurde solange gepuzzelt, bis zumindest im IE die Seite einigermaßen anzeigbar war. Auch diese Holzhammermethode ist irgendwann ausgestorben. Man hat den Firmen immer erzählt, dass z.B. Apple-User die Seite nicht anzeigen können, diese aber nur 1-2% der Benutzer ausmachten. Irgendwann hat man dann festgestellt, dass Apple-User aber die meiste Kohle hatten und eher potentielle Käufer waren (die dann den Webshop aber nicht nutzen konnten), als der verarmte IE-Benutzer. Das hat sich rumgesprochen und mittlerweile lassen sich die wenigsten Unternehmen damit über den Tisch ziehen. Irgendwann werden sie auch feststellen, dass schlechter Code Kosten nach sich zieht und auch das wird sich dann irgendwann ändern.
Nur mal so als Kommentar am Rande: Im Schnitt hat jeder 10 Bundesbürger eine
anerkannte Behinderung. Und das sind nicht nur blinde Surfer, sondern auch
Menschen mit motorischen Störungen die z.B. froh sind, wenn sich eine Webseite
sauber über die Tastatur bedienen lässt, da die Maus beim Klicken immer so zuckt.
anerkannte Behinderung. Und das sind nicht nur blinde Surfer, sondern auch
Menschen mit motorischen Störungen die z.B. froh sind, wenn sich eine Webseite
sauber über die Tastatur bedienen lässt, da die Maus beim Klicken immer so zuckt.
KeinKommentar
Stolzer Webbi :-)
- 13 Juni 2006
- 2.077
- 190
Tyr, ich hatte Deine Argumentation doch schon beim ersten Mal verstanden und anerkannt. Daß ich trotzdem teilweise anderer Meinung bin, ändert daran nichts.
Ist wohl Definitionsfrage, aber wenn eine Seite z.B. nicht in einem geläufigen Browser angezeigt werden kann, fällt das für mich eindeutig in den funktionalen Bereich. Sprich: Solche Fehler würde ich auch zu beheben versuchen, sofern sie mir bekannt sind. (Habe z.B. null Plan, wie gut oder schlecht meine Seite als Behinderter zu handhaben ist. Kann mir bei dem Code allerdings nicht vorstellen, daß es ein Vergnügen ist.)
Bitte den Ausgangspunkt nicht außer Acht lassen: Wir sprachen von vollkommener W3C-Konformität. Und die halte ich nach wie vor für nicht zwingend notwendig. Nicht in Bezug auf den Inhalt, nicht aus SEO-Sicht, nicht als User.
Tyr, um meinen Standpunkt verstehen zu können, mußt Du etwas abstrahieren. Du siehst es - bei allen berechtigten Argumenten - immer noch zu sehr mit den Augen eines Profis. Ein paar Beispiele: Der gewöhnliche kleine Webmaster (so wie ich z.B.) kann W3C-Konformität eben nicht dadurch erreichen, daß er "noch ein bisschen Zeit reininvestiert". Das kann gegenteilig schnell zur - überspitzt formuliert - Lebensaufgabe mutieren. Bei Fehlern, die die Funktionalität nicht spürbar behindern, stehen Aufwand und Nutzen in keinem sinnvollen Verhältnis. Natürlich könnte ich tagelang versuchen, die JS- und sonstigen Fehler zu beheben, an denen ich mir im ersten Durchgang die Zähne ausgebissen habe. Ich könnte mich aber in der Zeit auch um Inhalte kümmern, wovon meine Leser sehr wahrscheinlich mehr haben. Natürlich könnte ich den schrecklichen Code meiner Seite (und das ist er wirklich) grundsätzlich überarbeiten. Aber da müßte ich erst einmal Monate php & Co lernen. Für jede auch für mich leicht umzusetzende Verbesserung bin ich natürlich immer offen.
Mag vielleicht noch jemand auf meine Frage zum doctype antworten?
Ist wohl Definitionsfrage, aber wenn eine Seite z.B. nicht in einem geläufigen Browser angezeigt werden kann, fällt das für mich eindeutig in den funktionalen Bereich. Sprich: Solche Fehler würde ich auch zu beheben versuchen, sofern sie mir bekannt sind. (Habe z.B. null Plan, wie gut oder schlecht meine Seite als Behinderter zu handhaben ist. Kann mir bei dem Code allerdings nicht vorstellen, daß es ein Vergnügen ist.)
Bitte den Ausgangspunkt nicht außer Acht lassen: Wir sprachen von vollkommener W3C-Konformität. Und die halte ich nach wie vor für nicht zwingend notwendig. Nicht in Bezug auf den Inhalt, nicht aus SEO-Sicht, nicht als User.
Tyr, um meinen Standpunkt verstehen zu können, mußt Du etwas abstrahieren. Du siehst es - bei allen berechtigten Argumenten - immer noch zu sehr mit den Augen eines Profis. Ein paar Beispiele: Der gewöhnliche kleine Webmaster (so wie ich z.B.) kann W3C-Konformität eben nicht dadurch erreichen, daß er "noch ein bisschen Zeit reininvestiert". Das kann gegenteilig schnell zur - überspitzt formuliert - Lebensaufgabe mutieren. Bei Fehlern, die die Funktionalität nicht spürbar behindern, stehen Aufwand und Nutzen in keinem sinnvollen Verhältnis. Natürlich könnte ich tagelang versuchen, die JS- und sonstigen Fehler zu beheben, an denen ich mir im ersten Durchgang die Zähne ausgebissen habe. Ich könnte mich aber in der Zeit auch um Inhalte kümmern, wovon meine Leser sehr wahrscheinlich mehr haben. Natürlich könnte ich den schrecklichen Code meiner Seite (und das ist er wirklich) grundsätzlich überarbeiten. Aber da müßte ich erst einmal Monate php & Co lernen. Für jede auch für mich leicht umzusetzende Verbesserung bin ich natürlich immer offen.
Mag vielleicht noch jemand auf meine Frage zum doctype antworten?