Firefox und Netscape stürzen ab, IE und Opera funktionieren

Hem. Mit meinen Gecko-Browsern (Fx1.0, 1.5, 2.0, 3.0trunk und Moz1.7) kann ich keine Probleme feststellen. Was genau passiert denn?

Übelst verschachtelt ists natürlich trotzdem. Und eignet sich auch nicht so sehr für die Verlinkung. Und PDA/Handy/usw. werden damit eh nicht klar kommen. Schon mal in betracht gezogen die Seite neu machen zu lassen? Heutzutage sind Tabellen oder Frames schon lange veraltet und unzeitgemäss.

Zitat von Digo01

...
Würde aber schon gern das Problem verstehen, da ich in nächster Zeit noch an anderen Sites sitzen werde und auf eine zentrierte Darstellung eigentlich nicht verzichten will.

Vielen Dank mal vorab für die Antwort

Falls du es noch nicht kennst, dann kannst du ja mal hier vorbeischauen :

http://de.selfhtml.org

...:AOD:...

Zitat von Digo01

Die äußeren Frames werden noch angezeigt, aber die zentrierte, eigentliche Seite wird nicht mehr angezeigt (bleibt leer, weiss).

Ich habe es jetzt nach unzähligen Anläufen 2 mal beschafft auch einen weißes Frame zu bekommen. Kann getrost dem Firefox als Bug zugeschoben werden. Wen es beim ersten Aufruf geht, muss es auch bei jedem weiten gehen. Ist also so gesehen nicht Dein Fehler. Ist vermutlich ein interner Eventfehler. Das laden des neuen Frame-Inhaltes kommt nicht zustanden und die vorgeladene "about:blank" (also eine Leere Seite) bleibt im aufgerufenen Frameset einfach liegen.

Zitat von Digo01

Die Seite habe ich selbst für einen Freund erstellt.

Achso. Ich dachte da hätte wieder irgendein Möchtegerndesigner einem ahnungslosen Klienten das Geld aus der Tasche gezogen und der arme Klient sucht den Fehler.

Gegen Geld wäre sowas heutzutage quasi regelrechter Betrug am Kunden, als Freundschaftsdienst natürlich ganz ordentlich.

Zitat von Digo01

Das mit den Frames weiss ich, habe aber bisher keine Alternative zu einer zentrierten Anzeige gefunden.
Tabellen sind bereits auch veraltet? Gott - bin halt doch noch ein Greenhorn..... :?
Was gibts da für eine Alternative? Alles mit Ebenen darstellen?

Das Stichwort dafür ist Barrierefreiheit.

Aber keine Sorge. Jeder fängt klein an. Und niemand muss klein bleiben. : )

Selfhtml ist mehr was zum nachschauen wie einzelne Befehle funktionieren. Das hier find ich ist die beste deutschsprachige Einführung in modernes Webdesign: http://jendryschik.de/wsdev/einfuehrung/

Zitat von Digo01

Würde aber schon gern das Problem verstehen, da ich in nächster Zeit noch an anderen Sites sitzen werde und auf eine zentrierte Darstellung eigentlich nicht verzichten will.

Nun. Frames nur wegen den Zentrierung einzusetzen ist wirklich Unsinn. Das ist mit ja selbst mit Tabellen problemlos möglich. ; )

Nochmal zurück: wie gesagt... das mit dem leeren Frame ist nicht deine schuld. Da kannst du auch nicht sonderlich viel dran machen.

Abgesehen davon, dass sich das Frameset nicht innerhalb des Head-Bereiches befinden sollte, darf eine Frameset-Datei keinen Body-Bereich enthalten. Zudem ist der falsche DOCTYPE angegeben.

Erst wenn der Fehler nach Bereinigung der oben genannten Punkte immer noch auftreten sollte, würde ich die Ursache woanders suchen.

Wenn Fx immer den inneren Frame weglassen würde, ja. Aber wenn er in nur jedes xte Mal vergisst, dann ist es ein Fx-Bug. Der Quelltext hat sich ja in Zwischenzeit nicht geändert.

Zitat von bugcatcher

...Der Quelltext hat sich ja in Zwischenzeit nicht geändert.

Der Quelltext nicht, aber vielleicht der Speicher-Inhalt des Firefox?
Könnte doch sein, dass der falsche DOCTYPE den Firefox durcheinander bringt (was dann aber kein Firefox-Fehler wäre).

Die haben bestimmt kein random() eingebaut. Und wenn kein richtiger DocType angegeben ist kommt der QuirksMode zum Einsatz. Und wie der sich verhält ist auch zu 100% festgelegt. Da gibt es kein zufälliges jetzt so und morgen so. Und wenn Speicherinhalt vom Firefox trotz identischen Quellextes der Seite variiert, dann ist das ebenfalls ein Fehler.

Wenn ich ein Programm schreibe, in dem drin steht int i = 12;, dann hat i den wert von 12, nicht von 13 und auch nicht von 14. Rechner keinen kein "ca." oder ähnliche wage Angaben.

bugcatcher:

Hältst du es für so unwahrscheinlich, dass auf Grund eines falschen DOCTYPES ein Speicher-Inhalt vielleicht summiert wird und dadurch irgendwann zum ''Überlaufen'' führt? (Soll nur ein Beispiel sein und keine Analyse!)

Aber ist im Grunde auch egal. So lange ein Webseiten-Quelltext nicht dem Standard entspricht, ist es müßig, über mögliche Browser-Probleme zu diskutieren. Dafür ist immer noch Zeit, falls der Fehler bei korrektem Code immer noch auftreten sollte.

Sagen wir so. Klar kann man sagen es ist die Seite schuld, weil sie sich nicht an den Standard hält. ABER. Selbst das Forum hier läuft im Quirksmode. Wie eigentlich 95% der Seiten weltweit.

Theoretisch können Bufferoverflows für alles verantwortlich sein. Ein Bufferoverflow ist aber vom Prinzip her bereits ein Fehler.
; )

Wie gesagt... auch der Quirksmode geht nach festen Regeln vor und daher muss ein Quelltext, egal wie falsch oder richtig er ist, immer das selbe Ergebnis liefern. Tut er das nicht, hat das Programm einen Fehler.

Das ist aber auch nix schlimmes. Kann man alles beheben, sobald man es weiß. Leugnen bringt das Programm aber nicht weiter.

Das ist insofern gut zu wissen, weil es auch im Standardmode immer noch gelegentlich scheinbar "zufällige" Darstellungsfehler gibt, die erst nach einem Reload wieder weggehen, die wohl die selbe Ursache haben.

Zitat von bugcatcher

...Theoretisch können Bufferoverflows für alles verantwortlich sein. Ein Bufferoverflow ist aber vom Prinzip her bereits ein Fehler...

Okay, so gesehen hast du natürlich Recht. Andererseits sollte das den Fragesteller nicht davon abhalten, seinen Quelltext zu überarbeiten. Ich habe Framesets, die recht komplex verschachtelt sind, in denen kann ich stundenlang herumklicken und es tritt kein solcher Fehler auf - womit ich sagen will, dass Framesets im Firefox normalerweise durchaus gut funktionieren.

Wer eine Webseite anbietet, dem hilft es wenig, wenn er seine Hände in Unschuld wäscht, weil ja nicht er, sondern der ''böse'' Browser des Besuchers Schuld an Fehlern trägt. Der Besucher hat nun mal den Browser, den er hat - und da der hier angesprochene Fehler evtl. nur auf dieser einen Seite auftritt, wird ein Besucher den Fehler also bei dieser Webseite vermuten - und eventuell künftig fern bleiben! Das kann nicht im Interesse des Webmasters sein.

Okay, ''wir'' haben eine neue Schwachstelle im Firfox entdeckt - und die sollte man natürlich auch an die Entwickler weiterleiten - keine Frage. Doch den Besuchern des Fragestellers, die Firefox benutzen, hilft das vorerst nicht weiter. Eine Korrektur der Seite ist also die momentan vorrangige Aktion für den Webmaster, wenn er seine Besucher nicht vergraulen will.

Natürlich sollte er seine Seite überdenken. Habe ich ja selbst angeregt. Nur soll er nicht den Fehler in diesem speziellen Fall bei sich selbst suchen. Das Firefox grundsätzlich keine Probleme mit Frames hat stimmt, in diesem speziellen Fall aber wohl schon.

Logisch sollte er auch schauen, dass er den Fehler vom Firefox umgeht. Der Fehler ist aber halt erstmal beim Firefox. Was anderes hab ich nicht sagen wollen. ; )

Btw: ein rahmenfreies Frameset das sich an den W3C-Standards hält, wird im Firefox nicht richtig dargestellt, da er nur border aber nicht auf frameborder reagiert, wie es richtig wäre.

Zitat von bugcatcher

Btw: ein rahmenfreies Frameset das sich an den W3C-Standards hält, wird im Firefox nicht richtig dargestellt, da er nur border aber nicht auf frameborder reagiert, wie es richtig wäre.

Da tun sich aber alle Browser schwer. Laut Standard sollte die Rahmen-Unterdrückung im Frame-TAG stehen, aber die Browser wollen es im Frameset-TAG sehen.

Zitat von Tarkus

Da tun sich aber alle Browser schwer.

Das ist richtig. Ich wollte damit auch nur ausdrücken: auf den Standard pochen alleine hilft auch nichts. Kein Browser, auch nicht Firefox, interpretiert ihn zu 100% und auch von dem was er unterstützt nicht alles richtig.