position:fixed IE-Workaround/Problem mit width:100%

[wahsaga]

hi,

ich beschäftige mich gerade mit einem IE-workaround für position:fixed.

die methode dürfte bekannt sein, einfach html und body auf 100% höhe und overflow:hidden setzen, und da hinein dann einen ebenfalls 100% hohen container mit overflow:auto, der den scrollbaren seiteninhalt aufnimmt.
die fix zu positionierenden elemente kommen dann einfach ausserhalb dieses containers, und werden absolute positioniert.

so weit, so gut.

doch wenn ich jetzt ein fixed-element haben will, das über die gesamte breite gehen soll, habe ich ein problem.
width:100%, an 0/0 positioniert - und damit überdeckt mir dieses element auf der rechten seite den scrollbalken :-/
ist ja auch logisch, body hat durch overflow:hidden keinen scrollbalken mehr, also gehen 100% wirklich über die gesamte fensterbreite - erst darunter liegt ja mein container-div, mit seinem eigenen scrollbalken.
(siehe beispiel http://wazgnuks.net/misc/positionfixedIE.htm, oberer, roter bereich.)

was tun? width:95% oder 90% nehmen? sieht auch blöd aus, weil das je nach fenstergröße rechts unterschiedlich viel platz lässt, und somit ein mehr oder weniger großer abstand zum scrollbalken da ist.

meine idee:
ich positioniere das fixed-element nicht bei 0px von links, sondern bei {ungefähre_scrollbalkenbreite}px von rechts.
dann ragt es zwar um genau so viele pixel links aus dem anzeigebereich, aber das lässt sich ja kompensieren, in dem man seinen inhalt dann wieder ein bisschen nach rechts verschiebt.

bin jetzt im beispiel mal von einer scrollbalkenbreite von ca. 17 oder 18px ausgegangen, damit sieht es in meinen test-IEs (5.01, 5.5, 6.0) in etwa so aus, wie gewünscht - siehe blauer bereich im beispiel.

mir ist klar, dass die scrollbalkenbreite variieren kann (tut sie nach meiner beobachtung sogar schon zwischen dem 6er-IE mit dem 3D-scrollbalken von XP, und den 5ern mit ihrem eher 2D-scrollbalken), und auch sonst bin ich ja kein verfechter von pixelgenauem layouten, weil mir bewusst ist, wie viele striche einem da durch die rechnung gemacht werden können -

allerdings ist dies der beste weg, den ich finden konnte, um das hier beschriebene problem lösen zu können - meine frage: fällt jemandem ein "besserer" ein ...?

gruß,
wahsaga

p.s.: für die "anderen" browser nutze ich position:fixed, so wie's gedacht ist. das einzige, was der IE also zusätzlich braucht, ist dieser container-div (der für die anderen browser einfach vollkommen unformatiert gelassen wird), und ein wenig per conditional comments eingebundenes CSS, das die position:fixed-angabe mit absolute überschreibt, sowie die koordinaten leicht verschiebt.

in den anderen browsern könnte man zwar natürlich auch mit der gleichen methode position:fixed simulieren - aber da gibt's einige unschöne nebeneffekte bei, z.b. dass gecko-browser die seite nicht mehr per mausrad scrollen wollen (das problem ist ja m.W. bekannt bei overflow-bereichen). oder dass opera die seite nur so lange mit dem mausrad scrollen lässt, bis man einen link im inhaltsbereich nur hovert - danach geht nichts mehr, man muss erst auf eine frei stelle im dokument klicken, bevor man mit dem mausrad wieder scrollen kann; der hat da wohl irgendwie ein problem beim umgang mit dem fokus.

[willie]

hallö,

meine idee ist, einfach den scrollbalken zu "kürzen". dh, oben einen nicht-scollbaren div und drunter einen der gescrollt wird. sieht dann so ziemlich wie in frames aus. das freut ja den user ;)

beispiel auf http://www.koma69.de. (bitte nich über den inhalt meckern! außer: du kommst zum freibier ;-)

grüße aus Leipzig
willie

[wahsaga]

hi,

meine idee ist, einfach den scrollbalken zu "kürzen". dh, oben einen nicht-scollbaren div und drunter einen der gescrollt wird. sieht dann so ziemlich wie in frames aus. das freut ja den user ;)

mich aber nicht :-)

nein, danke für die idee - aber das ist nicht das, was ich haben will.

ich möchte eine "normal" aussehende seite, mit einem durchgehenden scrollbalken "für die ganze seite".

gruß,
wahsaga

[Gernot Back]

Hallo Wahsaga,

was ist schon normal?

meine idee ist, einfach den scrollbalken zu "kürzen". dh, oben einen nicht-scollbaren div und drunter einen der gescrollt wird. sieht dann so ziemlich wie in frames aus. das freut ja den user ;)

mich aber nicht :-)

nein, danke für die idee - aber das ist nicht das, was ich haben will.

ich möchte eine "normal" aussehende seite, mit einem durchgehenden scrollbalken "für die ganze seite".

Stimmt, bei so was

http://www.koma69.de.

könnten Leute, die nicht in den Quellcode schauen, denken du hättest doch Frames benutzt. - Igitt!

Gruß Gernot

[wahsaga]

hi,

Stimmt, bei so was
http://www.koma69.de.
könnten Leute, die nicht in den Quellcode schauen, denken du hättest doch Frames benutzt. - Igitt!

eben *g*

nein, das ist noch nicht einmal das hauptproblem.

oben möchte ich einen mit 100% breite durchgehenden bereich haben, aber unten sollen auch noch elemente fix positioniert sein, die nicht über die gesamte breite gehen (aber eben auch am rechten rand, wo ich wieder mein pixel-problem habe) - und "zwischen" denen soll der inhalt weiterhin durchscrollen.

das ist auch mit der lösung technisch nicht umsetzbar - egal, ob "wirkliche" frames, oder nur auf diese weise optisch simuliert.

gruß,
wahsaga

[willie]

hallö nochmal,

das ist auch mit der lösung technisch nicht umsetzbar - egal, ob "wirkliche" frames, oder nur auf diese weise optisch simuliert.

ich habe nicht frames simuliert (wer will/braucht das schon?) sondern eine elegante lösung für das eingangs beschriebene problem gesucht. das sollte beim logo-div oben links klar werden, das ist mit frames (ohne pixelgenaues positionieren) nicht machbar. mit ner entsprechend breiten schriftart (optimal: Bremen Bd BT) scrollt der content-div zudem unter dem logo-div weg.

das alles sehen natürlich nur aufmerksame besucher, die sich dafür interesieren, ob die seite frames verwendet ;-)

für mein fix positioniertes menü benötige ich keine scrollleiste. dass sie in ordentlichen browsern dort angezeigt wird, stört M$IE-user weniger...

grüße aus Leipzig
willie

[willie]

hallö,

Stimmt, bei so was
http://www.koma69.de.
könnten Leute, die nicht in den Quellcode schauen, denken du hättest doch Frames benutzt. - Igitt!

der sich mit zutiefst kritischem blick durchs internet bewegende müsste das dann auf nem browser tun, der *in diesem forum* zumeist einhellig dieselbe bewertung wie der einsatz von frames bekommt.

ich dachte: es geht bei der ablehnung von frames um deren vielfach diskutierte nachteile und nicht darum, was irgendjemand beim betrachten der seite (falsch!) vermutet.  - das wäre dann, was ich vorurteil oder auch unprofessionalität* nenne.

grüße aus Leipzig
willie

*: gibt es professionelle besucher?

[Gernot Back]

Hallo Willie,

ich dachte: es geht bei der ablehnung von frames um deren vielfach diskutierte nachteile und nicht darum, was irgendjemand beim betrachten der seite (falsch!) vermutet.  - das wäre dann, was ich vorurteil oder auch unprofessionalität* nenne.

Also was meinen Beitrag angeht, war der ironisch gemeint und der, auf den das gemünzt war, hat das auch verstanden!

Übrigens: auch die Nachteile von Frames kann man manchmal umgehen oder auch bewusst in Kauf nehmen. Bei eher privaten Seiten ist es vielleicht sogar erwünscht, wenn sie nur was für Eingeweihte bleiben und Suchmaschinen nicht darüber tratschen können.

Was mich manchmal stört, ist welcher Glaubenskrieg hier zu dem Thema tobt. Kaum stellt mal eine(r) eine Frage zu Frames, kriegt er/sie auch schon eins übergebraten, warum er/sie so was Ekliges überhaupt benutzt.

Übrigens ich bekenne mich: Ich frame gern!

Gruß Gernot

[willie]

hallö nochmal,

Also was meinen Beitrag angeht, war der ironisch gemeint und der, auf den das gemünzt war, hat das auch verstanden!
Was mich manchmal stört, ist welcher Glaubenskrieg hier zu dem Thema tobt. Kaum stellt mal eine(r) eine Frage zu Frames, kriegt er/sie auch schon eins übergebraten, warum er/sie so was Ekliges überhaupt benutzt.

na oké! da bin ich wohl grad opfer und täter im glaubenskrieg geworden... für die täterseite bitte ich um entschuldigung!

Übrigens ich bekenne mich: Ich frame gern!

ich nicht. kein problem.

grüße aus Leipzig
willie

[Gernot Back]

Hallo Wahsaga,

du scheinst ja mit CSS ähnliche Klimmzüge zur Vermeidung von Frames zu unternehmen wie ich mit JavaScript zur Vermeidung von serverseitiger Programmierung.

bin jetzt im beispiel mal von einer scrollbalkenbreite von ca. 17 oder 18px ausgegangen, damit sieht es in meinen test-IEs (5.01, 5.5, 6.0) in etwa so aus, wie gewünscht.

Das stimmt nach meinen JavaScript-Experimenten nicht ganz mit der Scrollbalkenbreite, die danach 13 Pixel beträgt, was im IE und im Opera auch exakt zu bestimmen ist.

http://forum.de.selfhtml.org/archiv/2004/7/86230/#m510098

Übrigens: Durch Abgleich der Werte für innerWidth in zwei parallelen Frames, einem mit Scrollbalken und dem anderen ohne, habe ich auch für Mozilla exakt dreizehn Pixel gemessen. Wenn man dort ein anderes Theme einstellt kommt möglicherweise aber auch mal etwas anderes heraus.

Gruß Gernot

[Gunnar Bittersmann]

du scheinst ja mit CSS ähnliche Klimmzüge zur Vermeidung von Frames zu unternehmen wie ich mit JavaScript zur Vermeidung von serverseitiger Programmierung.

Hallo Gernot,
In wahsagas "Klimmzügen" sehe ich Sinn. Aber wo ist der in deinen?
Gunnar

[Gernot Back]

Hallo Gunnar!

In wahsagas "Klimmzügen" sehe ich Sinn. Aber wo ist der in deinen?

Bei Grundlagenforschung fragt man nie nach dem Sinn. Der stellt sich im Nachhinein heraus, und wenn du offen genug bist für das was da kommt, wird er sich auch dir erschließen.

Gruß Gernot

[wahsaga]

hi,

du scheinst ja mit CSS ähnliche Klimmzüge zur Vermeidung von Frames zu unternehmen wie ich mit JavaScript zur Vermeidung von serverseitiger Programmierung.

na ja, nicht ganz.
frames vermeide ich für meine seite, ohne wenn und aber.
ich "brauche" sie hier ja auch nicht, um mehrere HTML-dokumente parallel anzuzeigen, wird ja alles serverseitig als ein dokument generiert.

ich versuche allerdings, die möglichkeiten von CSS zu nutzen, um gewisse optische effekte zu erzielen - und position:fixed ist eine davon. eigentlich ja auch vollkommen unproblematisch - nur der IE mit seiner unfähigkeit, das überhaupt umzusetzen, zwingt mich zu solchen "klimmzügen".

Das stimmt nach meinen JavaScript-Experimenten nicht ganz mit der Scrollbalkenbreite, die danach 13 Pixel beträgt, was im IE und im Opera auch exakt zu bestimmen ist.

hm, das kann ich jetzt nicht nachvollziehen.
17px von rechts positioniert sind auf meinem system die absolute untergrenze, damit der bereich nicht in den scrollbalken hereinragt.

aber ich hab's ja schon gesagt, mit dem pixelgenauen arbeiten fühle ich mich auch hier nicht wohl - und wie es scheint, zu recht, wenn das auch wieder je nach system anders ausfällt.
dass die scrollbalkenbreite auch vom user angepasst sein kann, war eh klar - aber ich hatte gedacht, dass wenigstens in der standardeinstellung diese 17px mehr oder weniger allgemeingültig wären.

mein nächster gedanke war, dass sich vielleicht die "bildschirmauflösung" auf die scrollbalkenbreite auswirkt.
also habe ich mal von 1024 auf 800 umgestellt - aber mein beispiel "passt" auf meinem system immer noch so, wie es sein sollte.

evtl. hängt es ja auch an der DPI-einstellung, die habe ich derzeit auf den voreingestellten 96 DPI.
aber die umzustellen habe ich im moment keine lust, weil mein windows dafür - überraschung! - einen neustart fordert :-)

könntest du dir bitte noch mal mein beispiel http://wazgnuks.net/misc/positionfixedIE.htm mit einem IE ansehen, und mir sagen, wie das bei dir aussieht?
sind da dann bei meinen derzeitigen 17px bei dir wirklich noch ca. vier pixel "frei", bis der scrollbalken kommt?

und wie gesagt, opera und geckos sind hier eh nicht relevant, weil die "normales" position:fixed bekommen, wie's gedacht ist. damit habe ich das problem ja dann gar nicht; dabei gehört der scrollbalken ja wirklich zum body, und nicht zu einem scrollbaren div-container - und damit gehen 100% breite auch wirklich nur bis _an_ den scrollbalken.

gruß,
wahsaga

[Franz]

mit dem Zeug hab ich mich auch schon rumgeärgert!
Ich hab das dann so gelöst, dass ich mehrere Div-Layer absolut positioniere u.a. einen für den Inhalt, der dann eine Scrollleiste bekommt. Wär das für deine Zwecke nicht auch nutzbar ?
Muss dich aber vorwarnen: der IE mag Konstruktionen nach dem Schema

position:absolute;
margin-left:20px;
margin-right:20px;

nicht - der ignoriert dann die 2. margin-Angabe d.h. du bekommst nicht Seitenbreite mit jeweils 20 Pixel Rand. Hab das dann für den IE mit conditional comments auf eine feste Breite geschrieben (für den Fall, dass der Benutzer Javascript deaktiviert hat). Ansonsten wirds beim IE mit Javascript bereichnet, sieht astrein aus.
Aber wie gesagt: Javascript !

[wahsaga]

hi,

Ich hab das dann so gelöst, dass ich mehrere Div-Layer absolut positioniere u.a. einen für den Inhalt, der dann eine Scrollleiste bekommt. Wär das für deine Zwecke nicht auch nutzbar ?

mache ich ja auch so.
die fixen elemente werden absolut positioniert, alle "scrollbaren" inhalte kommen in einen container mit höhe 100% und overflow:auto.
der container selber ist dabei nicht absolut positioniert - aber wozu auch; dadurch dass alles außerhalb von ihm absolut positioniert und damit aus dem elementfluss herausgenommen ist, beginnt er automatisch ganz oben und geht bis ganz unten.

Muss dich aber vorwarnen: der IE mag Konstruktionen nach dem Schema

position:absolute;
margin-left:20px;
margin-right:20px;

nicht - der ignoriert dann die 2. margin-Angabe d.h. du bekommst nicht Seitenbreite mit jeweils 20 Pixel Rand.

ich "brauche" den rand ja auch nur auf der rechten seite, damit die elemente dort nicht über dem scrollbalken des containers liegen und ihn teilweise verdecken.
wie gesagt, derzeit löse ich das durch absolute positionierung von rechts aus, um etwa scrollbalken-breite - 17px nach meinen versuchen.

aber auch wenn ich mich auf den box model bug des IE verlassen würde (was ich ungern tue, ich habe in lieber im compliant mode), und mit margin/padding + elementbreite = 100% da irgendwas tricksen könnte - das problem, die scrollbalkenbreite in pixeln abschätzen zu müssen, hätte ich damit ja noch ganz genauso.

Hab das dann für den IE mit conditional comments auf eine feste Breite geschrieben (für den Fall, dass der Benutzer Javascript deaktiviert hat).

wie gesagt, mit veränderten CSS-werten über conditional comments füttere ich ihn ja derzeit auch schon.

Ansonsten wirds beim IE mit Javascript bereichnet, sieht astrein aus.
Aber wie gesagt: Javascript !

danke, aber das kommt als lösung für mich auch eher nicht in frage.
ausserdem sehe ich gerade nicht, was ich da noch mit javascript anpassen sollte - scrollbalken-breite mit JS auslesen ...?

gruß,
wahsaga

[Detlef G.]

Hallo wahsaga,

... - scrollbalken-breite mit JS auslesen ...?

nein, aber z.B so:

function init(){
  document.getElementById("ue1").style.width=
  document.getElementById("container").clientWidth + "px";
}

Auf Wiederlesen
Detlef