nicht angemeldet
Hi Sven
Bei der Validität geht es keinesfalls darum, vom Validator ein OK zu kriegen, sondern darum, ordentlichen (X)HTML-Code zu produzieren - egal, mit welchen Mitteln.
Wie Du auf meiner Seite feststellen kannst sind sämtliche php und html dokumente XHTML konform valid ohne beschiss... das einzige was gestört hat war das Frameset welches UNMÖGLICH valid sein kann wenn man auf die weissen balken verzichten möchte.
Einige hier im Forum sind der Meinung eine Seite verdient dass W3C Valid logo nicht wenn das Frameset invalid ist. Was hier geschied ist Grauzone und interpretatiosnsache. Streng genommen IST das Frameset VALID weil es vom Parser IMMER als valid angenommen wird. Was jedoch auch stimmt ist, dass es zur Laufzeit Invalid wird. Das File ist als solches Valid aber nicht zur Laufzeit. Wie bewertet man denn nun ein valid HTML file? ist es valid wenn es in seiner ursprünglichen Form ist oder wenn es ausgefürt wird? wann wird das bestimmt? Ich denke eher in seiner ursprünglichen Form...
Dein Trick ist Betrug und zählt nicht.
Betrug? Ja sicher aber das File is in seiner Ursprungsform Valid. Desshalb darf man dem File das Siegel Valid verpassen.
Angenommen, in einer Welt würde es Regeln für gültige Briefe und Briefumschläge geben. Dann hättest du einen gültigen Briefumschlag - der Inhalt des Umschlags wird aber garnicht geprüft, obwohl der enthaltene Brief ungültig ist. Du darfst dich deshalb nicht wundern, wenn dein Brief bei manchem Leser auf Unverständnis stößt. Hättest du gleich den Brief auf Gültigkeit prüfen lassen und erst dann in den Umschlag gesteckt, würde sowas nicht passieren.
So kann man das ned vergleichen. Es ist mehr in einer Welt in der man den Brief schreibt jemand schaut ihn an ob er legal ist und kommt zum schluss ja. Jetzt gibt man den Brief an den Empfänger und dieser überschreibt den Brief und streicht einige passagen. Desshalb wird der Brief noch 1000 mal beim Prüfamt vorbeigehen und jedesmal legal sein, weil erst der Empfänger drin rumkritzelt...
Abgesehen davon hat dein Trick zwei Fehler - einen grundsätzlichen, und einen praktischen:
- Grundsätzlich ist es immer sehr problematisch, wenn man sich relevante Teile einer Seite per Javascript erstellen läßt. Das kann ins Auge gehen und setzt nur unnötig die Anforderungen an den User-Agent hoch. Es gibt Leute, die Javascript ausgeschaltet haben. Und es ist anzustreben, eine Seite möglichst ohne Javascript funktionieren zu lassen, wenn auch nicht mit den letzten optischen Features.
In diesem Fall nicht, da hier die Interne Fehlerbeseitigung der Browser in Kraft tritt. Alle Heutigen Broswer merken dass man "versehentlich" ein zweites frameset definiert hat und einen 2. head (head ist auch im script vercoded und darum kein fehler erst das zweite head ist falsch)
- Ganz praktisch gesehen erzeugt deine Lösung falsches HTML. Du schreibst das JS-Frameset noch innerhalb vom <HEAD> - da gehört es aber absolut nicht hin. Dummerweise kann das kein Validator bemerken - außer man kopiert den entstandenen Quelltext aus der Netscape-Quelltextansicht und läßt diesen validieren. Ich möchte nicht wissen, was da dann gemeckert wird.
Zeigt Netscape den Quelltext richtig an nachdem document write was reinschreibt?
Ganz grundsätzlich ist festzuhalten:
- Tricks in Javascript, die Validität vortäuschen, sind dumm, weil sie Fehler maskieren, die schwerwiegend sein können.
Sind sie in dem Fall jedoch nicht. Es sind Fehler die ohne probleme von allen browsern erkannt werden.
- Es ist allgemein anerkannt, daß man funktionierende und ordentlich aussehende Framesetdefinitionen nicht valide machen kann, weil die Browser andere, unerlaubte Angaben erfordern als der Standard vorsieht. Ein Tricksen in dieser Richtung ist deshalb vollkommen überflüssig.
Dennoch gibts genug Trüffel die rummotzen wenn ein frameset nicht valide ist. Das war mir zu blöd :-)
- Sven Rautenberg
Gruss Christoph