Sieht bei Opera, Konqueror und Mozilla ziemlich gleich aus,
vermutlich haben die Recht und der MSIE hat da einen kleineren
Fehler.
Ursache könnten die Zeilenumbrüche zwischen den div sein,
die stellen ein Leerzeichen dar, was dann eigentlich auch
darzustellen ist, wenn alles inzeilig ist. Kann man auch einfach
mal ausprobieren, indem man da zusätzlich nochmal ein festes
Leerzeichen hinzufügt. Einen Unterschied sollte man auch sehen,
wenn man den Zeilenumbruch wegläßt, wenn es wirklich daran
liegt.
Ansonsten müßte man das Box-Modell von CSS2.1 mal
genauer ansehen und mit größeren margins durchtesten, um dem
Unterschied auf die Spur zu kommen.
Formal ist die Behandlung von Leerzeichen in XHTML und HTML
auch unterschiedlich, wobei der MSIE gar kein XHTML kann. Da
das Dokument aber sowieso immer (fälschlich) als text/html
ausgeliefert wird, sollten eigentlich auch die anderen browser
nur ihren Markierungssuppen-parser verwenden, der das als
fehlerhaftes HTML interpretiert, insofern also erstmal kein
Unterschied zum MSIE, sollte man meinen, alle interpretieren das
als fehlerhaftes HTML und nicht als korrektes XML.
Ich hätte nicht gedacht das uns diese kleinigkeit wieder einmal so viele Probleme bereitet.
Ersteinmal vielen, vielen Dank für deine Hilfe der Zeilenumbruch ist das Problem gewesen. Ich werde nun mit den CSS Attributen ein wenig rumtricksen damit ich diese trozdem verwenden kann, da ich finde das die Menupunkte untereinander im Source besser aussehen.
Noch besser wäre es allerdings, auf diese “DIV-Suppe” zu verzichten und stattdessen eine simple Liste zu nehmen… so wie bei selfhtml ausreichend beschrieben.
Menülisten sind ja in HTML4 als veraltet gekennzeichnet und
tauchen in strict gar nicht mehr auf, feiern aber im
HTML5-Arbeitsentwurf eine Wiederauferstehung. ul- oder ol-Listen
sind für den Zweck ja auch nicht sehr spezifisch, dl auch nicht,
insofern ist da die Verwendung von div schon schwach, aber der
von ul, ol oder dl auch nicht so viel besser.
Ob nun display inline oder inline-block oder float besser ist, ist
ein wenig Geschmacksache. inline-block ist vermutlich für den
Zweck ganz nett, ist aber neu in CSS2.1, wie sich da ja auch die
Regeln für float (bzw clear) etwas geändert haben (was die
Sache jedenfalls spannend macht, welcher browser da bereits
was implementiert hat und wie dann das angezeigt wird - so ein
versionsloses CSS hat zusammen mit real existierenden browsern
unvermeidlich immer etwas von einem Überraschungsei ;o)
für die sinnvollste Lösung, da sich hier komplexe Strukturen mit mehreren Navigationsebenen (ok, hier noch nicht der Fall, könnte aber werden…) besser abbilden lassen.
ist imo Geschmackssache,
ist nicht für diese Linkliste gedacht.
Aber wie gesagt: alles nur vom semantischen Standpunkt aus betrachtet. Was nun wirklich sinnvoll ist, wird sich hier sicherlich nicht abschließend klären lassen - es lässt sich aber hervorragend darüber streiten
i.deFix - hängt stark vom browser ab, bei der alten Mozilla-Suite
und dem Nachfolger SeaMonkey oder Iceape funktioniert es
ganz gut. Irgendwann hat sich dann auch Opera mal entschlossen,
das zu interpretieren, einige Text-browser können es auch.
Daher nutze ich das bei einigen Projekten als Hauptnavigation.
Schlecht dabei ist allerdings, daß man link-Elemente nicht
ordentlich zu Listen oder Gruppen strukturieren kann. Das sind
wiederum technische Mängel von HTML - und das wurde in den
bisherigen HTML5-Entwürfen auch nicht verbessert. Im
Gegenteil, da wird es eher schwieriger, das umzusetzen, dort
denkt man eher wieder daran, die Navigation mit einem
speziellen Element innerhalb der Seite unterzubringen, wie es
ja viele tun, weil das andere bereits seit den Anfängen von HTML
von diversen browsern komplett oder teilweise ignoriert wurde
(was dann ja auch teils der Grund ist, warum frames von
netscape erfunden wurden).
HTML und auch der Entwurf für HTML5 weisen so große
semantische Lücken auf, daß man eigentlich immer
improvisiert. Und da ist es auch wieder strittig, ob man ein
Element verwenden soll, welches wenigstens ungefähr der
semantischen Bedeutung entspricht oder lieber gleich ein div,
wenn die nur schlecht getroffen wird. Mittels XHTML+RDFa kann
man immerhin präzisieren, was man gemeint hat - in beiden
Fällen, wobei die Präzisierung nicht geradezu der Bedeutung des
verwendeten Elementes widersprechen sollte ;o)
Wegen der groben semantischen Lücken habe ich nach
Erscheinen von XHTML+RDFa und SVG tiny 1.2 eigens eine
eigene Sprache spezifiziert, mit der man die Lücken schließen
kann - oder die man alternativ verwenden kann (LML), denn nach
meiner Erfahrung kann man von der HTML5-Arbeitsgruppe nicht
erwarten, daß die hinsichtlich Semantik oder Zugänglichkeit von
Inhalten besonders viel verstehen ;o)
Scheint mir bei obigem Beispiel aber illusorisch zu sein
anzunehmen, daß da jemals semantische Feinheiten im Quelltext
auftauchen werden ;o)
