Lokale Datei wird im IE nicht angezeigt

[Zeromancer]

Hallo,

nach meinem Erfolg letzter Woche

• vgl. http://forum.de.selfhtml.org/archiv/2007/2/t145857/#m946465
• vgl. http://forum.de.selfhtml.org/archiv/2007/3/t147535/#m956998

grüble ich über Veränderungen an unserer Vereinsseite.

Leider öffnet der IE 7 mir nicht die lokale index.shtml-Datein, Firefox 2.x und Opera 9.10 jedoch schon (Win XP prof).

Mittels http://www.testdomain.test erreiche ich beim IE gar nichts. Sofern ich jedoch auf "Quelltext anzeigen" gehe, öffnet sich Phase5 und zeigt den Quelltext. Wenn ich auf "Eigenschaften" gehe, wird mir eine Dateigröße von 5853 Bytes angegeben.

Muss ich im IE irgendeinen Haken setzen? Hatte schon mal jemand dieses Problem?

Mit freundlichen Grüßen,
André

[Zeromancer]

Hallo,

Fehler gefunden: ich musste

<script type="text/javascript" src="includes/javascript/gallery-01.js" />

auskommentieren. Aus welchen Gründen auch immer. Jetzt zeigt der IE die Seite auch an.

Wobei ich nicht verstehe warum?! Das dahinter liegende Skript ist aus einer Skriptsammlung und beinhaltet lediglich:

function showPic (whichpic) {  
if (document.getElementById) {  
document.getElementById('placeholder').src = whichpic.href;  
  if (whichpic.title) {  
   document.getElementById('desc').childNodes[0].nodeValue = whichpic.title;  
  } else {  
   document.getElementById('desc').childNodes[0].nodeValue = whichpic.childNodes[0].nodeValue;  
  }  
  return false;  
 } else {  
  return true;  
 }  
}

Wie auch immer, die Seite wird angezeigt. Der Rest kommt später.

Mit freundlichen Grüßen,
André

[wahsaga]

hi,

Fehler gefunden: ich musste

<script type="text/javascript" src="includes/javascript/gallery-01.js" />

auskommentieren. Aus welchen Gründen auch immer. Jetzt zeigt der IE die Seite auch an.

Wobei ich nicht verstehe warum?!

Weil Scripte in lokalen Dateien aus Sicherheitsgründen geblockt werden ...?

Vielleicht hilft das Setzen eines Mark of the Web.

gruß,
wahsaga

[Der Martin]

Hi,

Fehler gefunden: ich musste
<script type="text/javascript" src="includes/javascript/gallery-01.js" />
auskommentieren. Aus welchen Gründen auch immer. Jetzt zeigt der IE die Seite auch an.

ich meine mich zu erinnern, dass der IE5/6 mit der an sich korrekten und XHTML-konformen Schreibweise <script ... /> ein Problem hat und das Ende des script-Blocks nicht erkennt. Mit der ausführlichen Schreibweise <script ...></script> ist alles in Butter.
Möglich, dass das im IE7 immer noch so ist.

Ciao,
 Martin

[D.R.]

Hallo,

[…] dass der IE5/6 mit der an sich korrekten und XHTML-konformen Schreibweise <script ... /> ein Problem hat

Naja, ob es XHTML-konform ist, spielt erst eine Rolle, wenn die betroffene Ressource als application/xhtml+xml gerendert wird. Sonst gelten die HTML-Regeln, wo der „/“ am Ende bedeutungslos ist.

mfg. Daniel

[wahsaga]

hi,

[…] dass der IE5/6 mit der an sich korrekten und XHTML-konformen Schreibweise <script ... /> ein Problem hat

Naja, ob es XHTML-konform ist, spielt erst eine Rolle, wenn die betroffene Ressource als application/xhtml+xml gerendert wird. Sonst gelten die HTML-Regeln, wo der „/“ am Ende bedeutungslos ist.

Trotzdem ist das Problem altbekannt, dass der IE ohne schliessendes Tag </script> Probleme macht.

gruß,
wahsaga

[D.R.]

Hallo,

[…] dass der IE5/6 mit der an sich korrekten und XHTML-konformen Schreibweise <script ... /> ein Problem hat

Naja, ob es XHTML-konform ist, spielt erst eine Rolle, wenn die betroffene Ressource als application/xhtml+xml gerendert wird. Sonst gelten die HTML-Regeln, wo der „/“ am Ende bedeutungslos ist.

Trotzdem ist das Problem altbekannt, dass der IE ohne schliessendes Tag </script> Probleme macht.

Ist das schließende Tag überhaupt optional?

mfg. Daniel

[wahsaga]

hi,

Trotzdem ist das Problem altbekannt, dass der IE ohne schliessendes Tag </script> Probleme macht.

Ist das schließende Tag überhaupt optional?

Wenn du Script als inhaltsleeres Element als <script /> notierst, braucht es kein "schliessendes" Tag - aber genau das ist im IE problematisch. Egal ob HTML oder XHTML.

gruß,
wahsaga

[D.R.]

Hallo,

Trotzdem ist das Problem altbekannt, dass der IE ohne schliessendes Tag </script> Probleme macht.

Ist das schließende Tag überhaupt optional?

Wenn du Script als inhaltsleeres Element als <script /> notierst, braucht es kein "schliessendes" Tag

Woher soll ein Browser, der eine Ressource als text/html rendert, wissen, dass der Slash ein inhaltsleeres Element kennzeichnet?

Wenn andere Browser damit im text/html-Modus keine Probleme haben, sind sie entweder Fehlertolerant oder das schließende </script> ist optional.

aber genau das ist im IE problematisch. Egal ob HTML oder XHTML.

Hast du schonmal eine Seite als application/xhtml+xml an den IE ausgeliefert? Wenn du das machst, wird der IE keine Probleme mit <script /> haben, weil er gar nicht erst versucht die Seite darzustellen ;-)

mfg. Daniel

[wahsaga]

hi,

Wenn andere Browser damit im text/html-Modus keine Probleme haben, sind sie entweder Fehlertolerant oder das schließende </script> ist optional.

Darum, ob und unter welchem Unständen es optional ist, geht es nicht,

aber genau das ist im IE problematisch. Egal ob HTML oder XHTML.

Hast du schonmal eine Seite als application/xhtml+xml an den IE ausgeliefert?

und darum auch nicht.

Der IE _hat_ Probleme mit <script src="..." /> (dürfte auch schon mehrfach hier im Archiv stehen) - und darauf hat Martin hingewiesen.

gruß,
wahsaga

[D.R.]

Hallo,

Wenn andere Browser damit im text/html-Modus keine Probleme haben, sind sie entweder Fehlertolerant oder das schließende </script> ist optional.

Darum, ob und unter welchem Unständen es optional ist, geht es nicht,

aber genau das ist im IE problematisch. Egal ob HTML oder XHTML.

Hast du schonmal eine Seite als application/xhtml+xml an den IE ausgeliefert?

und darum auch nicht.

Martin hat geschrieben, dass <script /> eine XHTML-konforme Schreibweise ist, und es deshalb keine Probleme geben *sollte*.

Ich habe dazu nichts weiter geschrieben, als dass die XHTML-Regeln keine Rolle spielen, solange man die Ressource als text/html ausliefert und der Slash somit bedeutungslos ist.

Ich verstehe deine Argumentation dazu nicht. Was ist an meiner Aussage falsch?

mfg. Daniel

[wahsaga]

hi,

Martin hat geschrieben, dass <script /> eine XHTML-konforme Schreibweise ist, und es deshalb keine Probleme geben *sollte*.

Nein, da unterschlägst du Wesentliches - er wollte vor allem sagen, dass der IE damit Probleme hat.

Ich habe dazu nichts weiter geschrieben, als dass die XHTML-Regeln keine Rolle spielen, solange man die Ressource als text/html ausliefert und der Slash somit bedeutungslos ist.

Ich verstehe deine Argumentation dazu nicht. Was ist an meiner Aussage falsch?

Sie stellt Martins Aussage so dar, als sei sie für das diskutierte Problem bedeutungslos, weil irgendwelche Regeln unter irgendwelchen Umständen keine Rolle spielen.

Darum geht es aber nicht, sondern um einen _Bug_ im IE - Regeln hin oder her.

gruß,
wahsaga

[D.R.]

Hallo,

Ich verstehe deine Argumentation dazu nicht. Was ist an meiner Aussage falsch?

Sie stellt Martins Aussage so dar, als sei sie für das diskutierte Problem bedeutungslos, weil irgendwelche Regeln unter irgendwelchen Umständen keine Rolle spielen.

Darum geht es aber nicht, sondern um einen _Bug_ im IE - Regeln hin oder her.

So. Ich habe es jetzt mal selbst ausprobiert.

Einmal als text/html und einmal als application/xhtml+xml.

Hat Firefox jetzt auch einen Bug? Schließlich stellt er den Text im HTML-rendering-Modus ebenfalls nicht dar.

Lediglich Opera ist hier fehlertolerant.

Warum soll das ein Bug sein? Ich sehe lediglich einen Unterschied zwischen HTML und XHTML aber keinen Bug.

mfg. Daniel

[Manuel B.]

Ich grüsse den Cosmos,

als application/xhtml+xml.

Wird mir im IE6 zum Download angeboten. Ist das jetzt beabsichtigt oder doch ein Bug? Gleiches im Übrigen im IE7.

Was das jetzt an deiner Aussage bestätigen soll, versteh ich nicht wirklich.

Möge das "Self" mit euch sein

[D.R.]

Hallo,

als application/xhtml+xml.

Wird mir im IE6 zum Download angeboten. Ist das jetzt beabsichtigt oder doch ein Bug? Gleiches im Übrigen im IE7.

Dass der IE kein XHTML kann, sollte bekannt sein. Das ist aber IMHO kein Bug, sondern ein fehlendes Feature.

mfg. Daniel

[Manuel B.]

Ich grüsse den Cosmos,

Dass der IE kein XHTML kann, sollte bekannt sein. Das ist aber IMHO kein Bug, sondern ein fehlendes Feature.

Stimmt, da der IE kein Browser ist, benötigt er ja auch keine Unterstützung für aktuelle Standards. Der Bug ist der gesammte IE, fehlende Features werden durch die schlechte Handhabung und Sicherheitslücken wettgemacht :D
SCNR

Möge das "Self" mit euch sein

[D.R.]

Hallo,

Der Bug ist der gesammte IE, fehlende Features werden durch die schlechte Handhabung und Sicherheitslücken wettgemacht :D

So könnte man's auch sehen :-D

mfg. Daniel

[MudGuard]

Hi,

Woher soll ein Browser, der eine Ressource als text/html rendert, wissen, dass der Slash ein inhaltsleeres Element kennzeichnet?

Das ergibt sich schon alleine aus dem Doctype, der die Syntaxregeln für das Dokument festlegt.

cu,
Andreas

[D.R.]

Hallo,

Woher soll ein Browser, der eine Ressource als text/html rendert, wissen, dass der Slash ein inhaltsleeres Element kennzeichnet?

Das ergibt sich schon alleine aus dem Doctype, der die Syntaxregeln für das Dokument festlegt.

?? Der DOCTYPE legt fest, welche Elemente wie verschachtelt werden dürfen und welche Attribute erlaubt sind.

Mit dem Rendering-Modus hat das nichts zu tun. Oder hast du schonmal erlebt, dass ein Browser, der eine Ressource mit XHTML-Doctype und als text/html bekommt, XHTML auf diese Ressource anwendet?

mfg. Daniel

[MudGuard]

Hi,

Naja, ob es XHTML-konform ist, spielt erst eine Rolle, wenn die betroffene Ressource als application/xhtml+xml gerendert wird.

Falsch.
Ob das Dokument XHTML-konform ist oder nicht, ist vollkommen unabhängig davon, ob und wenn ja wie es irgendwann mal ausgeliefert wird.

Für XHTML gelten die Syntaxregeln für XML. Unabhängig davon, welcher Content-type bei einer evtl. stattfindenden Auslieferung per HTTP verwendet  wird.

cu,
Andreas

[D.R.]

Hallo,

Für XHTML gelten die Syntaxregeln für XML. Unabhängig davon, welcher Content-type bei einer evtl. stattfindenden Auslieferung per HTTP verwendet  wird.

Und *wie* sagst du dem Browser, dass es sich um XHTML handelt?

mfg. Daniel

[Der Martin]

Hi,

Für XHTML gelten die Syntaxregeln für XML. Unabhängig davon, welcher Content-type bei einer evtl. stattfindenden Auslieferung per HTTP verwendet  wird.
Und *wie* sagst du dem Browser, dass es sich um XHTML handelt?

selbstverständlich mit dem DOCTYPE. Denn der ist auch noch da, wenn die Ressource *nicht* per HTTP übertragen wird.

Ciao,
 Martin

[D.R.]

Hallo,

Für XHTML gelten die Syntaxregeln für XML. Unabhängig davon, welcher Content-type bei einer evtl. stattfindenden Auslieferung per HTTP verwendet  wird.
Und *wie* sagst du dem Browser, dass es sich um XHTML handelt?

selbstverständlich mit dem DOCTYPE. Denn der ist auch noch da, wenn die Ressource *nicht* per HTTP übertragen wird.

Dann müsste der Browser aber schon anfangen zu rendern, bevor er weiß, ob es sich um HTML oder XHTML handelt.

Lokal richten sich die Browser i.d.R. nach der Endung:
.xhtml = application/xhtml+xml
.html = text/html

mfg. Daniel

[Der Martin]

Hi,

Und *wie* sagst du dem Browser, dass es sich um XHTML handelt?
selbstverständlich mit dem DOCTYPE. Denn der ist auch noch da, wenn die Ressource *nicht* per HTTP übertragen wird.
Dann müsste der Browser aber schon anfangen zu rendern, bevor er weiß, ob es sich um HTML oder XHTML handelt.

nö, warum das? Der DOCTYPE (oder der XML-Prolog) ist doch die allererste Information innerhalb der Datei/Ressource. Also bekommt er die Information über den Typ des Dokuments gleich am Anfang, noch bevor er irgendwas anderes interpretieren muss.

So long,
 Martin

[D.R.]

Hallo,

Und *wie* sagst du dem Browser, dass es sich um XHTML handelt?
selbstverständlich mit dem DOCTYPE. Denn der ist auch noch da, wenn die Ressource *nicht* per HTTP übertragen wird.
Dann müsste der Browser aber schon anfangen zu rendern, bevor er weiß, ob es sich um HTML oder XHTML handelt.

nö, warum das? Der DOCTYPE (oder der XML-Prolog) ist doch die allererste Information innerhalb der Datei/Ressource. Also bekommt er die Information über den Typ des Dokuments gleich am Anfang, noch bevor er irgendwas anderes interpretieren muss.

Also ist der Mime-Type „application/xhtml+xml“ völlig umsonst, weil der Browser die Information ja aus dem DOCTYPE herleiten kann?

Gut, man kann eine XHTML-Datei auch als text/xml ausliefern und XHTML erwarten. Aber selbst *das* liegt nicht am DOCTYPE, sondern am xmlns-Attribut am Wurzelelement. Fehlt dieses, wird nur der Elementbaum angezeigt. Fehlt dagegen nur der DOCTYPE gibt es auch bei XHTML keine Probleme (nichtmal Quirksmode).

Ich würde eher sagen, der DOCTYPE legt fest, welche Elemente und Attribute erlaubt sind. Da es auch in dieser Beziehung gewisse Unterschiede zwischen HTML und XHTML gibt (z.B. name-Attribut), brauchte man dafür eben auch einen passenden DOCTYPE.

Zusammenfassend würde ich also sagen:

Mimetype = Verarbeitungsmodus (XHTML, HTML, svg, rdf…)
DOCTYPE = Legt Elemente und Attribute fest
Namespace = Wie sollen die Elemente standardmäßig dargestellt werden und was bedeuten Sie?

mfg. Daniel