| Zitat: |
| Zitat: |
Aus eigenen Seiten. Selbst erlebt. Klar, muss das nicht auf jede Seite zutreffen, aber in meinem Fall hatte der IE8 als IE7 gerendert, was sich nur dadurch beheben ließ. Falls du das weiterverfolgen möchtest, die Seite lief mit folgendem XML-Header/DocType:
|
Tatsächlich.. Ich habe das ganze grade ausprobiert mit nem kleinem Script:
| code: |
1:
2:
3:
4:
5:
6:
7:
|
<script type="text/javascript">
/*@cc_on
if(document.documentMode && document.documentMode == 8) {
alert(document.documentMode);
}
@*/
</script> |
|
Ohne Doctype fällt er sogar wieder zurück in den IE5-Quirksmodus.
Wenn du willst, dass der IE sich am Doctype orentiert, musst du EmulateIEx benutzen. IE=Edge weißt an, immer den aktuellen Modus zu benutzen. Finde hier ist die Beschreibung im MSDC ziemlich dürftig 
|
Ich denke, das Problem ist hier, dass vor dem DocType noch der XML-Header steht, vielleicht funktioniert das dann nicht so richtig. Ich erinnere mich da an die Möglichkeit den IE6 in Quirksmode zu bekommen, indem man vor dem DocType einfach einen HTML-Kommentar geschrieben hat.
| Zitat: |
| Zitat: |
| Ich empfehle XHTML, weil die Syntax weniger fehleranfällig ist. |
In wie fern?
|
Naja, das ist vermutlich Meinungssache. Ich finde, dass man bei XHTML immer die gleichen Regeln zu beachten hat und dadurch der Code übersichtlicher wird - dementsprechend macht man auch weniger Fehler. Auch gibt es ein paar uneindeutige Fälle, wo man mit XHTML immer das gewünschte Ergebnis erreicht und in HTML, aufgrund der anderen Regeln, nicht. Beispiel - Möglicher HTML-Code:
| code: |
1:
|
<div class=gruppe1 gruppe2 id=id1>....</div> |
|
Da die HTML-Syntax keine Anführungszeichen verlangt, ist der Code gültig, jedoch vermute ich, dass gruppe2 als Attribut und nicht als Wert für class gewertet wird. Durch die XHTML-Syntax ist man gezwungen Anführungszeichen zu machen und dieser mögliche Fehler ist ausgeschlossen:
| code: |
1:
|
<div class="gruppe1 gruppe2" id="id1">...</div> |
|
Natürlich passiert soetwas nur, wenn man unachtsam ist, aber, diesen Fehler dann zu finden, könnte ein größeres Problem werden. In XHTML meldet dies sofort der Validator, weil die Anführungszeichen fehlen.
| Zitat: |
| Zitat: |
| XHTML-Code leicht mit dem Validator, während HTML solche Fehler einfach toleriert. |
Meinst du die OMITTags (Entfallene Start/End-Tags)?
| code: |
1:
2:
3:
4:
|
<ul> <li>Eins
<li>Zwei
</ul> |
|
oder die Shorttags?
sehe ich als kein gutes Argument, da diese Schreibweisen
1) sehr wenig verbreitet sind (meistens nur bei Profis, nein ich will nicht! sagen dass ich einer bin
)
2) die Browser sowieso keinen SGML-Parser sondern einen Tag-Soup Parser benutzen und somit das in den meisten Browsern nicht funktioniert.
|
Da hast du Recht, meinte ich jedoch beides nicht. Ich meine, dass man z.B. innerhalb einer Tabellenspalte ein <div> anfangen kann und dieses erst in der nächsten Spalte wieder schließt. In XHTML gibt das einen Fehler im Validator, in HTML ist das korrekter Code - auch wenn mir fraglich ist, wie die Browser das interpretieren wollen - und siehe da, Firefox interpretiert anders als IE.
| code: |
1:
2:
3:
4:
5:
6:
|
<table>
<tr>
<td>123<div>456</td>
<td>789</div>abc</td>
</tr>
</table> |
|
Firefox 3.6.3:
IE 8.0.7600:
| Zitat: |
| Zitat: |
Außerdem können diese "tolerierten Fehler" in verschiedenen Browsern anders toleriert werden, wodurch die Seite anders aussieht.
|
Da beides durch den Tag-Soup Parser läuft kann dir das selbe doch auch bei XHTML passieren? Solang beides noch als text/html ausgeliefert wird, sehe ich da keinen Unterschied.
|
Das stimmt, die Fehler werden
vom Browser dennoch toleriert. Wenn man jedoch eine valide XHTML-Seite hat, hat man das Problem nicht, da der Validator im Gegensatz zum Browser nicht toleriert.
| Zitat: |
| Zitat: |
Sie ersetzen (i)Frames nicht, aber sind eine - zumindenst nach meiner Ansicht - brauchbare Alternative, um Inhalte aus anderen Quellen einzufügen.
|
AJAX unterliegt der Same Origin Policity für JavaScript. Damit ist das grundsätzlich ersteinmal nicht möglich, von anderen Seiten Inhalt zu holen. Nun könnte man eine Art Proxy mit PHP implementieren oder aber einen "richtigen" Proxy benutzen. Von mir aus auch mod_proxy für den Apache (hab ich zumindest immer so gelöst). In Firefox 3.5 hat sich da allerdings in der Hinsicht was getan 
wie das bei anderen aussieht, weiß ich aber nicht. |
Mit "anderen Quellen" meinte ich ausschließlich das Nachladen von Inhalten des eigenen Servers, aber beispielsweise aus einer anderen Datei.
| Zitat: |
| Das eigentliche Problem bleibt aber: Ich habe dann alles im selben Context. Mir persönlich würde das den Magen umdrehen.. Das wäre dann wohl XSS für Arme? |
Und hier haben wir den Unterschied zwischen PHP, AJAX und iFrames. Wenn man externe Seiten, also nicht-eigene einfügen möchte, sind iFrames definitiv vorzuziehen. Sind es jedoch eigene Inhalte, sind iFrames oft unnötig. So kann man statt seinen Seiteninhalt im iFrame zu laden auch einen Parameter an die URL hängen und den gewünschten Inhalt mit PHP einfügen lassen. Das "lesen" dann z.B. auch Suchmaschinen als eine Seite - und nicht als 2 Seiten ohne Zusammenhang.
| Zitat: |
| Ausserdem tritt hier wieder mein Lieblingsproblem mit der Zeichencodierung auf, die einigen wohl gar nicht so bewusst ist. |
Oh ja. Das kenne ich.... Der AJAX-Inhalt muss mindestens die selbe Zeichenkodierung haben, wie das Dokument, in das dieser eingefügt werden soll.
| Zitat: |
Die Privilegien die der Benutzer vielleicht nur meiner Seite gegeben hat, hat somit auch die Fremdseite.
Das sind nur einige Probleme die mir nun in den Sinn kommen. Das würde ich mit einem I-Frame zumindest größtenteils umgehen. |
Wieder korrekt. Daher - wie gesagt - AJAX nur für die eigenen Inhalte, für externe Inhalte sind iFrames vorzuziehen.
| Zitat: |
| Zitat: |
Aber manche Dinge können einfach nicht ausschließlich in CSS gestaltet werden, besonders der IE hat/hatte damit manchmal komische Probleme...
|
Welche sind das denn?
|
Ich bin mir nicht mehr sicher, aber ich glaube, es war unmöglich, ein <div> im IE6 ausschließlich mit CSS zu zentrieren...
