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

[gbecker]

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.

[mlweb]

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

[gbecker]

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?

[mdoll]

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

[tab]

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

[derRenner]

... 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.

[gbecker]

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.

[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

.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.

[mlweb]

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.

[gbecker]

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.

[Spooky]

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.

[tab]

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.

[zoglo]

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?

[zoglo]

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.