Ich arbeite an einem ASP.NET-Webprojekt mit. Als Entwicklungsumgebung benutze ich VS.NET 2003.
Funktioniert auch soweit, der IE stellt alles wunderbar dar. Nur leider zerreißts mir die Seiten im Firefox total.
Ich hab jetzt mal ein bisschen rumprobiert und folgendes rausgefunden:
Wenn ich die entsprechende .aspx-Seite, die Firefox so krankhaft darstellt, im Browser selbst über "File"->"Save Page" als .html - Seite speichere und wiederum mit dem Firefox aufrufe, dann passt das Layout.
Firefox scheint also die .aspx-Erweiterung irgendwie zu stören... is verrückt, es ist der selbe Quelltext, dargestellt auf zwei völlig verschiedene Weisen vom selben Browser...
Vielleicht hatte jemand mal ein ähnliches Problem und kann mir helfen ? Wäre sehr dankbar.
EDIT: Sollte vielleicht noch hinzufügen, dass ich in der web.config schon eine <browserCaps> - Section eingefügt hab, die den Firefox als High-Level-Browser erkennt und passenden Quelltext sendet.
Geändert von Crystallion (25.06.2005 um 14:21 Uhr)
Das Problem dürfte weniger der Firefox sein als viel mehr MS denen die Kompatibilität zu anderen Browsern (und vorallem Standards) ziemlich egal ist...
kannst du mal einen link posten wenn du das wo online haben solltest - ich würds mir gern auch mal mit
Opera
angucken
edit: die seite schon durch den validator gejagt? Wenn die seite nicht 100% valide ist, brauchst du dich auch nicht zu wundern, dass andere Browser die sonstwie darstellen (wobei ich eher sagen würde das der Internet Explorer dies Seite SONSTWIE darstellt)
Ihr habt natürlich recht, dass Microsoft sich nicht besonders viel um andere Browser schert - im IE läuft´s ja
Hilft mir aber nichts, es geht um ein Uni-Projekt, und die Entwicklungsumgebung ist eben vorgegeben.
Was mir aber nach wie vor nicht in den Kopf will, ist die Sache, dass der Firefox die Seite richtig darstellt, sobald die Endung ".html" statt ".aspx" lautet.
@Tele:
Es steht im Moment noch nichts online, sobald es mal soweit ist, sag ich´s Dir.
Der Validator meckert vier Punkte an (war mir auch klar...), ich werd sehen dass ich den Quelltext noch entsprechend korrigiere.
Den Opera-Check werd ich auch noch machen, ich habe Hoffnungen, dass die Seite im Opera auch läuft, wenn der Firefox sie mal schluckt...
Hab mir inzwischen die Seite auch mal mit Opera 8 angeschaut - genau das gleiche Phänomen wie mit dem Firefox. .aspx wird zerrissen, selber Quelltext in einer .html-Datei korrekt angezeigt.
guck doch am einfachsten mal, ob du in der ASP welt eine seite zusammenbauen und dann als beliebige file (z.b. als html) an den browser zurückwerfen kannst - der browser sollte also nix davon merken, das eine ASP.net anwendung im backend läuft.
Bitte sei so nett und code nach den W3C Standards für HTML/XHTML
Alle standardkonformen Browseruser werden es dir danken
Gruß
tele
PS: kannst du mir den Teil mit dem "Firefox kein High-Level Browser ist" näher erklären? Warum muss sich eine website überhaupt um spezifische browser im Code kümmern, das interessiert eigentlich nur den Test. wenn eine Seite standardkonform ist dann läuft sie in allen standardkonformen Browsern.
Grundsätzlich bin ich eigentlich gegen dieses W3C strikte aufbauen einer Website. Klar hat das Vorteile - und ist wahrscheinlich auch sinnvoll - aber mit der Zeit wurde da von W3C immer mehr vom Stapel gelassen, was eher hinderlich ist. Vor allem sehe ich gar nicht ein das ich meinen "Platzhalter" Bildchen ein Alt Tag verpasse, welches dann auch noch im IE unter umständen aufpoppt! Genau diese Tatsachen stören mich! Im Orginal W3C war das nämlich noch nicht pflicht - und jetzt fängt man an eine Website mit solche unnützen Angaben wieder sinnlos aufzublasen!
Aber egal - werde mal schauen was sich machen lässt um da wenigstens ein paar W3C Fehler zu unterbinden.
Die Deklaration der IDs kommt übrigens nicht von mir - sondern hat MS das in seinem DOTNET Framework so integriert - das die mit einem Unterstrich beginnen! Es gibt aber auch irgendwo eine Implementation die sowas auch wieder richten kann. (quasi MS Dotnet und W3C Konform)!
Firefox kein High Level Browser!
Das kommt beim DOTNET Framework mit. Dabei unterscheidet das Framework aufgrund des Browsers wie bestimmte automatisch erstellte Controls gerendert werden. Grundsätzlich wird dabei ein IE ab 6.0 als High Level Browser erkannt, und die Framework Engine rendert bestimmte Controls optimiert dafür. Ob das so sinnvoll ist oder nicht kann ich dabei aber nicht beurteilen. Zum Beispiel wird auf sogenannten High Level Browsern, die Validierung von Eingaben auf der Client Seite per Javascript automatisch aktiviert. Es wird zwar grundsätzlich dann auch nochmal auf der Server Seite validiert - aber dabei muß man sich halt vorstellen, dass schon jeder auf der Client Seite erkannte Fehler gar nicht erst zum Server gesandt wird - und somit auch Rechner Kapazität gespart wird. Bei nicht "High Level" Browsern wird das grundsätzlich nur auf der Server Seite gemacht!
Es geht bei der Sache mit Highlevel/Nicht-Highlevel auch um andere, einfachere Dinge:
So hatte ich zum Beispiel zunächst das Problem (als aufgrund fehlender Identifikation des FF dieser als Low-Level erkannt wurde), dass im Quelltext, den der FF erhalten hat, bestimmte HTML-Attribute gefehlt haben.
Beispielsweise hatten sämtliche "Input"s kein "width"-Attribut und waren damit gleich lang, was das Layout etwas verkomischt hat.
verschiedener code muss zwar meistens nicht sein, aber bei css wird man quasi gezwungen, für den jeweiligen browser nen eigenes sheet zu machen. der ie (7<) stellt da nämlich einiges falsch dar
ich weiß ja nicht was für speziellen code ihr da so habt, aber ich habe bisher kaum elemente gefunden, die standard sind und vom IE komplett falsch interpretiert werden.
Ich glaub jetzt reden wir ein bissel aneinander vorbei...
Nochmal zu Klarstellung: Im IE läuft die Sache so wie sie soll, Probleme gibt´s nur im Firefox, und zwar die am Anfang des Threads beschriebenen.
Bin zwar fleißig am rumprobieren, aber effektiv hat sich noch nix verbessert. Hab versucht dem IIS beizubringen, dass er bei .aspx-Dateien im HTTP-Header den MIME-Typ "text/html" mitschickt, aber das hat bisher auch noch nicht funktioniert.
EDIT: Sobald ich Zeit hab, versuch ich mal das Ganze auf einen Webserver zu bekommen, dann wird´s vielleicht klarer...
Geändert von Crystallion (29.06.2005 um 19:36 Uhr)
So - wir haben unser Problem inzwischen in den Griff bekommen.
Eines der Probleme war, dass Bilder in Menüs nicht angezeigt wurden. Irgendwann ist uns aufgefallen, dass diese Bilder aber durchaus vorhanden waren, nur eben vom Firefox unterdrückt wurden.
Das wiederum lag daran, dass das Visual Studio für die Pfade zu den Bildern absolute URLs angegeben hat (file:///...), und Anzeige solcher Elemente erlaubt der FF scheinbar aus Sicherheitsgründen nicht...
OK, es *hätte* uns auch früher auffallen können...
Damit erklärt sich auch die Sache mit dem abgespeicherten Quelltext, der dann korrekt angezeigt wurde - bei lokal gespeicherten HTML-Seiten sind wohl die sicherheitsbedingten Restriktionen des FF nicht so krass.
Die andere Sache betraf die Positionierung einiger Elemente. Das lag (wie könnte es anders sein...) an absoluter Positionierung der entsprechenden Tags.
Diese absoluten Angaben bezieht der Internet-Explorer aber dann auf das umgebende Element - der Firefox dagegen korrekterweise auf das ganze Form, also sprich die komplette Seite.
Danke auf jeden Fall für eure Tips ! Vielleicht hilft die Problemlösung ja mal jemand anderem weiter.
Das wiederum lag daran, dass das Visual Studio für die Pfade zu den Bildern absolute URLs angegeben hat (file:///...), und Anzeige solcher Elemente erlaubt der FF scheinbar aus Sicherheitsgründen nicht...
Das ist so nciht ganz richtig. Eine HTML Seite wird ja effektiv vom Client heruntergeladen und vom Browser interpretiert. Wenn du darin absolute Pfade hast, die auf Objekte auf dem server verweisen und mit file:// beginnen, dann sucht der Browser nciht auf dem Server danach, sondern auf der clientmaschine - wo diese ja offensichtlich nicht zu finden sind - nix mit sicherheitsrestriktionen (da ist der FF ohnehin eh nicht so krass wie z.b. Opera)
Das ist so nciht ganz richtig. Eine HTML Seite wird ja effektiv vom Client heruntergeladen und vom Browser interpretiert. Wenn du darin absolute Pfade hast, die auf Objekte auf dem server verweisen und mit file:// beginnen, dann sucht der Browser nciht auf dem Server danach, sondern auf der clientmaschine - wo diese ja offensichtlich nicht zu finden sind - nix mit sicherheitsrestriktionen (da ist der FF ohnehin eh nicht so krass wie z.b. Opera)
Da hast Du prinzipiell natürlich recht, aber in dem Fall sind Server und Client gleich, weil wir jeweils einen lokal eingerichteten IIS für die Entwicklung nutzen.
Die Bilder waren ja auch jeweils in der Seite vorhanden - mit Rechtsklick auf die entsprechende Stelle -> Bild anzeigen konnte man sie begutachten, aber innerhalb der Seite wurden sie eben nicht angezeigt.