IE 7 z-index Problem

[ChiSim]

Hallo zusammen,

wahrscheinlich gibt es hier einen Thread, der das Thema bereits behandelt, jedoch wurde ich nicht fündig.

Und zwar habe ich auf meiner virtuellen Maschine unter XP sämtliche Browser zum Testen installiert. Unter anderem auch den IE 7. Bei allen Browsern, außer diesem, wird alles korrekt angezeigt.

Hier die Seite zum anschauen. Beim IE 7 wird hier zwar die Imageflow-Galerie hinter die Logos gepackt (das ging nachdem ich die Logos auf z-index:999; gesetzt hatte), jedoch wird der container-Inhalt über den Logos angezeigt. Hab schon sämtliche Einstellungen mit z-index durch. Geht aber leider nicht.

Hat jemand nen Lösungsvorschlag?

Vielen Dank vorab!

[Silvano]

Hallo ChiSim

ich glaube beim IE7 muss das Element noch

position:relative;

drin haben damit es funktioniert.

Gruss Silvano

[ChiSim]

Bringt nix... Immernoch hinter dem container

[soweit_ok]

Der IE7 hat einen z-index-Bug. Wenn irgendwo in der Hierarchie ein absolut positioniertes Element dazwischen ist, wird es von allen anderen überlagert, egal welcher z-index vergeben wurde. Evtl. musst Dein ganzes zughöriges CSS mal durchgehen. Lass Dir die Elemente der Seite doch auch mal im Firebug markiert anzeigen, dann siehst Du genau, was los ist.

Wenn garnichts hilft, lass die Seite viell. mal validieren. Falls irgendwo ungültiges HTML versteckt ist, kann´s den IE auch ziemlich durcheinander bringen.

Mit Google findet man übrigens nach meiner Erfahrung oft mehr Forenbeiträge als mit dem Forum-Suchfeld. Ich verwende als Suchmuster immer "contao thema/problem". Hab mal kurz "contao ie7 z-index und positionierung" probiert, aber nicht angeschaut. Werden reichlich Treffer angezeigt, auch welche im englischsprachigen Forum.

[wotank]

ich glaube beim IE7 muss das Element noch

position:relative;

drin haben damit es funktioniert.

das kann man so leider nicht sagen.
Der IE7 kommt oft nicht gut zurecht, wenn ein Element pos. relative und kein Haslayout hat. Das gilt auch für dessen Nachfahren!
Daraus kann man eine Faustregel ableiten:
Ein relativ positionierter Container ohne HasLayout ist nicht stabil und hat auch keine stabilen Nachfahren.

Leider stehen in der contao.css ein paar Anweisungen, die immer wieder für Probleme sorgen.
.inside bekommt dort position:relative;. .inside hat auch fast nie HasLayout.
overflow:hidden für .block ist auch so ein Kandidat für vielfältige Probleme auch in modernen Browsern.

Der z-index-Bug ist ein irregulärer Stapelkontext der jedem positionierten Element (auch den relativen!) ganz ohne z-index eine Art Stapelkontext zuordnet solange HasLayout=true für dieses Element gilt, als wäre z-index:0; gesetzt.

Meine Empfehlung ist erst mal alle unnötigen Positionierungen entfernen und dann die Stapelung neu aufbauen.

Zum Verständnis der Stapelung könntest du dir diesen Artikel mal anschauen.

[ChiSim]

Vielen Dank euch beiden für die fachlichen Auskünfte. Ich werde versuchen das Problem nach euren Ansätzen zu lösen.

@soweit_ok
Ja, die Sufu liefert hier ab- und zu mal komische Ergebnise. Danke für den Tipp. Werd ich in Zukunft mal über el googlo versuchen.

@wotank
Könnte man in der contao.css das HasLayout mit false deklarieren, um dieses Problem zu lösen, oder würde das andere Probleme mit sich bringen? Schöner webblog. Sehr gut erklärt. Ich denke, da werde ich mir ab- und zu mal was von abschauen können.

Viele Grüße

[ChiSim]

???...??? Keine Ahnung, ob das jetzt ne gute Lösung ist, aber ich hab jetzt einfach ein reset CSS mit Conditional comment mit "if IE7" erstellt, bei dem ich im container

float:none;
position:relative;
z-index:-500;

gesetzt habe. Und siehe da - es funktioniert!

[soweit_ok]

Bzgl. guter Lösungen und möglicher Seiteneffekte hier noch ein Link zu einem recht umfassenden und mit diversen Tests angereicherten Artikel zum Thema "HasLayout" ...

http://onhavinglayout.fwpf-webdesign.de/

[ChiSim]

Genau da drauf bin ich vorher auch schon drauf gestoßen. Hab ich mal angelesen... sehr umfangreich. Meine Lösung scheint nicht wirklich gut zu sein, da ich nun das Problem habe, dass Formulareingabe und Map nicht mehr richtig funktionieren, da sie teilweise von den anderen divs überlagert werden.

[wotank]

@wotank
Könnte man in der contao.css das HasLayout mit false deklarieren, um dieses Problem zu lösen, oder würde das andere Probleme mit sich bringen? Schöner webblog.

HasLayout = false ist (praktisch) nie eine gute Idee. Nur in extrem seltenen Fällen ist das eine Lösung.

???...??? Keine Ahnung, ob das jetzt ne gute Lösung ist, aber ich hab jetzt einfach ein reset CSS mit Conditional comment mit "if IE7" erstellt, bei dem ich im container

float:none;
position:relative;
z-index:-500;

gesetzt habe. Und siehe da - es funktioniert!

umpf!

Das klingt gar nicht gut.

Zur den CSS-Dateien und Cond. Comments.:
Lesestoff zu Conditonal Comments

Das einfachste für eine eigene CSS-Datei und eigene Conditonal Comments ist wenn du die fe_page.tpl in deinem Sinne modifizierst und die geänderte datei im Backend unter Templates ablegst.
Das machst du so:
Backend-Modul Templates öffnen, oben auf Neues Template klicken,
Aus der Liste die fe_page.tpl auswählen.
Im Zielverzeichnis Templates abspeichern
Auf das blaue Symbol zum Bearbeiten der fe_page.tpl klicken,
Nach dieser Zeile (ca. Zeile 13):

<?php echo $this->stylesheets; ?>

fügst du z.B. folgendes ein:

<link type="text/css" rel="stylesheet" href="tl_files/themes/dein-theme/bildschirm.css" media="screen" />
<link type="text/css" rel="stylesheet" href="tl_files/themes/dein-theme/druck.css" media="print" />
     <!--[if lte IE 8]>
     <link rel="stylesheet" type="text/css" href="tl_files/themes/dein-theme/ie.css" media="screen" />
     <![endif]--> 

Die erstellten CSS-Dateien sowie die Änderungen derselben lädst du in diesen
Ordner (tl_files/themes/dein-theme/) hoch.

Da deine Dateien im Quelltext nun nach den contao-css-Dateien, ist es nun einfach deren Anweisungen zu überschreiben.
Dabei mußt du nur auf ausreichende Spezifität der Anweisungen achten.

Wenn du dir selber einen Gefallen tun willst, bestell dir dieses Buch.
Lernen und gleich mitbasteln, besser gehts nicht.

[soweit_ok]

Deshalb dachte ich ja gestern auch, Du solltest Dir am besten mal alles, was das beeinflussen könnte, mit Firebug anzeigen lassen, u. a. auch die Schichten, wie z. B. "inside" und viell. auch noch eigene Layoutbereiche, die ggf. zusätzlich eingebaut sind. Ich erinnere mich bspw. wie ein clearfix in einem Contao-CSS meinen Mainbereich unterm Header nur im IE ca. 10px nach unten verschob und damit die Optik einer sekundären Navi zerstörte. Ohne Firebug hätte ich die Ursache vielleicht nie gefunden.

Die Schichten geben natürlich viel Flexibilität, die man auch gut gebrauchen kann und erst recht im Fall eines perfekt funktionierenden / kontrollierten Liquid- oder Hybriddesigns. Mit wüster Stapelei nach dem "try and error"-Prinzip kann man auch dadurch jedoch schnell in Teufels Küche kommen. Siehst Du ja selber. Aber man lernt ja nie aus und manchmal kann ein Gestaltungskompromiss besser sein als dieser Sch... dauernd mit entspr. Zeitaufwand.

[soweit_ok]

Alternativ zu wotanks Tipp mit der CSS-Verlinkung in fe_page.tpl gehts ebenso unter "zusätzliche <head>-Tags" im jeweiligen Layout. Erscheint mir dort sogar idealer bei Layouts, die nur auf spezifischen Seiten eingesetzt werden. Wobei mir grad einfällt, dass ich garnicht weiß, wie das kombinierbar wäre bzw. ob es bei Verwendung beider Methoden eigentlich vor oder nach den in fe_page.tpl eingefügten Links im generierten Quelltext ausgegeben würde. Was ja wegen des Überschreibens nicht egal ist.

[pmmueller]

AWobei mir grad einfällt, dass ich garnicht weiß, wie das kombinierbar wäre bzw. ob es bei Verwendung beider Methoden eigentlich vor oder nach den in fe_page.tpl eingefügten Links im generierten Quelltext ausgegeben würde. Was ja wegen des Überschreibens nicht egal ist.

Die Sachen kommen wie folgt in die fe_page.tpl:

• Seitenlayout-Konfig (Spalten etc.): $this->framework
• Interne Stylesheets: $this->stylesheets
• Zusätzliche Head-Tags: $this->head

In dieser Reihenfolge, wenn ich mich richtig erinnere. Ein Vorteil des eigenen link-Elements im Seitentemplate ist, dass man das beliebig platzieren kann.

[soweit_ok]

Danke für die Aufklärung.

[Andreas]

Dass die zusätzlichen <head>-Tags als letztes kommen stimmt und macht Sinn, da man mit eigenem CSS eigentlich immer das automatisch generierte überschreiben will.

Wollte eigentlich nur noch gesagt haben, dass das Einbinden übers Seitenlayout mit dem Feld 'Zusätzliche <head>-Tags' auch einen gewaltigen Vorteil bietet. Du hast nach einem Update wieder das neue fe_page.tpl im Gebrauch, was du andernfalls erst auf Änderungen kontrollieren musst. Ich empfehle auch ein importiertes fe_page.tpl auf jeden Fall umzubenennen und im Layout neu einzubinden. Da man nachher sonst nicht mehr weiß, ob man mit einer modifizierten Version oder dem Original arbeitet.

Gruß Andreas

[pmmueller]

Wollte eigentlich nur noch gesagt haben, dass das Einbinden übers Seitenlayout mit dem Feld 'Zusätzliche <head>-Tags' auch einen gewaltigen Vorteil bietet. Du hast nach einem Update wieder das neue fe_page.tpl im Gebrauch, was du andernfalls erst auf Änderungen kontrollieren musst.

Da hast du Recht. Das IST ein echter Vorteil. Da kann ich nix gegen sagen ;-)

Den Namen des Seitentemplates ändere ich bei so kleinen Anpassungen meist nicht, denn das reine Vorhandensein einer fe_page.tpl im templates-Ordner signalisiert ja schon, dass ich da was geändert habe. Die Änderungen selbst schreibe ich mir als PHP-Kommentar in das Template. Beim Einsatz eines komplett anderen CSS-Frameworks wie YAML benenne ich das Seitentemplate entsprechend um.

[Andreas]

Den Namen des Seitentemplates ändere ich bei so kleinen Anpassungen meist nicht,...

Mach ich ja auch, aber nicht weitersagen. Ist nämlich blöd, wenn ich in ein Kunden-BE komme und der Templates-Ordner ist zugemüllt mit Templates, teilweise in der Originalbezeichnung. Da dann überall default diese Templates genommen werden muss ich im Prinzip kontrollieren, ob der Kunde sie verändert hat. Hat er aber eine eigene Bezeichnung gewählt, sehe ich im BE ja in den Template-Auswahlfeldern, ob ein angepasstes Template ausgewählt wurde. Und kann mich dort, wo das Default-Template gewählt wurde darauf verlassen (oder auch nicht), dass hier das Core-Template zum Einsatz kommt. ;-)

Gruß Andreas

[soweit_ok]

So ähnlich wie pmmueller seh ich das mit der Template-Umbenennung auch. Wenn eine Modifikation überall eingesetzt wird, belasse ich es bei dem Originalnamen. Brauche ich im Seitenlaylut unterschiedliche Fassungen, benenne ich sie um. Anderenfalls würde ja immer das modifizierte statt des Originals verwendet.

Was mich in dem Zusammenhang noch interessieren würde: Wenn man ein importiertes Template gleichen Namens wieder löscht, wird das dann in der Datenbank auch ohne Fehler komplett entfernt und von Contao wieder das Original benutzt? Hatte noch keine Zeit, das mal zu überprüfen und mich deshalb bislang nicht getraut, nicht mehr benötigte dieser Templates wieder zu löschen. Obwohl alles andere unlogisch wäre, aber das schützt schließlich nicht vor möglichen internen Fehlern.

[hnuecke]

Soweit ich die Logik verstanden habe, schaut Contao einfach in der Reihenfolge:
1. templates/modulename/modul.tpl
2. templates/modul.tpl
3. system/modules/modulname/templates/modul.tpl

Sobald die modul.tpl gefunden wird, wird sie genommen und die Suche abgebrochen.
Wenn man also an allen drei Stellen eine modul.tpl hat, wird die 1. genommen.
Löscht man diese, wird einfach die 2. genommen.
Wird auch die gelöscht, wird die originale modul.tpl aus 3. genommen

[xchs]

...muss ich im Prinzip kontrollieren, ob der Kunde sie verändert hat.

Du lässt Redakteure an die Templates ran?

[Andreas]

S
1. templates/modulename/modul.tpl

Den Punkt kannte ich noch überhaupt nicht.

Bei dem Seitenlayout ist es so, dass sich da in der DB überhaupt nichts ändert. Es steht fe_page im Feld 'template'. Wenn du jetzt ein neues Template aus einem Original-Template erstellst, dann wird eine Kopie des Originals in den Ordner ROOT/templates/ gelegt und dieses wird dann anstelle des Originals genommen. Wenn du das wieder löschst wird einfach wieder das Original aus dem Core genommen.

Bei der Vorgehensweise von Contao dachte ich immer, dass es andersherum geht - die Templates aus dem Core werden eingelesen und zum Schluss die aus dem Ordner ROOT/templates/, und wenn da eins gefunden wird, was es vorher schon gab, wird das eben überschrieben. Ich lass mich aber gerne eines Besseren belehren.

Gruß Andreas

[Andreas]

Du lässt Redakteure an die Templates ran?

Nein Wenn ich einen Auftrag bekommen in der Art: Kannst du mir dies und das an meiner Contao-Installation machen?

[soweit_ok]

@Andreas
So wie Du es im letzten Absatz beschriebst, hatte ich es bislang auch angenommen. Aber egal, Hauptsache es funktioniert.