Wie veraltete CSS-Eigenschaft "clip" in CSS-Regel für ".invisible" entfernen?

Leider befindet sich in der CSS-Regel für die Klasse ".invisible" die veraltete Eigenschaft "clip".
Bei Contao-Updates macht diese Eigenschaft regelmäßig Probleme, gerade geschehen beim Update von 5.3.3 auf 5.3.4.

Ein zeitgemäßer Ersatz für
"clip: rect(0 0 0 0);"
wäre z.B.
"clip-path: circle(0);"

Wie kann ich dauerhaft dafür sorgen, dass "clip: rect(0 0 0 0);" bei Updates nicht wieder "aktiv" wird?

Einen Workaround für ".invisible", bei dem die veraltete Eigenschaft mit der zeitgemäßen Eigenschaft überschrieben wird, möchte ich vermeiden.
Bei diesem Workaround muss für ".invisible:focus" dann zudem die veraltete Eigenschaft "clip: auto;" zusätzlich zu "clip-path: none;" notiert werden.

Am einfachsten geht so etwas m. E., wenn man das Contao-Framework gar nicht verwendet und nur eigenes CSS einsetzt.

Das stimmt wohl.

Aber "Layout-Builder" und "Responsives Layout" bringen doch schon einige sinnvolle "Features" mit.
Deshalb habe ich sie aktiviert.

Dann muss ich mir wohl die Arbeit machen, die sinnvollen "Features" aus den beiden genannten CSS-Frameworks herauszufiltern und in das eigene CSS zu integrieren.

Ich dachte, es gibt vielleicht eine einfachere Methode.

Da "Responsives Layout" den "Layout-Builder" zwingend voraussetzt, wäre es hilfreich, wenn ich wüsste, welche CSS-Regeln zu "Responsives Layout" und welche CSS-Regeln zum "Layout-Builder" gehören.

Wie kann ich das herausfinden?

Moin,

das sollte schnell gemacht sein, Du findest die CSS-Dateien bei github:

https://github.com/contao-components...o/tree/9.x/css

Welche davon jetzt genau zum Layout Builder und zum responiven Layout gehören, weiß ich allerdings nicht. Die .invisible Anweisung steht in der layout.css.

Gruß
Mathias

Die Zuordnung scheint mir doch recht eindeutig durch die Namen der CSS-Dateien gegebenzu sein.
layout.css und responsive.css.

Zitat:

---

Zitat von gbecker

... gerade geschehen beim Update von 5.3.3 auf 5.3.4.

---

sofern du die 'Bildausrichtung' im CE Text verwendest müsstest du sowieso auch dein CSS anpassen » auch hier wurde in 5.x nachgebessert.
Ich denke, dass wenn du dir ein custom.css vorrichtest, welches du dann in jede Installation mit aufnimmst und dieses stetig erweiterst, wirst du dann schon relativ rasch einen neuen, funktionierenden workaround für "veraltetet und nicht mehr vorhandene" Anweisungen haben.

Besten Dank für die Hinweise.
Ich bin dem Vorschlag von mlweb gefolgt und "Responsives Layout" sowie "Layout-Builder" durchgegangen, um die benötigten CSS-Regeln herauszufiltern. Der Umfang der benötigten CSS-Regeln hielt sich erfreulicherweise stark in Grenzen, sodass ich auf die Einbindung von "Responsives Layout" und "Layout-Builder" nun ganz verzichten kann.

Wer mit dem Gedanken spielt, auf den Einsatz der Contao-eigenen CSS-Frameworks "Responsives Layout" und "Layout-Builder" zu verzichten, sollte auf jeden Fall die CSS-Regel

Code:

---

.block {
  overflow: hidden;
}

---

aus der Layout-Builder-CSS-Datei in die eigene CSS-Datei (custom.css) übernehmen.

Beim Herausfiltern der benötigten CSS-Regeln habe ich diese unscheinbare Regel übersehen.
Sie sorgt dafür, dass die Navigation auf dem Smartphone korrekt angezeigt wird. Die CSS-Klasse ".block" wird in den Navigationsmodulen verwendet.

Ich hatte diese Regel nicht übernommen, weil beim Testen im simulierten Smartphone-Mode des Browsers kein Unterschied sichtbar wird, wenn diese Regel fehlt.
Der Unterschied ist erst beim Testen auf dem Smartphone aufgefallen.

Möglicherweise gibt es noch weitere CSS-Regeln in "Responsives Layout" und "Layout-Builder", die, wenn sie fehlen, nur beim Testen auf dem Smartphone auffallen.

Das ist eine Geschmacksfrage. Manch einer - ich z.B. - will das nicht pauschal für alle Elemente mit der Klasse block haben. Das sind standardmäßig deutlich mehr als die Navigationsmodule, z.B. auch die Artikel.
Man kann so etwas auch ganz gezielt bei bestimmten Elementen einsetzen.

Ich habe bei dem in meiner Konstellation aufgetretenen Layout-Fehler keine finale Ursachenforschung betieben.
Debugging direkt auf dem Smartphone ist nicht wirklich eine Option. Der Kiwi-Browser hat zwar Entwicklerwerkzeuge, bisher konnte ich allerdings nicht herausfinden, wie ich dort Layout und CSS sinnvoll miteinander vergleichen und verändern kann.

Mir ist der gavierende Layout-Fehler wie gesagt nicht in der Smartphone-Simulation im Desktop-Browser, sondern erst, als ich direkt auf dem Smartphone getestet habe, aufgefallen:
Das Hamburger-Icon wurde auf Grund der fehlenden "overflow: hidden" Anweisung außerhalb des Viewports positioniert. Um an das Hamburger-Icon zu gelangen musste ich die Seite nach links verschieben.
Das Kuriose dabei war, dass dieser Layout-Fehler nicht konsistent auf allen Seiten auftrat, sondern nur auf manchen.
Ich konnte auch keine besonderen Komponenten auf den betroffenen Seiten finden, die für diesen Layout-Fehler vielleicht verantwortlich gewesen sein könnten.

Mit meinem "Update" wollte ich darauf aufmerksam machen, dass ein Verzicht auf die Contao-eigenen CSS-Frameworks "Layout-Builder" und "Responsives Layout" gewisse "Gefahren" birgt.
Wie eingangs erwähnt, liefern die Contao-eigenen CSS-Frameworks doch schon einige sinnvolle "Features". Wenn sie weggelassen werden, kann dies wie in meinem Fall u.U. zu unerwünschten "Nebenwirkungen", die nicht direkt auffallen, führen.

Wer kennt die Beweggründe, die CSS-Klasse ".block" mit "overflow: hidden" als "Grundregel" einzuführen? Vielleicht könnte ich mit diesem Hintergrundwissen dem Layout-Fehler in meiner Konstellation auf die Spur kommen.

Zitat:

---

Zitat von gbecker

Wer kennt die Beweggründe, die CSS-Klasse ".block" mit "overflow: hidden" als "Grundregel" einzuführen? Vielleicht könnte ich mit diesem Hintergrundwissen dem Layout-Fehler in meiner Konstellation auf die Spur kommen.

---

Vermutlich damit dieser Container die volle Höhe einnimmt, falls sich floating elements darin befinden.

Zitat:

---

Zitat von gbecker

Wer kennt die Beweggründe, die CSS-Klasse ".block" mit "overflow: hidden" als "Grundregel" einzuführen? Vielleicht könnte ich mit diesem Hintergrundwissen dem Layout-Fehler in meiner Konstellation auf die Spur kommen.

---

Ich kann nicht für die Entwickler sprechen, die das bereits vor langer Zeit so gemacht haben. Aber auch der Kommentar im css-File legt die Vermutung nahe, dass hierdurch sichergestellt werden soll, dass in den entsprechenden Bereichen am Ende alle Floats gecleart sind und nicht Probleme bei der Darstellung der gefloateten Elemente und in anderen Bereichen verursachen. Es ist die einfachste Methode um das zu erreichen ohne auf ein clearfix zurückgreifen zu müssen.

Die .invisible Klasse ist für Screenreader wichtig und hat noch CSS-Eigenschaften, welche als Fallback für Internet-Explorer und co. funktionieren könnten.
Wenn dieses "invalide" CSS nicht korrekt ist, mache einen PR in der contao-component oder verzichte auf die Verwendung des CSS-Frameworks und schreibe dir diese selbst.

Ich verstehe immer noch nicht, warum dies stört, da es keine Auswirkungen in deinen Seiten haben sollte?

Zitat:

---

Zitat von gbecker

Wer kennt die Beweggründe, die CSS-Klasse ".block" mit "overflow: hidden" als "Grundregel" einzuführen? Vielleicht könnte ich mit diesem Hintergrundwissen dem Layout-Fehler in meiner Konstellation auf die Spur kommen.

---

Du musst das Framework von Contao nicht nutzen.
Mir ist overflow: hidden ein Dorn im Auge, da dadurch position: sticky nicht funktioniert.

Wenn du beim Ausschalten der Frameworks Seiteneffekte hast, dann musst du diese bei dir beheben, es ist kein Bug des Frameworks sondern in deinem CSS.

Zitat:

---

Zitat von zoglo

Du musst das Framework von Contao nicht nutzen.

---

Wenn es so einfach wäre, würde ich hier nicht posten.

Es geht mir nicht um Bugs im CSS-Code von Contao oder in meinem CSS-Code.
Das Thema war, einen gangbaren Weg zu finden, einerseits deprecated CSS-Code zu vermeiden und andererseits auf bestehendem CSS-Code aufzusetzen.
Ein gangbarer Weg bedeutet für mich, auf "Workaround-Code" möglichst zu verzichten.

Danke für den Hinweis auf das Thema "Floating".

In meinem CSS-Code, der überwiegend auf flexbox und grid basiert, gibt es nur ein "float" für die Checkbox im Kontaktformular und ein "float" für die Positionierung des Submenü-Icons in der Navigation. Die Seite mit dem Kontaktformular ist vom Layout-Fehler nicht betroffen. Das "float" für die Positionierung des Submenü-Icons kann ebenfalls nicht für den Layout-Fehler verantwortlich sein, weil die Navigation auf jeder Seite eingebunden ist. Es müssten also alle Seiten fehlerhaft dargestellt werden. Das ist nicht der Fall.

Das HTML-Gerüst von Contao kann aus meiner Sicht nicht unabhängig vom damit verbundenen CSS Design-Ansatz verwendet werden. Es gibt ein komplexes Geflecht von gegenseitigen Abhängigkeiten.
Wie sich an meinem Beispiel zeigt, kann grundlegender CSS-Code nicht einfach weggelassen werden, ohne dass an irgendeiner Stelle möglicherweise ein gravierender Fehler auftritt, der nur sehr schwer nachvollziehbar ist.

Es ist nachvollziehbar, wenn dein Theme ohne die Contao-Frameworks aufgebaut wurde.

Du kannst dir den Teil der Contao CSS-Frameworks kopieren und in einer eigenen CSS hinzufügen, was spricht denn dagegen es nicht selbst einzubinden?

Es ist müssig weiter darüber zu diskutieren. Viele Wege führen nach Rom.
Du hast bisher das Framework genutzt und jetzt festgestellt, dass Du einige Sachen aus dem Framework benötigst. Dann übernimmst Du halt die Regeln, die Du benötigst.

Andere (ich z.B.) haben das Framework nie verwendet und schreiben von A-Z eigenes CSS.

Das ist der Grund warum Deine Empfehlung

Zitat:

---

Zitat von gbecker

Wer mit dem Gedanken spielt, auf den Einsatz der Contao-eigenen CSS-Frameworks "Responsives Layout" und "Layout-Builder" zu verzichten, sollte auf jeden Fall die CSS-Regel

Code:

---

.block {
  overflow: hidden;
}

---

aus der Layout-Builder-CSS-Datei in die eigene CSS-Datei (custom.css) übernehmen.

---

m.E. nur für Dich und Deinen Fall korrekt ist.
Es gibt deutlich mehr Regeln aus dem Framework die entweder komplett oder in abgewandelter Form den Weg ins eigene CSS finden können oder sollen.

Ich zitiere mlweb:

Zitat:

---

Zitat von mlweb

Am einfachsten geht so etwas m. E., wenn man das Contao-Framework gar nicht verwendet und nur eigenes CSS einsetzt.

---

Wenn ich der Argumentation von zoglo folge, ist es sehr wohl angezeigt, das Contao-Framework - zumindest die grundlegenden "Responsives Layout" und "Layout-Builder" - zu verwenden, da ein vollständiges Weglassen dieser beiden Frameworks möglicherweise zu unerwünschten "Nebenwirkungen" führen kann.

Insofern ist die pauschale Antwort "Am einfachsten geht so etwas m.E., wenn man das Contao-Framework gar nicht verwendet" nicht zutreffend und führt in die Irre.

Ich denke auch nicht, dass diese Diskussion müssig ist, und ich hier nur einen Spezialfall, der nur auf mich zutrifft, poste. Wie ich bereits sagte, kann das HTML-Gerüst von Contao nicht unabhängig vom damit verbundenen CSS Design-Ansatz verwendet werden. Zoglo stimmt dieser These mit seiner Argumentation indirekt zu. Mittlerweile haben sich die CSS Design-Ansätze gewandelt. Möglicherweise kommt es bei der Verwendung von "flexbox" und "grid" zu unerwünschten "Wechselwirkungen".

Das CSS Framework von Contao existiert seit Typolight - und ist auch dementsprechend veraltet. Der Sinn des CSS Frameworks war es eine Art "Schnellstart" für die Umsetzung einer Website zu haben. Das CSS Framework existiert im Prinzip allerdings nur mehr aus Rückwärtskompatibiliätsgründen und wird in Contao 6 evt. entfernt.

Zitat:

---

Zitat von gbecker

Wenn ich Deiner Argumentation folge, ist es sehr wohl angezeigt, das Contao-Framework - zumindest die grundlegenden "Responsives Layout" und "Layout-Builder" - zu verwenden, da ein Weglassen dieser beiden möglicherweise zu unerwünschten "Nebenwirkungen" führen kann.

---

Eigenes CSS schreiben bedeutet alle Regeln, die man braucht selbst zu schreiben. Natürlich kann man dazu auch im Framework spicken um nichts zu vergessen oder einiges so zu übernehmen wie es im Framework steht. Aber man übernimmt eben nur die Regeln, die einem sinnvoll erscheinen. Regeln für bestimmte Selektoren übernimmt man gar nicht oder schreibt diese ganz anders.

Übrigens die Contao-Demo verwendet auch kein Framework.

Wenn das CSS Framework in Contao 6 möglicherweise entfernt werden soll, wird das sicherlich auch das HTML-Gerüst betreffen. Eine weniger verschachtelte HTML-Struktur wäre wünschenswert.
Mit "flexbox" und "grid" lässt sich auch eine weniger stark verschachtelte HTML-Struktur differenziert layouten.

Zitat:

---

Zitat von gbecker

Eine weniger verschachtelte HTML-Struktur wäre wünschenswert.

---

In wie fern?

Mit den neuen Twig-Templates hat sich doch schon einiges geändert an der HTML-Struktur der Content-Elemente.
Außerdem kannst Du für die HTML-Struktur Deine eigenen Templates verwenden und somit auch ganz anderes HTML rendern lassen.

Zitat:

---

Zitat von mlweb

Aber man übernimmt eben nur die Regeln, die einem sinnvoll erscheinen. Regeln für bestimmte Selektoren übernimmt man gar nicht oder schreibt diese ganz anders.

---

Genau das habe ich - wie oben beschrieben - getan. Das Ergebnis war ein für mich nicht nachvollziehbarer Darstellungsfehler, der mit den beim Coden verfügbaren Test-Tools nicht erkennbar war. Der Darstellungsfehler ist erst beim Testen auf einem realen Endgerät aufgefallen. Zudem handelt es sich um einen Darstellungsfehler, der inkonsistent auftritt.

Deshalb habe ich mit meinem Update darauf hingewiesen, dass ein Verzicht auf grundlegende CSS-Regeln aus den Contao CSS-Frameworks möglicherweise zu unerwünschten "Nebenwirkungen" führen kann.

Das HTML-Gerüst von Contao kann wie gesagt nicht ohne weiteres ohne den damit verbundenen CSS Design-Ansatz verwendet werden. Neuere CSS Design-Ansätze müssen diesem Umstand anscheinend in besonderer Weise Rechnung tragen.

Zitat:

---

Zitat von mlweb

Außerdem kannst Du für die HTML-Struktur Deine eigenen Templates verwenden und somit auch ganz anderes HTML rendern lassen.

---

Auf diesem Weg stellt sich dann irgendwann die Frage, warum ich überhaupt Contao und nicht ein anderes CMS verwende. Ich denke schon, dass es gut und sinnvoll ist, auf bestehenden Strukturen aufzusetzen und sich auf den gegebenen Design-Ansatz einzulassen, um ein nachhaltiges Ergebnis zu erzielen. Contao liefert ja semantisch gut aufgebautes HTML. Warum sollte ich das nicht nutzen, vorallem in Hinblick auf Wartung und Updates.

Zitat:

---

Zitat von Spooky

In wie fern?

---

Zum Beispiel:
<main id="main"> in einem <div id="container">
<div class="rte"> in einem <div class="content-text">

Sicherlich haben diese DIVs eine bestimmte Funktion innerhalb des CMS, aber möglicherweise könnten diese DIVs auch aus dem System entfernt werden.

Verschlankungen dieser Art könnten die HTML-Struktur übersichtlicher machen.

Da besteht kein Grund zur Änderung. Der .rte Wrapper ist sogar eine Neuerung in Contao 5.

Zitat:

---

Zitat von Spooky

Da besteht kein Grund zur Änderung. Der .rte Wrapper ist sogar eine Neuerung in Contao 5.

---

Steht "rte" für "Rich Text Editor"?

Laut BennyBorn ist der .rte Wrapper für die Positionierung von Bildern mittels Flexbox gedacht:

Zitat:

---

Zitat von BennyBorn

Hab mich noch nicht mit CTO5 beschäftigt aber ich würde mal annehmen um die Bilder endlich nicht mehr zu floaten, sondern ordentlich mit Flexbox neben den Content setzen zu können. Mache ich bei meinen Templates auch meistens so.

---

Das wäre dann ja sogar in meinem Sinne. :)

Zitat:

---

Zitat von gbecker

Steht "rte" für "Rich Text Editor"?

---

Genau. In den neuen Templates von Contao 5 ist der textliche Inhalt eines Text Inhaltselementes nun in einem <div> gruppiert, was diverse Styling Aufgaben erleichtert. Wenn du es anders haben willst kannst du dir, wie immer, die Templates anpassen.

Zitat:

---

Zitat von zoglo

Mir ist overflow: hidden ein Dorn im Auge, da dadurch position: sticky nicht funktioniert.

---

Danke für Deinen Hinweis auf "position: sticky". Er hat mich bei der Fehlersuche auf die richtige Spur gebracht.

Ich verwende in meinem CSS nicht "position: sticky", sondern "position: fixed", und zwar für den "#header".

Hierbei verhält es sich genau umgekehrt: Bei Verwendung von "position: fixed" muss ich zwingend auch "overflow: hidden" für ".block" setzen, wenn ich gleichzeitig irgendwo auf der Seite ein Bild mit einem negativen margin-right im Artikel-Modul einbinde. Das Artikel-Modul hat ja standardmäßig die Klasse ".block". Ohne Angabe von "overflow: hidden" wird in diesem Fall das Hamburger-Icon rechts außerhalb des Viewports positioniert.