@@at
Die gute Nachricht ist: Alle können froh sein, sich die nötigen Klassenbezeichnungen nicht mehr merken zu müssen. Weil’s mit CSS einfacher geht. Und auch besser. Zumindest für ein Grid-System haben Bootcrap u.ä. ausgedient.
Dann erkläre mir doch kurz – oder lang, wenn du die Zeit erübrigen kannst –, wie das in der Praxis aussehen wird, insbesondere mit Bezug auf die Selektoren. Oder genauer: Wie funktioniert das Zusammenspiel zwischen inhaltlich flexiblen Templates und Design im Backend des CMS für den Redakteur? Muss man dann schon beim Erstellen des Templates die Semantik jedes Inhaltselementes vorwegnehmen? Oder soll der Redakteur für jedes semantisch neue Inhaltselement den Entwickler und den Designer rufen, damit die das Template erweitern?
Nein. Es dürfte mit CSS Grid für den Redakteur viel einfacher werden. Er muss gar nicht mehr die Position der Inhaltselemente zueinander im Blick haben, sondern kann für jede Box einfach deren Position (beginnt in Spalte, Zeile) und Größe (erstreckt sich über Spalten, Zeilen) im Grid angeben. Er muss nur im Auge haben, dass sich Boxen nicht ungewünscht überlappen.
Dazu könnten ihm vier Eingabefelder (vom Typ number
) dienen, wobei die beiden für die Größe jeweils mit 1
vorbelegt sind. Das CMS generiert das Element mit den entsprechenden Angaben.
Bsp.: Redakteur sagt, er hätte ein Element gern in der 2. Spalte in der 3. Zeile und es soll sich über 2 Spalten, aber nur eine Zeile erstrecken. Das CMS generiert das Element mit style="grid-column: 2 / span 2; grid-row: 3 / span 1"
.
(Das Grid (Anzahl der Spalten/Zeilen, Spaltenbreite, Zeilenhöhe) selbst wird im Stylesheet festgelegt.)
LLAP 🖖
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory