phpBB.de

Hallo

Da ich jetzt bei EMP das CSS so weit wie möglich umgebaut habe, habe ich dieses Thema erneut gesichtet um zu sehen, ob hier noch alles zu den Erfahrungen passt, die ich bei dem Umbau gemacht hatte. Dadurch ist mir eine Falschaussage aufgefallen:

LukeWCS hat geschrieben: 02.04.2025 19:19 Die Pseudoklasse :is() eignet sich vor allem dort, wo Selektoren einen grossen statischen Teil haben, aber nur einen kleinen variablen Teil.

Das war nicht korrekt und ich habe den Satz wie folgt geändert:

Die Pseudoklasse :is() eignet sich vor allem dort, wo Selektoren eine hohe Redundanz aufweisen.

Des Weiteren habe ich in dem besagten Beitrag auch einen zweiten Code-Block eingefügt, der die klassische Darstellung der gezeigten :is() Notation zeigt. Ausserdem als Rand-Information die jeweilige Grösse (Bytes) der Codes hinzugefügt.

Was mir u.a. beim Umbau aufgefallen ist:

1. Man braucht viel Konzentration beim Umbau, denn ruckzuck hat man hinter & entweder ein Leerzeichen eingefügt wo keines hingehört, oder umgekehrt ein Leerzeichen vergessen, wo eines sein musste.
2. Es kann passieren, dass nach der Konvertierung etwas nicht mehr so funktioniert wie vorher und die Ursache waren bei mir schlicht Fehler in der alten Notation die sich aber nie gezeigt haben, weil die Regelblöcke rein zufällig in genau der richtigen Reihenfolge in der CSS Datei angeordnet waren. Das heisst also, das man bei Nested CSS insgesamt präziser arbeiten muss.

LukeWCS hat geschrieben: 14.10.2025 18:53 nach der Konvertierung etwas nicht mehr so funktioniert wie vorher und die Ursache waren bei mir schlicht Fehler in der alten Notation die sich aber nie gezeigt haben, weil die Regelblöcke rein zufällig in genau der richtigen Reihenfolge in der CSS Datei angeordnet waren.

Hast du dafür evtl. mal ein Beispiel.

Hi Udo

Nicht aus dem Stand, weil der Umbau sehr umfangreich war und ich seitdem etliche weitere Dinge optimiert und umgestellt habe. Eines davon weiss ich aber noch zumindest ungefähr, weil mich das viel Zeit gekostet hat, bis ich kapiert hatte, wo das Problem liegt. Ich werde versuchen das nochmal zu rekonstruieren, dann melde ich mich hier wieder.

@Udo

Ich habe jetzt eine ganze Weile gebraucht (gut 2 Stunden), bis ich das rekonstruieren konnte, weil ich seitdem ja das CSS noch etliche Male überarbeitet habe. Und ich hatte das falsch in Erinnerung was das besagte Problem betrifft; nicht die Reihenfolge hat eine Rolle gespielt, sondern Spezifität. Geht also um EMP 3.1.0 Beta:

Ausgangslage ist b18, da war noch alles in klassischer Notation. Es betrifft diesen Block:

https://github.com/LukeWCS/ext-mgr-plus ... ss#L67-L86

Und die problematische Zeile war:
Diese Zeile war schlicht ein Artefakt, was ich aber erst beim Umbau bemerkte. Die Zeile hätte also schon längst entfernt gehört, aber wie das halt bei CSS so ist, sammelt sich mit der Zeit immer mehr Code an, der später gar nicht mehr relevant ist. Zum Beispiel ja auch veraltete Vendor-prefixes (z.B. -moz und -webkit) die nicht mehr benötigt werden, aber auch keine Fehler verursachen, wenn sie noch im Code sind.

Dieses Artefakt hatte aber keine Auswirkung, wegen diesem Block:

https://github.com/LukeWCS/ext-mgr-plus ... ss#L20-L23

Dieser Block ab Zeile 20, hat eine höhere Spezifität als der problematische Block ab Zeile 67, weshalb dessen padding: 3px 2px; schlicht ignoriert wurde.

Dann kam b20 wo ich schon mal alles auf Nested umgestellt hatte. Da sah der Block dann so aus:

https://github.com/LukeWCS/ext-mgr-plus ... #L123-L144

Da war noch alles okay, weil sich nur die Notation, aber nicht die Spezifität geändert hat. Dann bemerkte ich, dass ich nicht konsequent genug umgestellt hatte und sich da noch mehr zusammenfassen lies. Dann sah der Block von b21 zuerst so aus:
Ich hatte jetzt alles in #confirm zusammengefasst und dadurch habe ich die Spezifität des Selektors erhöht. Und jetzt hat sich mein alter Fehler (die überflüssige Zeile) erst gezeigt. Erst nachdem ich padding: 3px 2px; aus dem obigen Block entfernt hatte, war wieder alles im Lot.

Die anderen Probleme die ich hatte waren ähnlich gelagert, aber da war es tatsächlich die alte Reihenfolge die Probleme machte, weil ich bei der Umstellung eben nicht nur eine pure Konvertierung, sondern auch gleich eine Optimierung vorgenommen habe. Kurz gesagt, kann es beim Umbau vorkommen, dass einem alte "Fehler" einen Strich durch die Rechnung machen. Ein Grund mehr für mich, alles umzustellen.

Ich seh schon das dieses Nested nicht so einfach ist. Sollte ich dies in meinen EXTs verwenden dann nur für´s ACP. Denn es gibt sicherlich Forenbetreiber( welche etwas CSS Kenntnisse haben) und ihren eigenen Style haben und (wenn nötig) eine EXT an ihren Styles anpassen, von daher wäre für´s Frontend die klassische CSS besser geeignet.
Danke für die Erklärung und Beispiel

Nested ist nicht kompliziert, es ist einfach nur anders. Und alle Probleme die ich hatte, waren hausgemacht. Und generell ist Nested ja ein alter Hut, nämlich bei CSS Präprozessoren. Bei CSS selber hat das ja eine Ewigkeit gedauert, bis das endlich mal nativ möglich wurde.

Aber du hast recht, Ext Entwickler und Style Designer können sich da reinfuchsen. Aber "normale" Admins könnten Probleme kriegen, weil Nested halt höhere Anforderungen stellt. Für Programmierer ist so eine Struktur nicht schwer zu lernen, denn solche Strukturen nutzen sie tagtäglich. Aber die Anforderungen steigen halt überall, da macht CSS auch keine Ausnahme. Gibt bei CSS ja schon länger auch Variablen und Funktionen, was es früher ja nicht gab. Durch die ganzen neuen Features steigen die Möglichkeiten, aber halt auch die Komplexität.