nicht angemeldet
Float-Bug im IE 5?
Hi,
eigentlich will ich die von mir erstellten Websites ja so barrierefrei und Plattform-/Browserübergreifend wie möglich machen und selbige auch in so vielen Browsern wie möglich testen.
Deswegen habe ich oben verlinkte (sich noch im Aufbau befindliche) Site auch mit dem IE (genauergesgt iirc IE 5.5) getestet. Dort trat aber ein merkwürdiger Bug auf: Der #content-Bereich rechts der gefloateten Navigation, der mit margin-left auch unterhalb Selbiger auf gleichbleidendem Abstand gehalten wird, passt sich nicht der Breite des Browser-Viewports an, wie gedacht, sondern bleibt auf eine sehr geringe Breite (die iirc ca. der der Navigation entspricht) beschränkt.
Meine Frage lautet nun, an welcher Kombination von CSS-Eigenschaften dieses Verhalten liegt und wie man das ganze umgehen kann.
MfG,
Max.
-
hi,
(IE 5.5) getestet. Dort trat aber ein merkwürdiger Bug auf: Der #content-Bereich rechts der gefloateten Navigation, der mit margin-left auch unterhalb Selbiger auf gleichbleidendem Abstand gehalten wird, passt sich nicht der Breite des Browser-Viewports an, wie gedacht, sondern bleibt auf eine sehr geringe Breite (die iirc ca. der der Navigation entspricht) beschränkt.
Meine Frage lautet nun, an welcher Kombination von CSS-Eigenschaften dieses Verhalten liegt und wie man das ganze umgehen kann.schon mal versucht, dem #content explizit eine breite von 100% zuzuweisen?
gruss,
wahsaga-
Hi,
schon mal versucht, dem #content explizit eine breite von 100% zuzuweisen?
Äh, nein.
Aber die Navi hat doch schon eine gewisse Breite, dann müsste die gesamte Seite doch breiter als das Browserfenster werden?
Ich werd's trotzdem mal ausprobieren.MfG,
Max.-
Hi,
wenn ich dem #content die 100% Breite zuweise, wird die gesamte Breite dann wie erwartet im Opera breiter als der Vieport (siehe Bild: http://free.pages.at/maxb88/Operashot.jpg)...
-
-
-
Der #content-Bereich rechts der gefloateten Navigation, der mit margin-left auch unterhalb Selbiger auf gleichbleidendem Abstand gehalten wird, passt sich nicht der Breite des Browser-Viewports an, wie gedacht, sondern bleibt auf eine sehr geringe Breite (die iirc ca. der der Navigation entspricht) beschränkt.
Meine Frage lautet nun, an welcher Kombination von CSS-Eigenschaften dieses Verhalten liegt und wie man das ganze umgehen kann.Der MSIE 5.x hat einen Bug, der ihn eine Kombination aus einem Universalselektor und einem Attributselektoren als Universalselektor interpretieren lässt. Den Selektor der Regel
*[id^="foo"] div {
display:block;
width:13em;
margin:0.2em auto
}interpretiert er als »* div« und vergibt die Eigenschaften an jedes div-Element, somit auch an #content. Das gilt auch für die anderen Regeln mit ähnlichem Selektor, die eine davor und die drei danach.
Du willst offenbar durch die Selektorwahl bestimmten Browsern spezielle Regeln geben, vielleicht nutzt du eine andere Möglichkeit, die MSIE 5.x nicht missverstehen kann.
Übrigens gäbe es viele Anmerkungen zu deiner Seite, wieso nutzt du etwa XHTML 1.1 als text/html? XHTML 1.1 erlaubt per se keine HTML-Kompatibilität und ist daher nicht empfehlenswert, wenn du »browserübergreifend« schreiben willst. Dazu wirst du aber detaillierte Postings von mir im Archiv finden. Die Angabe von application/xhtml+xml im meta-Element ist widersinnig, weil das meta-Element sowieso nur relevant ist, wenn das Dokument als text/html ausgeliefert wird, und dann ist eben text/html der Inhaltstyp, obwohl es wie gesagt unpassend ist, XHTML 1.1 als HTML an HTML-Clients zu senden.
-
Hi,
Der MSIE 5.x hat einen Bug, der ihn eine Kombination aus einem Universalselektor und einem Attributselektoren als Universalselektor interpretieren lässt.
Achso. Und deswegen zeigt er wohl auch alle Links als Blockelemente an.
Du willst offenbar durch die Selektorwahl bestimmten Browsern spezielle Regeln geben, vielleicht nutzt du eine andere Möglichkeit, die MSIE 5.x nicht missverstehen kann.
Ja, ich will, dass das ganze nur von Mozilla umgesetzt wird, weil der fast alle regeln zu den Divs im footer versteht, nur nicht das display:inline-block. Sehr zukunftssicher ist dieses "Provisorium" aber nicht, ich überlege, ob ich das nicht anders lösen könnte...
Ich werde wohl bei den Divs noch IDs und Klassen angeben, das hält den IE 5 hofffentlich von diesen Fehlinterpretationen ab.Übrigens gäbe es viele Anmerkungen zu deiner Seite, wieso nutzt du etwa XHTML 1.1 als text/html? XHTML 1.1 erlaubt per se keine HTML-Kompatibilität und ist daher nicht empfehlenswert, wenn du »browserübergreifend« schreiben willst. Dazu wirst du aber detaillierte Postings von mir im Archiv finden. Die Angabe von application/xhtml+xml im meta-Element ist widersinnig, weil das meta-Element sowieso nur relevant ist, wenn das Dokument als text/html ausgeliefert wird, und dann ist eben text/html der Inhaltstyp, obwohl es wie gesagt unpassend ist, XHTML 1.1 als HTML an HTML-Clients zu senden.
Sorry, aber ich verstehe nicht ganz, worauf du damit hinaus willst. Sollte ich die Datei lieber unter index.xml speichern? Oder den Server einen anderen Mime-Typ versenden lassen? Und wieso soll XHTML 1.1 zu HTML "inkompatibel" sein?
Und welche Anmerkungen gäbe es noch, wo mache ich deiner Meinung nach grobe Fehler?MfG,
Max.-
Hallo.
Sorry, aber ich verstehe nicht ganz, worauf du damit hinaus willst. Sollte ich die Datei lieber unter index.xml speichern? Oder den Server einen anderen Mime-Typ versenden lassen? Und wieso soll XHTML 1.1 zu HTML "inkompatibel" sein?
Wenn XHTML 1.1 mit korrektem MIME-Typ auslieferst, verstehen es die gängigen Browser nicht. Wenn du es mit inkorrektem MIME-Typ auslieferst, nun, ist es eben inkorrekt, wenn auch die Dateien validieren und alles wie geplant angezeigt wird. Die Datei-Endung ist dabei nicht zwangsläufig wesentlich, da der MIME-Typ vom Webserver mitgeschickt wird. Meta-Angaben greifen erst, wenn kein brauchbarer MIME-Typ vom Server versandt wird.
MfG, at -
Du willst offenbar durch die Selektorwahl bestimmten Browsern spezielle Regeln geben, vielleicht nutzt du eine andere Möglichkeit, die MSIE 5.x nicht missverstehen kann.
Ja, ich will, dass das ganze nur von Mozilla umgesetzt wird, weil der fast alle regeln zu den Divs im footer versteht, nur nicht das display:inline-block.Hm, da gibt es wahrscheinlich keine bessere Methode. Vermeidbar ist aber in jedem Fall der Einsatz des Universalselektors. Zunächst einmal sind *[id^="footer"] und [id^="footer"] identische Selektoren. Da das Element mit der ID »footer« ist auch bekannt, es ist nämlich ein div-Element. also wäre auch div[id^="footer"] möglich, dann sollte MSIE 5.x die Regel ignorieren. Für die anderen kritischen Selektoren gilt ähnliches:
*[id="footer"] div --> div[id="footer"] div oder #footer[id] div
*[id="footer"] * strong --> div[id="footer"] strong oder #footer[id] strong
*[id="footer"] * em --> div[id="footer"] em oder #footer[id] em
*[id="footer"] div a:hover --> div[id="footer"] a:hover oder #footer[id] a:hoverIch werde wohl bei den Divs noch IDs und Klassen angeben, das hält den IE 5 hofffentlich von diesen Fehlinterpretationen ab.
Das sollte eigentlich nicht nötig sein.
Sorry, aber ich verstehe nicht ganz, worauf du damit hinaus willst. Sollte ich die Datei lieber unter index.xml speichern? Oder den Server einen anderen Mime-Typ versenden lassen?
Nein, jeder andere Inhaltstyp als text/html ist nicht kompatibel. Du kannst höchstens einigen Browsern, die explizit application/xhtml+xml anfordern (z.B. Mozilla/Gecko), das Dokument als solches ausliefern, es wird dann als XML verarbeitet.
Und wieso soll XHTML 1.1 zu HTML "inkompatibel" sein?
XHTML 1.0 ist zu HTML-Browsern nur unter Beachtung der Kompatibilitätsrichtlinien (http://www.w3.org/TR/xhtml1/#guidelines / http://www.edition-w3c.de/TR/2002/REC-xhtml1-20020801/#_Toc6101548) bzw. mit den dort genannten Einschränkungen kompatibel. XHTML 1.1 unterscheidet sich im Hinblick zu XHTML 1.0 in einigen Kleinigkeiten, die Kompatibilität nicht ermöglichen. Das betrifft vor allem das fehlende name-Attribut bei Linkankern, Formularen (kritisch bei JavaScript-Zugriff), Imagemaps (das usemap-Attribut hat auch einen anderne Inhaltstyp) und img (betrifft ebenfalls den JavaScript-Zugriff). Ferner Sprachauszeichnung, weil das lang-Attribut fehlt. Dann gibt es natürlich keine Möglichkeit, auf eine Transitional-Variante auszuweichen, statt applet und iframe gibt es nur object, was nicht halb so kompatibel ist.
XHTML 1.1 hat nicht den Anspruch, als text/html auf entsprechenden Clients zu funktionieren. Es gibt daher keine Spezifikation, die die Verknüpfung von XHTML 1.1 mit dem Inhaltstyp text/html »erlaubt«, es wird auch nicht empfohlen http://www.w3.org/TR/xhtml-media-types/#summary. Der passende Medientyp wäre application/xhtml+xml, das verstehen aber wie gesagt nur wenige Browser. Wenn du HTML-kompatibel schreiben willst, benutze XHTML 1.0, das ist extra für HTML-Kompatibilität ausgelegt und »darf« deshalb auch als text/html ausgeliefert werden.Und welche Anmerkungen gäbe es noch, wo mache ich deiner Meinung nach grobe Fehler?
Die Content-Style-Language ist per default text/css. Die Angabe ist also nicht nötig. Darüber hinaus verwendest du ja sowieso nahezu keine Inline-Styles. Selbst <div id="ns-div" style="color:blue; background-color:yellow; border:2px solid blue"> könntest du im Stylesheet notieren, in einem Regelsatz vor den @-Regeln.
<meta name="constributor" content="Maximilian Baumgart" /> - Das sollte wohl contributor heißen.
Wenn du sowieso alle 8-Bit-Zeichen mit Entities maskierst, kannst du auch US-ASCII als Kodierung verwenden, naheliegender wäre es, ISO-8859-1 auszureizen und die Umlaute usw. direkt ins Dokument zu schreiben.
title="Standart-Stil" - Standard wird immer noch mit »d« geschrieben...
Der Sinn von Accesskeys ist sehr umstritten. Ein paar Quellen dazu:
http://wats.ca/resources/accesskeys/19
http://www.virtuelvis.com/archives/86.html
http://www.clagnut.com/blog/204/
http://www.barrierefreies-webdesign.de/knowhow/accesskey/empfehlung.php-
Hi,
danke für die zahlreichen Anmerkungen, ich hab' jetzt mal (fast) alles korrigiert und werd' mir die Site bei Gelegenbheit noch mal im IE 5 anschauen :-).
Bei den Umlauten gibt's das Problem, dass die mein HTML-Quelltext-Editor automatisch konvertiert... Aber das lässt sich bestimmt irgendwo abschalten.
Und das mit den Acceskeys schau' ich mir auch noch mal genauer an.MfG,
Max.
-
-
-
