Safari und <div>s ohne gesetzte Breite

[globe]

n'abend,

ich hätte da gerne mal ein Problem.

ich schrieb vor kurzem den tabManager - ein kleines Javascript-Tool um tabbed-panels zu ermöglichen, möglichst generisch gehalten, kann das Ding auch einiges was kein Mensch braucht. Nur eins kann er nicht; mit Safari spielen.

Safari scheint meinem armen kleinen tabManager Schäufelchen und Eimerchen zu klauen, wenn es darum geht zu einem anderen Tab zu wechseln. Konkret weigert sich Safari - im Gegensatz zu Firefox und Internet Exploder - die Panels mit voller Breite des tabManagers anzuzeigen.

Würde ich den Panels (per CSS) eine Breite von 100% zuweisen, würden sich richtige[tm] Browser wie Kinder im Sandkasten über Margin und Padding freuen. Das fällt also erstmal flach.

Der switchTo-Funktion, welche den Tausch des aktuell sichtbaren Panels regelt, habe ich dann folgende Zeile hinzugfügt:

  
panels[tabID].width = panels[currentID].offsetWidth + 'px';  

Lustig ist, wenn ein Tab - welches rechts vom aktuellen angeordnet ist - angeklickt wird, wird das Panel nun mit gewünschter Breite angezeigt. Wird allerdings ein Panel links vom aktuellen angeklickt, so ist das Panel wieder ~40px breit. Obige Zeile wird aber bei jedem switchTo ausgeführt, ob ein Panel rechts oder links vom Aktuellen liegt, spielt bei der Funktion absolut keine Rolle.

Meine Theorie ist, dass Safari ein Problem damit hat, wenn das anzuzeigende <div> oberhalb des aktuellen liegt - was es im Falle eines Tabs zur Linken des Aktuellen ja tut.

Hab ich hier einen Safari-Bug gefunden? Bin ich einfach nur zu doof das richtig zu lösen? Was ist hier eigentlich los?

Im Voraus vielen Dank für jegliche - helfenden - Hinweise.

weiterhin schönen abend...

[wahsaga]

hi globe,

mangels Safari kann ich zu den Ursachen des Problems nicht viel sagen.

Der switchTo-Funktion, welche den Tausch des aktuell sichtbaren Panels regelt, habe ich dann folgende Zeile hinzugfügt:

panels[tabID].width = panels[currentID].offsetWidth + 'px';

  
Wobei du im aktuell unter zuvor genanntem URL eingebundenen Script das anhängen der Maßeinheit 'px' noch auskommentiert hast - ist das beabsichtigt?  
  
~~~javascript
 // set width of panel switching to, to compensate some safari lacks  
 panels[tabID].width = panels[currentID].offsetWidth;// + 'px';

Lustig ist, wenn ein Tab - welches rechts vom aktuellen angeordnet ist - angeklickt wird, wird das Panel nun mit gewünschter Breite angezeigt. Wird allerdings ein Panel links vom aktuellen angeklickt, so ist das Panel wieder ~40px breit. Obige Zeile wird aber bei jedem switchTo ausgeführt, ob ein Panel rechts oder links vom Aktuellen liegt, spielt bei der Funktion absolut keine Rolle.

Kann ich wie gesagt mangels eines Safaris zum Nachvollziehen nichts zu sagen.

Aber generell: Aus welchem Grund ist es denn erforderlich, die Breite für ein einzublendendes Tab aus der des aktuell eingeblendeten herzuleiten? Ich kann das aktuell noch nicht ganz nachvollziehen.
Wäre es nicht vielleicht auch möglich, bspw. die Breite des umgebenden Containers abzufragen? (Oder spricht da dann wieder eine margin/padding-Geschichte dagegen?)

Meine Theorie ist, dass Safari ein Problem damit hat, wenn das anzuzeigende <div> oberhalb des aktuellen liegt - was es im Falle eines Tabs zur Linken des Aktuellen ja tut.

Mit "oberhalb" meinst du im Quelltext bzw. DOM-Baum vor einem anderen liegend?
Auf die Darstellung ist es wohl nicht bezogen - zumindest sehe ich dich nirgends z-index zum ein-/ausblenden von Tabs benutzen, denn das machst du ja über display.

gruß,
wahsaga

[globe]

n'abend,

Wobei du im aktuell unter zuvor genanntem URL eingebundenen Script das anhängen der Maßeinheit 'px' noch auskommentiert hast - ist das beabsichtigt?

Absicht ist relativ. Ich habe wie bescheuert alles Mögliche ausprobiert. Ob da nun ein 'px' dahinter hing oder nicht spielte keine Rolle. Wohl vergessen wieder einzukommentieren.

Kann ich wie gesagt mangels eines Safaris zum Nachvollziehen nichts zu sagen.

Das denke ich mir, denn in jedem anderen Brwoser schaut der tabManger auch "richtig" aus.

Aber generell: Aus welchem Grund ist es denn erforderlich, die Breite für ein einzublendendes Tab aus der des aktuell eingeblendeten herzuleiten? Ich kann das aktuell noch nicht ganz nachvollziehen.

Generell ist das natürlich *nicht* von Nöten. FireFox, Opera und selbst der Internet Explorer zeigen die Panels mit voller Breite an - also so, wie man es erwarten würde.

Wäre es nicht vielleicht auch möglich, bspw. die Breite des umgebenden Containers abzufragen? (Oder spricht da dann wieder eine margin/padding-Geschichte dagegen?)

Natürlich könnte man die Breite des Containers abfragen, margin und padding abziehen und als Breite des Panels setzen. Da der tabManager aber style-los bleiben soll - sprich das stylesheet (und damit auch padding und margin) nach belieben geändert werden sollen - kann das nicht runtergerechnet werden.

Mit "oberhalb" meinst du im Quelltext bzw. DOM-Baum vor einem anderen liegend?

Korrekt. Ich spreche von "oberhalb des Elements im DOM-Tree".

Auf die Darstellung ist es wohl nicht bezogen - zumindest sehe ich dich nirgends z-index zum ein-/ausblenden von Tabs benutzen, denn das machst du ja über display.

Grundsätzlich ist die display-methode ja eine recht einfache Geschichte. ich denke mit z-index würde es wieder andere Probleme geben.

weiterhin schönen abend...

[wahsaga]

hi,

Generell ist das natürlich *nicht* von Nöten. FireFox, Opera und selbst der Internet Explorer zeigen die Panels mit voller Breite an - also so, wie man es erwarten würde.

Also ist dieser Versuch eines Workarounds rein für Safari gedacht?

Wäre es nicht vielleicht auch möglich, bspw. die Breite des umgebenden Containers abzufragen? (Oder spricht da dann wieder eine margin/padding-Geschichte dagegen?)

Natürlich könnte man die Breite des Containers abfragen, margin und padding abziehen und als Breite des Panels setzen. Da der tabManager aber style-los bleiben soll - sprich das stylesheet (und damit auch padding und margin) nach belieben geändert werden sollen - kann das nicht runtergerechnet werden.

Ja, das dachte ich mir.
Sofern Safari computedStyle/currentStyle o.ä. unterstützt, könnte man die jeweiligen Werte dynamisch auslesen ... aber auch nicht sonderlich schön, bzw. frickelig.

gruß,
wahsaga

[globe]

n'abend,

Also ist dieser Versuch eines Workarounds rein für Safari gedacht?

Korrekt. In den anderen - gängigen - Browsern tut der tabManager wie er soll. Das Problem - und dessen Lösung - sind rein safarischer Natur.

Ja, das dachte ich mir.
Sofern Safari computedStyle/currentStyle o.ä. unterstützt, könnte man die jeweiligen Werte dynamisch auslesen ... aber auch nicht sonderlich schön, bzw. frickelig.

Eine "schöne" Lösung des Problems wird es wohl sowieso nicht geben. Workarounds sind per Definition "unschön".
Du sprichst hier von computedStyle / currentStyle, von denen ich bislang noch nichts gehört habe. Werde mich mal auf die Suche machen. Wenn dennoch nützliche Links in deiner Sammlung rumschwirren, werde ich mich nicht beschweren, wenn du diese mit mir teilst ;)

weiterhin schönen abend...

[wahsaga]

hi,

Du sprichst hier von computedStyle / currentStyle, von denen ich bislang noch nichts gehört habe. Werde mich mal auf die Suche machen. Wenn dennoch nützliche Links in deiner Sammlung rumschwirren, werde ich mich nicht beschweren, wenn du diese mit mir teilst ;)

z.B. „getComputedStyle” für alle Browser könnte einen Ansatz liefern - allerdings finde ich da gerade auch nicht erwähnt, ob Safari soetwas überhaupt beherrscht, da werden wohl nur die "großen" Browser betrachtet.

gruß,
wahsaga

[globe]

n'abend,

z.B. „getComputedStyle” für alle Browser könnte einen Ansatz liefern - allerdings finde ich da gerade auch nicht erwähnt, ob Safari soetwas überhaupt beherrscht, da werden wohl nur die "großen" Browser betrachtet.

Get the rendered style of an element behauptet, dass Safari das könne ;)

weiterhin schönen abend...

[globe]

n'abend,

so, dann bedanke ich mich für den computedStyle-Hinweis...
Das Problem ist nun gelöst.
Der Code zum Auslesen der Breite ist im vorhergehenden Post verlinkt.

weiterhin schönen abend...