Kuratierte Linksammlung für Webdesigner und -entwickler.
CSS-Workarounds

CSS: Schlechtes Styling (und wie man es vermeidet)

Je mehr CSS Joe Forshaw (@___joeforshaw) verwendet, desto mehr denkt er, in einem absurden wilden Westen zu sein. Irgendwie ist CSS allgegenwärtig, hat jedoch keine grundlegenden, mit gesundem Menschenverstand nachvollziehbare und wirklich nutzbare Herangehensweisen, die bei anderen themenverwandten Tools selbstverständlich sind. Nachdem Joe mit mehreren modernen MVC-Web-Apps gearbeitet hat, die über gut strukturierte Backends, umfangreiche Testberichte und eine gute Dokumentation verfügen, empfindet er Stylesheets oft als riesigen dampfenden Haufen von Spaghetti-Müll.

„Ich bin wahrscheinlich unfair“, sagt er dazu. CSS wurde in einer Zeit geboren, als sich das Web erst noch entwickelte, Ideen und populäre Dinge entworfen worden, um zu bestehen. So schwierig CSS auch ist, jede Website der Welt braucht sie und könnte ohne sie nicht überleben.

Anzeige

Hier sind einige von Joes Gedanken darüber, was schlecht ist und wie man vernünftiges CSS schreibt. Betrachte diesen Beitrag gerne als Orientierung oder Tippgeber bei deiner Arbeit mit CSS.

1. Globaler Umfang

Das erste und größtes Problem mit CSS ist, dass jede Style-Deklaration jeden Aspekt eines Elements auf einer Seite ändern kann. Das ist großartig, wenn du gerade angefangen hast, deine Fühler ins Netz auszustrecken, aber für größere Seiten ist es meistens sehr gefährlich. Fast alle Frontend-Entwickler werden an einem Punkt irgendwelche Styles hinzufügen, modifizieren oder entfernen, nur um zu Vermeiden, versehentlich in einen anderen Abschnitt einer anderen Seite einen Lack zu verursachen.

Das ist das wichtigste Thema bei CSS, dass es zu bedenken gilt. Es macht jedes Konzept der Modularität sehr schwierig. Morgen könnte ein Entwickler einfach ein paar !important-Tags in den Code einbauen und dein gut gekapseltes, wiederverwendbares Widget verschrotten.

.blog-post {
  .title {
    font-size: 2rem;
  }
}

# Grrrr, Styles sind überall undicht
h1 {
  font-size: 5rem !important;
}

SASS/SCSS hilft uns hier, aber auch nicht vollständig. Wenn du als Entwickler ein tieferes Verständnis hast, können undichte Stile durch Verschachteln von Regeln in einer Elternklasse erheblich reduziert werden.

.blog-post {
  .title {
    font-size: 2rem;
  }
}

# Noch besser
.home {
  h1 {
    font-size: 5rem;
  }
}

Das ist besser, aber es ist keine narrensichere Lösung. Es braucht nur ein unvorsichtiges Styling, um dich zurück ins Choas zu stürzen. Eine enge Frist, die dich zwingt, einige fragwürdige Kompromisse (z.B. Hacks) einzugehen.

Wenn du einem Back-End-Entwickler gesagt hast, dass er eine Programmiersprache verwenden muss, die allen Variablen globalen Geltungsbereich verleiht und den internen Status jedes Objekts sichtbar macht, lässt du jeden anderen Entwickler seinen Code außer Kraft setzen. Aber das ist die irrsinnige Realität der CSS-Entwicklung.

Der beste Workaround

Der beste Weg um den globalen Geltungsbereich zu finden ist, indem du das CSS-Benennungssystem BEM einführst, das von den Entwicklern erwartet wird, ihren Code konsequent modular zu schreiben. Es meidet gefährlich undichte Gewohnheiten wie mit Hilfe von Tags Styling (zB h1, p usw.) und stattdessen lieber Styling auf Klassennamen. Klassennamen, die absichtlich mit dem Namen des Moduls (oder Block in der BEM-Terminologie) benannt sind, in dem sie leben, um zufällige Kollisionen mit ähnlichen Klassennamen zu vermeiden.

Oft gibt es ein Argument, um Tags zu verwenden, um einen Standardsatz von Stilen zu erstellen. Für die meisten Websites ist es normalerweise eine gute Idee. Wenn du diese Stile jedoch fast überall außer Kraft setzt, könnte man sagen, dir die Mühe sparen zu können. Setze sie in allgemeine Hilfsklassen (z.B. .paragraph, .heading-1 usw.) und verwende sie nach Bedarf.

BEM ist keineswegs perfekt. Es kann beschwerlich sein, große, lange, „namespaced“ Klassen konsequent zu schreiben. Du schreibst immer noch CSS. Du kannst dabei immer noch zwielichtige Stylings schreiben, die alles vermasseln. Du brauchst immer noch Disziplin. Aber es gibt eine Struktur und eine Reihe von Regeln, die dir helfen, bessere und wartungsfreundlichere Stile zu schreiben.

2. Spezifität

Spezifität ist der Mechanismus, den CSS verwendet, um zu entscheiden, welches Styling wichtiger ist als andere. Meiner Erfahrung nach endet es fast immer in einem Wettlauf nach unten (oder oben in diesem Zusammenhang). Ein Streuen von !important-Tags, Stilen auf beliebigen IDs und unnötigen divWrappern, deren Hauptzweck es ist, die Spezifität etwas höher zu schieben als mühselige existierende Stile. Wahre Geschichten. Ich sehe das gerade auf der Arbeit beim Optimieren von CSS-Code einer alten Seite. Kaum zu glauben, was sich so mancher ausdenkt.

Wenn du ein neues UI-Element erstellst, aber ein anderer sehr spezifisches Styling deines Kollegen dir im Weg steht, würdest du:

  • Zeit investieren, um das UI-Widget deines Kollegen zu verstehen, die Auswirkung ermitteln und einer Änderung des Stils auf andere Teile der Website berücksichtigen, und es entsprechend korrigieren.
  • Oder fange es mit einem !important ab.

Abhängig von der Art der Umgebung, in der du arbeitest, und der Größe deiner Codebasis kann deine Antwort natürlich unterschiedlich ausfallen.

Objektorientierte Sprachen umgehen dieses Problem durch Vererbung und Unterklassenbildung. Die am wenigsten „wichtigen“ und unspezifischen Methoden stehen am Anfang des Vererbungsbaums, am spezifischsten unten. Meiner Meinung nach ist die Anwendung dieser OO-Prinzipien im Bereich der UI-Arbeit viel besser als die Spezifität von CSS. Jeder, der sich beispielsweise mit iOS UIKit auskennt, ist damit vertraut, generische UIView-Widgets neben spezifischeren Unterklassen zu setzen, die bestimmte Attribute außer Kraft setzen. Auf der anderen Seite musst du normalerweise etwas mehr Code schreiben und ein wenig mehr über diese Art von Override-Verhalten nachdenken.

Der beste Workaround

Nimm nicht am Rennen nach unten teil. Stelle im Allgemeinen sicher, dass deine Stylings nicht zu spezifisch sind.

  • Versuche nicht !important zu verwenden (manchmal bist durch Drittanbieter-Embeds leider dazu gewungen).
  • Style keine IDs (zu spezifisch).
  • Verwende Klassennamen (unspezifisch).
  • Vermeide die Einbeziehung von Nachkommen in Stilselektoren, da diese die Spezifität erhöhen. Mit SASS/SCSS werden verschachtelte Stile zu untergeordneten Selektoren kompiliert, also nicht verschachteln.

Wenn du BEM verwendest, befolgst du diese Regeln bereits. ?

3. Implizite Prozentregeln

Jeder, der bereits Prozentsätze in Padding-Regeln verwendet hat, wird sich bewusst sein, wie verwirrend die Dinge werden können.

.sidebar {
  padding: 10%;
}

Wenn du neu in CSS bist, kann das obige Styling dich zum Nachdenken bringen. Es ist nicht klar, wie die 10% handeln werden. 10% von was? Es könnte von …

  • Breite des Ansichtsfensters (Viewport)
  • Höhe des Viewports
  • Breite der .sidebar
  • Höhe der .sidebar
  • Übergeordnete Breite der .sidebar
  • Elternhöhe der .sidebar

Auf den ersten Blick also völlig unklar. In Wirklichkeit berechnet es den Prozentsatz anhand der Breite des Elternelements. Dies führt zu einigen nicht intuitiven Ergebnissen, z. B. ändert sich das vertikale Padding, wenn sich die Breite des Browsers statt der Höhe ändert (diese Seltsamkeit wird häufig verwendet, um responsive Seitenverhältnisse zu hacken). Wenn du möchtest, dass deine vertikale Auffüllung auf die Höhe deines Containers reagiert, kannst du dies nicht tun.

In einer idealen Welt solltest du, wenn du einen Prozentsatz verwendest, explizit angeben, welchen ​​Wert er entsprechen soll. Ich denke, das ist vernünftig zu erwarten.

Bester Workaround

Es gibt leider nicht viel, was du tun kannst, um dies zu umgehen.

Wenn du die Größe relativ zur Breite und zur Höhe des Darstellungsbereichs anpassen möchtest, empfehle ich die Verwendung der Einheiten vw und vh. Die Unterstützung ist ziemlich gut und du musst dabei nicht mit Prozenten herumspielen. Achte jedoch auf Besonderheiten auf Mobilgeräten, da sich die Breite und Höhe des Darstellungsbereichs abhängig davon ändern können, ob der Chrome-Browser angezeigt wird.

Um implizite Prozent-Probleme anzugehen, glaubt Joe, dass das Konzept von vw– und vh-Einheiten eine gute Lösung darstellt. Er wünscht sich nur, es hätte uns heute schon etwas weitergebracht.

4. Z-Index

Wenn z-Index Kopfschmerzen verursacht, ist eine gebräuchliche Lösung, die Nukleare: z-index: 999999. Sobald dies geschieht, entsteht Chaos. Alles, was in Zukunft darüber erscheinen muss, wird wahrscheinlich eine zusätzliche „9“ enthalten.

Alles, was auf mangelndem Kontext entsteht, wird scheitern.

Da z-index-Regeln in allen Stylesheets einzeln angegeben werden, sind die Beziehungen zwischen ihnen nicht eindeutig.

Workaround

Wenn wir diszipliniert sind, kann SASS/SCSS uns hier heraus helfen. Wenn wir alle unsere z-indexes als Variablen definieren, erhalten wir den Kontext, den wir brauchen.

$z-index-page: 100;
$z-index-navigation: 200;
$z-index-newsletter-modal: 300;

Wir können deutlich sehen, dass unser Newsletter-Modal über unsere Navigation steht, die wiederum über unseren Seiteninhalt hervorsteht.

Ich tendiere auch dazu, in Hunderten-Schritten zu arbeiten, damit wir andere Z-Indexes dazwischen einfügen können, wenn wir es brauchen. Dies ist nicht so wichtig, wenn jeder Z-Index wie oben abgelegt wird, da du einfach alle Werte nur an einer Stelle aktualisieren kannst.

5. Du musst es verwenden

Wie JavaScript ist CSS die De-facto-Sprache des Browsers. Es ist die einzige Möglichkeit, Webseiten zu gestalten, die also akzeptiert zu werden. Hoffentlich werden manche Browser irgendwann sprachunabhängig.

Auf der anderen Seite wird CSS (ziemlich) konsistent über mehrere verschiedene Plattformen verwendet und ist nicht der ummauerte Garten, den iOS, Android und der Rest des Tech-Ökosystems geworden sind.

Die beste Problemumgehung

Beende die Frontend-Webentwicklung. Wenn das keine Option ist, musst du weiterhin CSS verwenden. ;-)

Quelle

joeforshaw.com

Frischer Input für Designer. Jeder Abonnent erhält das kostenlose Bundle aus 50 Photoshop Device-Mockups und 40 Responsive WordPress-Themes.

1x pro Woche. Kein Spam. Jederzeit kündbar.
Jonathan Torke
Jonathan Torke

Auf pixeltuner.de teile ich aktuelle Ressourcen für Webdesigner und -entwickler. Du findest mich auch auf deviantART und Instagram.
PayPal-Kaffeespende.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.