Cheatah: Das W3C und HTML 4

Hallo,

nachdem ich nun meine neu designeten Seiten durch den W3C-Validator (http://validator.w3.org/) gejagt habe, bin ich nicht mehr so ganz sicher, was ich vom W3C halten soll. Zwar wurden mir einige tatsächliche Fehler klargemacht, aber anderes halte ich für ziemlich unsinnig. Als Fehler bezeichne ich hier, was beide großen Browser korrekt darstellen, aber vom W3C als falsch markiert wird - und wofür es offenbar keine Lösung gibt. Folgendes fiel mir auf:

  • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?
  • <noframes> scheint auch falsch zu sein. Muß man das durch <body> ersetzen?
  • Bei <img> wird der Parameter name beanstandet. Ist der wirklich falsch? Ich brauche das für wartungsarme JavaScript-Funktionen (images[x] fällt flach, weil ich das ggf. in vielen Seiten ändern müßte).
  • Ziemlich krass: Bei Countergrafiken wird jedes "&" angemeckert (z.B. <img src="count.pl?id=cheatah&counter=test">, da ist ein "&" drin...). Begründung: "general entity 'counter' [in diesem Fall] not defined and no default entity". Die Erklärung dazu ist folgende (http://www.cs.duke.edu/~dsb/kgv-faq/errors.html#bad-entity):

--- snip ---
A URL for a CGI program that uses `&' as a separator, such as "http://host/prog?x=1&y=2". Gerald writes:

This is a common problem: the inventors of CGI didn't think things through very carefully when they decided to use the '&' character as a separator between CGI arguments, because '&' has special status in HTML.

The only way to get around this is for the author of the CGI program to use a different value between arguments, like ';' or '', which would allow the link to be coded as <img src="http://site/cgi?opt1=val1;opt2=val2"> or whatever.

Please contact the maintainer of the CGI program you are linking to, and ask them to use a different character for their separator. (Normally this is extremely easy to add to the CGI program; multiple characters can also be used so existing links using the '&' character will still work.)
--- snip ---

Mit anderen Worten: Die Erfinder von CGI waren zu blöd, um über ihren Tellerrand zu schauen. So lange ich CGI kenne sind mir aber fast ausschließlich "&"s als Trennung zwischen Parametern untergekommen, deswegen kann man den Fehler wohl kaum den Programmierern von Scripts anlasten. Das W3C glaubt hier offenbar, die "älteren Rechte" zu haben, weil HTML vor CGI da war. Aber war HTML 4 auch vor CGI da?

Weiter im Text:

  • <table height="100%"> ist offenbar nicht erlaubt. Wie kriege ich den Seiteninhalt sonst an den unteren Bildschirmrand, und zwar so, daß es auch zu HTML 3.2 (zumindest) bzw. der Interpretation der Browser kompatibel bleibt?
  • Mit <script> hat W3C offenbar arge Probleme... man sehe sich nur mal http://validator.w3.org/check?uri=http%3A%2F%2Fcheatah.net%2Ftest%2Fwerbung.htm an! Die entsprechende Seite erzeugt mit JavaScript eine Tabelle, die soweit ich das sehe HTML 4 ready ist. Die Fehlermeldungen aber "beweisen" das Gegenteil...

Fazit:
Nur eine einzige Seite von denen, die bei http://cheatah.net/test angezeigt werden, ist HTML 4 ready, nämlich http://validator.w3.org/check?uri=http%3A%2F%2Fcheatah.net%2Ftest%2Fsubmenu.htm (die Hauptseite habe ich gar nicht erst geprüft, die ist sowieso "alter Schrott"). Dort mußte ich aber auch erst die Reihenfolge <table><form>...</form></table> umkehren, obwohl sich das für manche Fälle als unvermeidbar erwies. Naja.

Meine Meinung:
Ich werde weiterhin versuchen, HTML 4 einzuhalten. So wie ich das sehe, hat aber das W3C noch einiges an ihrem aktuellen Standard zu tun.

Ich bin gespannt, was andere dazu meinen :-) Testet doch mal eure Seite mit dem Validator! Vermutlich werdet ihr überrascht sein...

Cheatah

  1. Hallo Cheatah! (wieder mal ;-) !)

    Ich hatte mal "unerklärliche" Fehlermeldungen bei mir; bis ich daraufkam,
    dass dem Validator von W3C es nicht egal war WIE man die doctype-Angabe
    schreibt.
    Dies führte immer zu Fehlermeldungen.
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
    "http://www.w3.org/TR/REC-html40/loose.dtd">

    Diese wurde dann endlich angenommen.
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
                   "http://www.w3.org/TR/REC-html40/loose.dtd">

    Warum das so ist kann ich mir nicht erklären. Laut W3C gehört <noframes>
    innerhalb vom <frameset>. Aber das hatten wir mal hier.

    Grüße
    Thomas

    1. Hi Thomas,

      Ich hatte mal "unerklärliche" Fehlermeldungen bei mir; bis ich daraufkam,
      dass dem Validator von W3C es nicht egal war WIE man die doctype-Angabe
      schreibt.
      Dies führte immer zu Fehlermeldungen.

      bei mir steht der ganze Doctype in einer Zeile und wird auch korrekt erkannt. Die meisten Fehlermeldungen (bis auf die im JavaScript) kann ich auch erklären, nur gibt es offenbar keine Lösung...

      Warum das so ist kann ich mir nicht erklären. Laut W3C gehört <noframes>
      innerhalb vom <frameset>. Aber das hatten wir mal hier.

      Oh, das hatte ich auch noch nicht gewußt. Wohl überlesen... Danke für den Tip!

      Cheatah

  2. Hallo Cheatah,

    nachdem ich nun meine neu designeten Seiten durch den W3C-Validator (http://validator.w3.org/) gejagt habe, bin ich nicht mehr so ganz sicher, was ich vom W3C halten soll.

    Ich weiss schon, warum ich Seiten ungern durch Validatoren jage, die die Praxisumsetzungen in den Browsern nicht beruecksichtigen. Aber ob der obige Validator wirklich die HTML4-Spec kennt, wage ich nach Deinen Beschreibungen auch zu bezweifeln. Zum Beispiel ist es nach der Spec durchaus erlaubt, beim Attribut width= im Zusammenhang mit <table> Prozentangaben zu benutzen (vgl. http://195.214.83.11/w3c-html/struct/tables.html#adef-width-TABLE). Allerdings sind viele Validatoren erst zufrieden, wenn Prozentwerte in Anfuehrungszeichen stehen.

    Ich persoenlich halte es fuer sehr wichtig, dass es Spezifikationen fuer Sprachen wie HTML, CSS usw. gibt. Aber es ist halt wie mit allen Gesetzen und der Juristerei. Man kann zigtausend Seiten mit Regularien vollschreiben, und es bleibt immer noch Interpretationsspielraum. Die Anzahl der Interpretationsspielraeume waechst sogar proportional zur Anzahl der Regeln, die gesetzt werden, um Interpretationsspielraeume zu verkleinern. Plastischer ausgedrueckt: je feiner die Gesetze und je mehr davon, desto mehr Juristen sind erforderlich, um bei Auffassungsunterschieden zu entscheiden. Deshalb halte ich es beim Web Publishing pragmatisch: jeder, der sich ernsthaft mit Web Publishing auseinandersetzt, sollte die Spezifikationen kennen und wissen, wie man darin etwas nachschlaegt. Aber wenn man damit nicht weiterkommt oder wenn das, was darin steht, nun mal unvereinbar ist mit dem, was man beim Austesten mit Browsern erlebt, dann muss man halt auch mal was anders machen, als es dort steht.

    Das Rumreiten auf den Specs, wie man es in Newsgroups zuhauf zu lesen bekommt, halte ich jedenfalls fuer krankhaft. Die Specs stammen auch nur von Menschen und nicht von Goettern. Genau sie SELFHTML <g>.

    viele Gruesse
      Stefan Muenz

    1. Hi Stefan,

      Ich weiss schon, warum ich Seiten ungern durch Validatoren jage, die die Praxisumsetzungen in den Browsern nicht beruecksichtigen. Aber ob der obige Validator wirklich die HTML4-Spec kennt, wage ich nach Deinen Beschreibungen auch zu bezweifeln. Zum Beispiel ist es nach der Spec durchaus erlaubt, beim Attribut width= im Zusammenhang mit <table> Prozentangaben zu benutzen

      nein, das ist nicht das Problem - die Angabe war HEIGHT=, unabhängig vom Wert! Ich vermute mal, daß <table height=x> nicht regelkonform ist, ich frage mich aber, warum?

      Allerdings sind viele Validatoren erst zufrieden, wenn Prozentwerte in Anfuehrungszeichen stehen.

      Ich habe vor dem Check alle Parameterwerte in Anführungszeichen gesetzt, eben genau deswegen... :-)
      Schwieriger ist es übrigens mit Dateiangaben, die außerhalb des aktuellen Pfades sind. Da steht dann nämlich ein / drin, und das ist ein Endezeichen für den Tag...

      Ich persoenlich halte es fuer sehr wichtig, dass es Spezifikationen fuer Sprachen wie HTML, CSS usw. gibt. [...] Aber wenn man damit nicht weiterkommt oder wenn das, was darin steht, nun mal unvereinbar ist mit dem, was man beim Austesten mit Browsern erlebt, dann muss man halt auch mal was anders machen, als es dort steht.

      Wie wahr, wie wahr. Es ist nur traurig zu sehen, daß der Standard, an den man sich halten sollte(!) praxisfern ist...

      Das Rumreiten auf den Specs, wie man es in Newsgroups zuhauf zu lesen bekommt, halte ich jedenfalls fuer krankhaft. Die Specs stammen auch nur von Menschen und nicht von Goettern. Genau sie SELFHTML <g>.

      *lol* :-)

      Danke,

      Cheatah

  3. Hi,

    • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

    Laß es doch einfach drin.
    Unbekannte Parameter müssen laut W3C ignoriert werden - schaden kann es also nichts... :-)

    • Bei <img> wird der Parameter name beanstandet. Ist der wirklich falsch? Ich brauche das für wartungsarme JavaScript-Funktionen (images[x] fällt flach, weil ich das ggf. in vielen Seiten ändern müßte).

    Ich nehme mal stark an, daß das W3C hier lieber ein ID=... sehen würde...

    • Ziemlich krass: Bei Countergrafiken wird jedes "&" angemeckert

    Na, dann sollen sie mal meckern... Ich kann mir nicht vorstellen, daß jetzt alle ihre Parametertrennung umstellen, nur weil das dem W3C jetzt so einfiel...

    Das W3C glaubt hier offenbar, die "älteren Rechte" zu haben, weil HTML vor CGI da war. Aber war HTML 4 auch vor CGI da?

    Da müßte man mal nachschauen, wann dieser &-Stuß vom W3C "erfunden" wurde. Vielleicht ist ja schon in älteren http-Spezies was drin, daß die cgi-ler übersehen hatten...

    • <table height="100%"> ist offenbar nicht erlaubt. Wie kriege ich den Seiteninhalt sonst an den unteren Bildschirmrand, und zwar so, daß es auch zu HTML 3.2 (zumindest) bzw. der Interpretation der Browser kompatibel bleibt?

    Eigentlich gar nicht...
    Das height=... funktioniert zwar, aber besonders genial find' ich's auch nicht...
    Sind Frames nicht eine bessere Lösung? Und zur Not kann das in der unteren Tabellenhälfte doch auch drangeklatscht sein, oder?

    • Mit <script> hat W3C offenbar arge Probleme...

    Hab' mir jetzt deine Seite nicht angeschaut...
    Kann's sein daß du den Code nicht auskommentiert hast?

    Meine Meinung:
    Ich werde weiterhin versuchen, HTML 4 einzuhalten. So wie ich das sehe, hat aber das W3C noch einiges an ihrem aktuellen Standard zu tun.

    Naja... der W3C-Standard ist ja ein "das sollte funktionieren", es erlaubt aber auch eigene Erweiterungen...

    Ich bin gespannt, was andere dazu meinen :-) Testet doch mal eure Seite mit dem Validator! Vermutlich werdet ihr überrascht sein...

    Ich werde mich hüten!
    Ich frage nämlich den Browser ab, und wenn das nicht einer der neueren ist, kommt eine "Not-Version" mit FONT-Tags... die kann das W3C afaik nicht ausstehen... dazu kommen noch ein paar kleine IE/Netscape-Feinheiten...

    Ciao,
    Mirko

    1. Hi Mirko,

      • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

      Laß es doch einfach drin.
      Unbekannte Parameter müssen laut W3C ignoriert werden - schaden kann es also nichts... :-)

      klar :-)
      Ich lasse sie auch drin, nur denke ich daß das W3C eine alternative Möglichkeit vorsehen sollte. Die gibt es aber anscheinend nicht. Nebenbei ist es auch ein ganz nettes Gefühl, W3C-konform programmiert zu haben. Den präsentierten Button kann man als (echten!) Award ansehen. Eine Seite hat ihn bei mir verdient, aber der Rest nicht... :-)

      • Bei <img> wird der Parameter name beanstandet. Ist der wirklich falsch? Ich brauche das für wartungsarme JavaScript-Funktionen (images[x] fällt flach, weil ich das ggf. in vielen Seiten ändern müßte).

      Ich nehme mal stark an, daß das W3C hier lieber ein ID=... sehen würde...

      Hab ich schon versucht, aber dann funktioniert die Referenzierung nicht mehr => wertlos.

      • Ziemlich krass: Bei Countergrafiken wird jedes "&" angemeckert

      Na, dann sollen sie mal meckern... Ich kann mir nicht vorstellen, daß jetzt alle ihre Parametertrennung umstellen, nur weil das dem W3C jetzt so einfiel...

      Ja, das vermute ich auch *g*

      Das W3C glaubt hier offenbar, die "älteren Rechte" zu haben, weil HTML vor CGI da war. Aber war HTML 4 auch vor CGI da?

      Da müßte man mal nachschauen, wann dieser &-Stuß vom W3C "erfunden" wurde. Vielleicht ist ja schon in älteren http-Spezies was drin, daß die cgi-ler übersehen hatten...

      HTML 4 hat den Vorteil, daß man die Fehler von HTML 3.2 korrigieren konnte. Wenn nun dieser &-Stuß (schöner Begriff *g*) als falsch akzeptiert wird, brauchte man es in HTML 4 nicht zu übernehmen. Vor allem vermute ich aber, daß das & früher nicht explizit verboten war. Zumindest in URLs, denn das sind Adressen, die auf einem Server gelten müssen, nicht in einem Dokument. Meiner Meinung nach überschreitet das W3C hier seine Kompetenzen.

      • <table height="100%"> ist offenbar nicht erlaubt. Wie kriege ich den Seiteninhalt sonst an den unteren Bildschirmrand, und zwar so, daß es auch zu HTML 3.2 (zumindest) bzw. der Interpretation der Browser kompatibel bleibt?

      Eigentlich gar nicht...
      Das height=... funktioniert zwar, aber besonders genial find' ich's auch nicht...

      Naja, ich auch nicht. Aber was soll man sonst machen? Und width funktioniert doch schließlich auch...

      Sind Frames nicht eine bessere Lösung? Und zur Not kann das in der unteren Tabellenhälfte doch auch drangeklatscht sein, oder?

      Ich möchte in einem _Frame_ ein Objekt unten darstellen... und nun? :-)
      Schau's Dir am besten mal selbst an: http://cheatah.net/test, der Frame oben links (mit dem WebHits-Logo). Die beiden Grafiken sollen einfach nur in dem Frame unten rechts sein.

      • Mit <script> hat W3C offenbar arge Probleme...

      Hab' mir jetzt deine Seite nicht angeschaut...
      Kann's sein daß du den Code nicht auskommentiert hast?

      Doch, da war ich streng.

      Meine Meinung:
      Ich werde weiterhin versuchen, HTML 4 einzuhalten. So wie ich das sehe, hat aber das W3C noch einiges an ihrem aktuellen Standard zu tun.

      Naja... der W3C-Standard ist ja ein "das sollte funktionieren", es erlaubt aber auch eigene Erweiterungen...

      Trotzdem sollte der _Standard_ nicht realitätsfern sein...

      Ich bin gespannt, was andere dazu meinen :-) Testet doch mal eure Seite mit dem Validator! Vermutlich werdet ihr überrascht sein...

      Ich werde mich hüten!
      Ich frage nämlich den Browser ab, und wenn das nicht einer der neueren ist, kommt eine "Not-Version" mit FONT-Tags... die kann das W3C afaik nicht ausstehen... dazu kommen noch ein paar kleine IE/Netscape-Feinheiten...

      Ach so :-)

      Cheatah

    • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

    Die müssen eigentlich im <frame>-Tag stehen. Ich schreibe die Angaben aber auch immer in den <frameset>-Tag. Ist einfacher.

    Maxboy

    1. Hi Maxboy,

      • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

      Die müssen eigentlich im <frame>-Tag stehen. Ich schreibe die Angaben aber auch immer in den <frameset>-Tag. Ist einfacher.

      was sollen die Angaben den im <frame>-Tag? Da habe ich die noch nie gesehen. Momps, ich probier's mal aus... nein, im <frame> bewirken die gar nichts.

      Cheatah

      1. Hi Maxboy,

        • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

        Die müssen eigentlich im <frame>-Tag stehen. Ich schreibe die Angaben aber auch immer in den <frameset>-Tag. Ist einfacher.

        was sollen die Angaben den im <frame>-Tag? Da habe ich die noch nie gesehen. Momps, ich probier's mal aus... nein, im <frame> bewirken die gar nichts.

        Ich hab auch keine Ahnung, weshalb die eigentlich im <frame>-Tag stehen sollen. Jedenfalls schlägt bei mir immer der Validator von Homesite an, wenn die Attribute im <frameset>-Tag stehen.

        Soweit ich weiss, schreibt auch FP die Attribute in den <frame>-Tag. Aber solange die Attribute im <frameset>-Tag funktionieren, ist es ja eigentlich egal.

        Maxboy

    • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

    Nur die vom IE verwendete Syntax ist offiziell.

    • <noframes> scheint auch falsch zu sein. Muß man das durch <body> ersetzen?

    jo!

    • Bei <img> wird der Parameter name beanstandet. Ist der wirklich falsch? Ich brauche das für wartungsarme JavaScript-Funktionen (images[x] fällt flach, weil ich das ggf. in vielen Seiten ändern müßte).

    wollen lieber id="" !

    • Ziemlich krass: Bei Countergrafiken wird jedes "&" angemeckert (z.B. <img src="count.pl?id=cheatah&counter=test">, da ist ein "&" drin...). Begründung: "general entity 'counter' [in diesem Fall] not defined and no default entity". Die Erklärung dazu ist folgende (http://www.cs.duke.edu/~dsb/kgv-faq/errors.html#bad-entity):

    Pech für's W3C!

    • <table height="100%"> ist offenbar nicht erlaubt. Wie kriege ich den Seiteninhalt sonst an den unteren Bildschirmrand, und zwar so, daß es auch zu HTML 3.2 (zumindest) bzw. der Interpretation der Browser kompatibel bleibt?

    height="" ist nicht offiziell.

    W3C mag deshalb auch <layer> nicht. (nicht nur in der Spec)

    Ich bin gespannt, was andere dazu meinen :-) Testet doch mal eure Seite mit dem Validator! Vermutlich werdet ihr überrascht sein...

    bei mir wird er auch solchen und ähnlichen Mist finden. Wenn's keinen Browser stört - Pech für's W3C

    1. Hi,

      • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

      Nur die vom IE verwendete Syntax ist offiziell.

      bitte keine Verallgemeinerungen :-)
      Die Angaben frameborder und -spacing sind übrigens MS-Syntax, und die wollte der Validator auch nicht.

      • <noframes> scheint auch falsch zu sein. Muß man das durch <body> ersetzen?
        jo!

      Hm, andere sagen, der <noframes>-Bereich muß vor das </frameset>. Was denn nu?

      • Bei <img> wird der Parameter name beanstandet. Ist der wirklich falsch? Ich brauche das für wartungsarme JavaScript-Funktionen (images[x] fällt flach, weil ich das ggf. in vielen Seiten ändern müßte).
        wollen lieber id="" !

      Tja, das versteht aber Netscape nicht!

      • Ziemlich krass: Bei Countergrafiken wird jedes "&" angemeckert (z.B. <img src="count.pl?id=cheatah&counter=test">, da ist ein "&" drin...). Begründung: "general entity 'counter' [in diesem Fall] not defined and no default entity". Die Erklärung dazu ist folgende (http://www.cs.duke.edu/~dsb/kgv-faq/errors.html#bad-entity):
        Pech für's W3C!

      Du sagst es :-)

      • <table height="100%"> ist offenbar nicht erlaubt. Wie kriege ich den Seiteninhalt sonst an den unteren Bildschirmrand, und zwar so, daß es auch zu HTML 3.2 (zumindest) bzw. der Interpretation der Browser kompatibel bleibt?
        height="" ist nicht offiziell.

      Ja, aber das finde ich doof.

      Hm? Da verstehe ich den Zusammenhang nicht!

      Ich bin gespannt, was andere dazu meinen :-) Testet doch mal eure Seite mit dem Validator! Vermutlich werdet ihr überrascht sein...
      bei mir wird er auch solchen und ähnlichen Mist finden. Wenn's keinen Browser stört - Pech für's W3C

      So kann man's auch sehen :-)

      Cheatah

        • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?

        Nur die vom IE verwendete Syntax ist offiziell.

        bitte keine Verallgemeinerungen :-)
        Die Angaben frameborder und -spacing sind übrigens MS-Syntax, und die wollte der Validator auch nicht.

        .. naja zumindest umgekehrt stimmt's

        • <noframes> scheint auch falsch zu sein. Muß man das durch <body> ersetzen?
          jo!

        Hm, andere sagen, der <noframes>-Bereich muß vor das </frameset>. Was denn nu?

        das hatten wir doch erst: nette Probleme

        • Bei <img> wird der Parameter name beanstandet. Ist der wirklich falsch? Ich brauche das für wartungsarme JavaScript-Funktionen (images[x] fällt flach, weil ich das ggf. in vielen Seiten ändern müßte).
          wollen lieber id="" !

        Tja, das versteht aber Netscape nicht!

        that's the problem!

        Hm? Da verstehe ich den Zusammenhang nicht!

        <layer> ist doch nur in Verbindung mit JS zu gebrauchen. Daher mag das W3C diesem nicht, denn man mag kein JS - kommt von Netscape, gehört Netscape..
        Es unterstützen ja nur drei Browser JS (Netscape, Opera und IE. Netscape hat JS entwickelt und die beiden anderen haben's lizenziert (und manipuliert*)
        *macht Netscape sauer - sehr sauer

        1. Hallo,

          <layer> ist doch nur in Verbindung mit JS zu gebrauchen. Daher mag das W3C diesem nicht, denn man mag kein JS - kommt von Netscape, gehört Netscape..
          Es unterstützen ja nur drei Browser JS (Netscape, Opera und IE. Netscape hat JS entwickelt und die beiden anderen haben's lizenziert (und manipuliert*)
          *macht Netscape sauer - sehr sauer

          Na, geraet Dir da jetzt nicht Einiges durcheinander?

          Christine

        2. Hi,

          <layer> ist doch nur in Verbindung mit JS zu gebrauchen. Daher mag das W3C diesem nicht, denn man mag kein JS - kommt von Netscape, gehört Netscape..

          also, <script> ist in HTML verankert, seit HTML 4 sogar <script src=>. Zumindest sollte das W3C also so schlau sein, entweder den Code darin _richtig_ zu interpretieren oder ihn zu ignorieren. Zumindest document.writeln('<A href=...>...</A>'); sollte nicht zur Meldung "</A>: Nicht geöffnet" führen!

          Es unterstützen ja nur drei Browser JS (Netscape, Opera und IE. Netscape hat JS entwickelt und die beiden anderen haben's lizenziert (und manipuliert*)
          *macht Netscape sauer - sehr sauer

          Äh... Netscape hat's erfunden, richtig. Aber bist Du sicher, daß der Rest stimmt? Naja, das was MS daraus gemacht hat ist natürlich wieder etwas, das nur noch im Ansatz mit dem Original zu tun hat </übertreib> [Nicht geöffnet!] { Sorry... }, aber abgesehen von IE3 läßt die Angabe "...versteht JS v1.x" immerhin auf einen Grundetat von Fähigkeiten schließen.

          Sauer macht es übrigens vor allem die Webmaster, die drum herum pfuschen müssen...

          Cheatah

  4. ReHallo

    Hallo,

    nachdem ich nun meine neu designeten Seiten durch den W3C-Validator (http://validator.w3.org/) gejagt habe, bin ich nicht mehr so ganz sicher, was ich vom W3C halten soll. Zwar wurden mir einige tatsächliche Fehler klargemacht, aber anderes halte ich für ziemlich unsinnig. Als Fehler bezeichne ich hier, was beide großen Browser korrekt darstellen, aber vom W3C als falsch markiert wird - und wofür es offenbar keine Lösung gibt. Folgendes fiel mir auf:

    • Im <frameset> werden border, frameborder und framespacing angemeckert. Ja wie soll ich denn den Rahmen wegkriegen?
    • <noframes> scheint auch falsch zu sein. Muß man das durch <body> ersetzen?

    Genau dieses Problem hatte ich auch. Ich habe mich bei der Erstellung an ein Buch von Data Becker gehalten, (da kannte ich SelfHTML noch nicht) inedem es genau so erklärt ist, wie ich das nun auch geschrieben habe, ich dachte schon ich könnte nicht mehr lesen, aber wenn es anderen genauso geht, bin ich ja beruhigt

    Ich bin gespannt, was andere dazu meinen :-) Testet doch mal eure Seite mit dem Validator! Vermutlich werdet ihr überrascht sein...

    Du hast recht, ich war da dann auch überrascht, nun aber meine Frage: gibt es von den jeweiligen Firmen (Netscape und Microsoft) Prüfmaschinen, die das in Übereinstimmung mit Ihren Browsern machen, oder eine unabhängige Stelle, bei der man das praxisnäher prüfen kann. Ich kann ja als doctype nicht einen angeben, bei dem meine Seiten total falsch sind wie z.B.für die normale Page ohne Frames:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN                                      "http://www.w3.org/TR/REC-html40/loose.dtd">

    Klaus