Hinweis: Am 9. April beteiligen wir uns auf webkrauts.de am Naked CSS Day. Die Stylesheets sind an diesem Tag absichtlich abgeschaltet.

Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Absurditäten des Web-Alltags

Kolumne

Absurditäten des Web-Alltags

Das Leben als Freelancer bietet einen Einblick in die Arbeitsweisen verschiedener Firmen und Agenturen. Der Freelancer lernt nicht nur, mit welchen Frameworks und Tools die Firmen arbeiten, sondern auch, dass Code-Standards in jedem Betrieb anders aussehen können.

Ich bin seit über zehn Jahren als Freelancer tätig. Das ist manchmal anstrengend, da man selten weiß, ob man in zwei Wochen einen Job hat, bedeutet auch viel Arbeit, da neben der eigentlichen Tätigkeit der Web-Entwicklung die Organisation des eigenen Mini-Betriebes hinzukommt mit Steuerkram, Angebotserstellung, Akquise-Aktivitäten usw.
Ein durchaus positiver Nebeneffekt ist jedoch, dass man sich als Freelancer nicht stets im eigenen Saft suhlt, sondern durch unterschiedliche Aufträge immer wieder neue Firmen und Agenturen und damit unterschiedliche Arbeitsweisen kennen lernt.

In der Regel werde ich für zwei Wochen bis hin zu drei Monaten gebucht, oft von heute auf morgen und das auch schon mal in Frankfurt, München, Bielefeld, nicht immer direkt vor der Haustür. Häufig werde ich dann gebucht, wenn ein Entwickler im Urlaub ist oder wenn ein Projekt mit eigenen Kräften der Agentur nicht mehr gestemmt werden kann. Vor allem komme ich fast immer in laufende Projekte hinein, sodass grundlegende Entscheidungen für die Frontend-Entwicklung bereits getroffen sind.

Jede Firma ist etwas anders organisiert, hat eigene Standards, spezielle Lösungsansätze und eine andere Art, Webseiten zu bauen. Derweil haben sich Grunt bzw. Gulp und LESS bzw. SASS als Best Practice durchgesetzt, was jedoch nicht bedeutet, dass überall gleich gearbeitet wird. In jeder Firma werden diese Technologien im Detail anders interpretiert. Aussagen wie »Wir arbeiten nach dem BEM-Konzept, haben das aber etwas für unsere Zwecke angepasst« sind keine Ausnahmen.

Das hat für mich den Effekt, dass ich im Grunde jede Buchung als eine Art Fortbildung, manchmal auch als Inspiration zum Nachdenken erlebe. Aus jedem Projekt gehe ich mit mehr Knowhow heraus und werde sogar dafür bezahlt. Das heißt nicht, dass mein Wissen gigantisch groß ist. Es ist eher so, dass ich in jedem Projekt kämpfe, den Anforderungen der einzelnen Agentur gerecht zu werden, dafür aber einen guten Eindruck davon habe, was »draußen« in der Web-Welt abgeht, wie sich die Frontend-Entwicklung verändert und wie modernes Webdesign in der Praxis gelebt wird – und wie gut Gemeintes oft einfach nur gutgemeint bleibt ;-).

Ich warte auf den ersten, der sich tot-strukturiert

Recht häufig sehe ich, wie viel Mühe in die Strukturierung eines Projektes gesteckt wird. Struktur ist wichtig, ohne Frage. Aber mehr ist nicht immer mehr. Da werden SASS-Dateien für einzelne HTML-Elemente, Module und Objekte angelegt, was zu Beginn eines Projektes sinnvoll erscheint.

Mit fortlaufendem Projekt ist es jedoch keine Seltenheit, dass ein Projekt 100 SASS-Dateien und mehr umfasst. Schon bei 20 einzelnen Dateien ist es kaum möglich, intuitiv zu erkennen, was sich in welcher Datei verbergen könnte. Für diejenigen, die eine solche Struktur über Monate entwickelt haben, mag das alles völlig klar sein. Kommt man als Freelancer erst spät in ein Projekt, ist man schon mal »Lost in Space«.

Abgesehen davon habe ich es nicht nur einmal erlebt, dass ein Grunt-Task aufgrund wachsender Anzahl von Sass-Dateien (und natürlich auch wachsender Anzahl anderer Dateien) 30, 60 oder mehr Sekunden dauerte, und dies aufgrund des Gesamtsettings und des Fortschritts im Projekt nicht auf die Schnelle umzustellen war. So bin ich schon mehrmals an die Grenzen meiner Geduld gestoßen.

»Wir trennen nach Struktur und Farben«

Wie gesagt, ich halte Struktur für wichtig, es ist nur die Frage, wie weit man es treibt. Bei einem Auftraggeber wurden grundsätzlich einzelne Dateien für die Struktur, also die Flächenaufteilungen und andere Dateien für Farben angelegt. Das war insofern durchdacht, da in dem Haus diverse Webseiten mit demselben Grundlayout aufgesetzt waren, lediglich die Farben den einzelnen Auftritt ausmachten. Was jedoch dazu führte, dass zusammengehörige border-Eigenschaften auseinander gerissen wurden. In der einen Datei standen also border-style und border-width, die Farbe der border war jedoch in einer anderen Datei zu finden. Kann man machen. Macht es aber nicht einfacher.

Meine Lieblings-SASS-Variablen: $white und $black

Ich weiß nicht, wie es euch dabei geht. In jedem zweiten Projekt sind diese beiden Variablen zu finden. Und ich sitze davor und frage mich: Welchen Mehrwert hat das? Ich frage mich, in welchem Projekt man sich überlegt: »Heute ändern wir den Wert von $white in #ff0000.« Kann man machen? Ja! Macht man es? Nein! Ich würde auch behaupten, dass Variablen wie $lightgray, $middlegray, $darkgray oder $middledarkgray weder zu einer besseren Pflegbarkeit noch zu einer effektiveren Arbeit führen. Warum machen wir das? Weil es geht. Ist es sinnvoll? Ich sage: Nein!

Bereits im Vorfeld habe ich zu der Thematik der SASS-Variablen Feedback erhalten, dass man es schon erlebt hat, dass der Weißwert von #ffffff auf #f2f2f2 geändert wurde. Inhaltlich ist es ja sinnvoll, aus einem klaren Weiß ein etwas gedämpfteres Weiß zu machen, damit Texte auf dem Bildschirm nicht ganz so knallen. Aber – jetzt kommt der Moment, wo ich als Freelancer später zu einem Projekt hinzustoße: Ich setze diese Sass-Variablen ein und werde mich wahrscheinlich wundern, warum mein eingesetztes $white nicht wirklich weiß ist?!? Bessere Varianten wären sicher $text-white-color oder $background-black. Variablen wie $white bzw. $black sind aus meiner Sicht keine geeigneten Bezeichnungen für Variablen, da sie im Grunde keine Variablität zulassen.

CSS bietet ja generell die Möglichkeit, mit einem Schlag das Aussehen und die Farbgebung eines kompletten Web-Angebotes zu verändern. Ja, das geht. Macht man es? Nein. In über zehn Jahren habe ich noch kein Projekt erlebt, bei dem bei einer Überarbeitung lediglich das CSS ausgetauscht wurde. Selbst wenn es kein Relaunch war, sondern nur ein Re-Make oder gar nur ein Re-Brush (was scheinbar eher eine Formulierung für das Angebot war, da das doch wesentlich billiger klingt), gab es bei solchen Projekten auch immer Anteile am HMTL, die verändert wurden, was dann auch eine Ergänzung des CSS notwendig machte.

Kommentieren ist wichtig!

Ja, dem stimme ich auch zu. Dann schaue ich in einen Quelltext und finde Folgendes:

  1. <!-- Anfang Formular -->
  2. <form method="post" action="kontakt.php">
  3.   …
  4. </form>
  5. <!-- Ende Formular -->

Huaaah… Solltet ihr das lesen und solltet ihr in dieser Weise kommentieren: Bitte lasst es! Wenn eure Kommentare lediglich das wiederholen, was offensichtlich im HTML zu lesen ist, hilft das weder euch noch anderen Entwicklern, um den Quelltext besser zu verstehen. Das bläht nur das HTML auf und ist letztendlich nur Makulatur.

Wenn zusammengehöriges HTML auf unterschiedliche Dateien verteilt ist, dann ist es für folgende Entwickler hilfreich, wenn der Anfang und das Ende eines div-Blocks durch Kommentare gekennzeichnet ist. Sinnvoll ist es, wenn ein Kommentar auf etwas hinweist, was eben nicht intuitiv aus dem Quelltext hervorgeht.

Das gilt nicht nur für HTML, sondern für alle Quelltexte. Ob eine PHP-Funktion mit dem Funktionsnamen getZipCodeOfUser() wirklich mit den Worten »liefert die Postleitzahl des Nutzers« kommentiert sein muss, stelle ich persönlich in Frage.

Hurra, wir haben die divititis besiegt!

Tabellen-Layouts waren vorgestern, div-Layouts waren gestern, das ist zum Glück vorbei! Wir haben jetzt HTML5 und können unsere Quelltext endlich mit einer modernen, fortgeschrittenen Technologie und einer sinnvollen Semantik bereichern. Sehr gut, das gefällt mir! Ich stehe in der nächsten Agentur uns stoße auf dieses HTML:

  1. <section class="text-bild-wrap">
  2.   <section class="text-content">
  3.     …
  4.   </section>
  5.   <section class="bild-wrap">
  6.     …
  7.   </section>
  8. </section>

Aua. Zugegeben. Für neue HTML5-Struktur-Elemente wie section oder article hat sich noch kein Standardeinsatz durchgesetzt. Der gezielte Einsatz ist schwer und wird in der Regel nach dem persönlichen Empfinden eingesetzt. So lässt sich darüber streiten, ob man für den Haupt-Seiten-Wrapper ein section einsetzt, oder das section-Tag lediglich als Strukturelement für den Hauptinhalt der Seite einsetzt.

Ich wage aber zu behaupten: Spätestens wenn du drei section-Elemente ineinander verschachtelt hast, stimmt hier was nicht. Das entspricht nicht dem, was sich das W3C dabei gedacht hat. Also: Wenn du ein zusätzliches Element benötigst, um eine spezielle Layout-Anforderung umzusetzen, dann nimm ein div. Genau dafür ist es gedacht und ist gar nicht so schlimm, wie allgemein sein Ruf. Das ist auf jeden Fall besser, als ein semantisch relevantes HTML-Tag zweckzuentfremden. Wahrscheinlich hat sich das Wort sectionitis noch nicht durchgesetzt, weil es nicht so leicht von der Zunge geht wie divititis.

Und, und, und…

Ich weiß, manche von euch werden jetzt die Augen verdrehen. Ich vermute aber auch, dass vielen von euch ein »ja, genau« von den Lippen geht. Und dass ihr solche oder ähnliche Erfahrungen in der täglichen Arbeit schon gemacht habt. Ich würde mich freuen, wenn ihr eure Anekdoten hier teilt. Ich bin mir sicher, am Ende wird hier ein schönes Sammelsurium zu lesen sein, bei dem sich viele wiederfinden und sich auch der ein oder andere ertappt fühlt.

Und bitte: Schiebt den bitteren Ernst etwas zu Seite. Viele Dinge, die ich selber in meinen langen Jahren als Entwickler gemacht habe, waren nicht immer sinnerfüllt, und manche würde ich selber ebenso belächeln.Nichts ist persönlich gemeint und wenn man alles mit einem Augenzwinkern betrachtet, ist auch alles halb so schwer ;-).

Kommentare

Jens Martsch
am 11.12.2015 - 11:35

Ich musste doch sehr schmunzeln bei $white und $black. Einer Tatsache, die mich schon bei Bootstrap gestört hat und leider auch seinen Weg in das neue Foundation 6 for sites gefunden hat, worauf hin ich ein Issue auf github https://github.com/zurb/foundation-sites/issues/7383 einstellte, diese Variablen doch zu entfernen oder umzubenennen, da weiß und schwarz absolute, fest definierte Werte sind und eben nicht variabel.

Die Antwort der Entwickler war, dass Sie anderen Entwicklern die Möglichkeit geben möchten, was weiß oder schwarz für sie bedeutet. Es sind keine semantischen Namen, aber der Schlüssel ist, dass es Konstanten sind.
We're giving developers the flexibility to modify what "black" and "white" mean in their design. They might not be semantic names like $primary-color, but the key is that they're constants.

Somit wurde das Ticket leider unbearbeitet geschlossen und diese Variablen werden weiter existieren.

Permanenter Link

Gunnar Bittersmann
am 11.12.2015 - 16:39

Da fällt mir ein Projekt von mir ein, wo es um Flaggen geht. Für die italienische hab ich tatsächlich
$white: rgb(241, 242, 241); gesetzt.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 17.12.2015 - 11:38

@Gunnar: Ja, verstehe ich - ich würde in dem Fall eine Variable $icon-white wählen. Was nimmst Du, wenn Du wirklich weiß benötigtst ;-)
Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 17.12.2015 - 11:36

;-) Danke fürs Untermauern!
Permanenter Link

Frank
am 11.12.2015 - 13:10

Ja, genau! ;)

Schöner Beitrag, an manchen Stellen musste ich auch schmunzeln ($white). Und dem ich zustimmen kann. Ich will es nicht gleich als Problem bezeichnen, aber Strukturierung, Modularisierung, Standardisierung usw. - das und der Aufwand dafür steht nicht selten im Widerspruch zur Realitität und zum Projekt. Ich habe auch noch nie erlebt, dass eine Webseite mal nur einen neuen Farbanstrich bekommen hat. Mit Entwicklertools wie Firebug finde ich die passende Datei schneller als mit der Deutung von Ordner- und Dateinamen. Auch ist meine Erfahrung, dass Webseiten, wenn einmal fertiggestellt, nicht allzu oft weiterentwickelt und erweitert werden.

Ist natürlich alles abhängig von Projektumfang und Teamgröße, aber ich schließe mich dir da an: Struktur ist wichtig, "es ist nur die Frage, wie weit man es treibt."

Permanenter Link

Tilman
am 11.12.2015 - 14:05

Für $black und $white habe ich in so fern Verständnis, als dass es der Konsistenz dienlich ist alle Farben in Variablen zu packen. Für veränderliche helle und dunkle Farbwerte bevorzuge ich aber die semantischen Namen $dark und $light ;) Die können dann Schwarz und Weiss entsprechen, müssen aber nicht. Schwarz und Weiss sind dann aber für Farbmischungen verfügbar. Wobei mir das zugegebenermaßen in Projekten noch nie begegnet ist.

Bei auf den ersten Blick überbordenden Struktur hast du einen wichtigen Punkt angesprochen. Wenn die für neu in das Projekt eingestiegene Mitarbeiter erst einmal unübersichtlich wirkt und wenig eingängig ist, dann kann das "Überstrukturierung" sein, kann aber auch etwas über die Komplexität des Projekts aussagen. Aus der Innenansicht der Agentur kommt dann tatsächlich auch der von dir berührte Aspekt ins Spiel, dass die vorhandenen Strukturen eine Projekt übergreifende Verbindlichkeit haben. Da mag die Einarbeitung neuer Teammitglieder in die vorhandene Struktur etwas aufwändiger sein, dafür muss sie nur einmal im Gesamten stattfinden, die Einarbeitung in weitere Projekte verkürzt sich auf ein Minimum, da nur noch die spezifischen Unterschiede der Projekte "gelernt" werden müssen.
Gerade im Agenturgeschäft mit einer eher hohen Anzahl an Projekten in der Umsetzung und Produktivbetrieb ist das ein nicht zu unterschätzender Faktor, wenn man sich für kleinere Anpassungen oder Bugfixes nicht komplett einarbeiten muss. Das hat meiner Erfahrung nach auch einen großen Einfluss auf die Konsistenz des Gesamtprojekts, wenn dieses nach Launch erweitert und um Features ergänzt werden soll. Eine gelernte und verstandene Struktur zu erweitern mündet weniger wahrscheinlich in einem großen Kuddelmuddel.

Ansonsten zeigen deine Ausführungen ja die klassischen Schwierigkeiten, für die man sich als Freelancer entschieden hat ;) Nach der einen oder anderen sehen ich mich auch zurück, besonders die vielfältigen Einblicke in Arbeitsweisen und was man dabei lernen kann vermisse ich besonders.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 17.12.2015 - 11:50

Hallo Tilmann,

Du beschreibst das Dilemma, in dem man als Freelancer steckt, ziemlich gut: Als Agentur würde ich das genauso machen, dass ich Workflows optimiere, damit Folgeprojekte effektiver umgesetzt werden können. Dem ist nichts entgegenzusetzen.

Wenn Du als Freelancer dann dazu stößt, kann man in einem Projekt niemals alles erfassen, was über lange Zeit gewachsen ist, und je nach Agentur, welche individuellen Sonderregeln (auch wenn jede einzelne historisch verständlich ist) es so gibt.

Frontend ist eben in den letzten Jahren immer komplexer und anspruchsvoller geworden, wo man früher »schnell mal« eingreifen konnte, ist das heute nur schwer möglich, vor allem, wenn man sich in der gegebenen Struktur einfügen möchte.

Das ist das, was ich derweil erlebe, dass die Unzufriedenheit bei Agenturen größer wird. Einerseits sind die Prozesse optimiert, andererseits soll der Freelancer alles können, und zwar so schnell wie möglich, da der ja auch vermeintlich teuer ist. Ich erlebe es immer häufiger, dass dann eben Erwartungshaltung zu hoch ist, was man nach 2 Stunden »sich einlesen« leisten kann, was Festangestellte eben über Monate/Jahre verinnerlicht haben. Nun, ich vermute, dass ist ein Dilemma, mit dem jeder Freelancer leben muss....

Permanenter Link

Gunnar Bittersmann
am 11.12.2015 - 16:16

Für neue HTML5-Struktur-Elemente wie section oder article hat sich noch kein Standardeinsatz durchgesetzt. Der gezielte Einsatz ist schwer und wird in der Regel nach dem persönlichen Empfinden eingesetzt.

Ich geb mal mein Empfinden wieder: section ist ein relativ eigenständiger Abschnitt des Inhalts des übergeordneten Blocks (welcher bspw. auch die gesamten Webseite sein kann). Aber nicht zu eigenständig, sonst wär’s ja article.

Jede section hat eine ID. Weil es ein relativ eigenständiger Abschnitt ist, möchten Nutzer womöglich speziell auf diesen Abschnitt verlinken – mit fragment identifier: example.net/seite#abschnitt. Andersrum kann man wohl auch getrost sagen: Wenn der Bereich kein prädestiniertes Linkziel ist, dann ist das section-Element dafür vermutlich falsch.

Jede section hat i.d.R. eine Überschrift. Sagt auch die Spec. Das sollte auch Screenreader-Nutzern helfen, durch die Seite zu navigieren. In manchen Fällen will man vielleicht keine visuelle Repräsentation der Überschrift haben; dann sollte aber dennoch eine vorhanden sein und mit gängigen Visually-hidden-Techniken (bitte nicht -9999px!) versteckt werden.

Ich wage aber zu behaupten: Spätestens wenn du drei section-Elemente ineinander verschachtelt hast, stimmt hier was nicht. Das entspricht nicht dem, was sich das W3C dabei gedacht hat.

Warum nicht? Wenn der Inhalt wirklich so strukturiert ist, sollte das völlig OK sein:

  1. <main role="main">
  2.   <h1>Das Ganze</h1>
  3.   <section id="1">
  4.     <h2>Kapitel 1</h2>
  5.     ⋮
  6.     <section id="1.1">
  7.       <h3>Abschnitt 1.1</h3>
  8.       ⋮
  9.       <section id="1.1.1">
  10.         <h4>Unterabschnitt 1.1.1</h4>
  11.         ⋮
  12.       </section>
  13.       ⋮
  14.     </section>
  15.     ⋮
  16.   </section>
  17.   ⋮
  18. </main>

So lässt sich darüber streiten, ob man für den Haupt-Seiten-Wrapper ein section einsetzt

Haupt-Seiten-Wrapper gibt es doch bereits; sogar zwei davon: html und body. Das sollte genügen. Der Hauptinhalt der Seite sollte im main-Element gewrappt sein, nicht in section.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 17.12.2015 - 11:58

Hi Gunnar,

erstmal vielen Dank für den letzen Hinweis. Warum die meisten Webworker das body-Element nicht statt eines Wrappers nutzen, verwundert mich auch immer wieder.

Bei der Verschachtelung der section in Deinem Beispiel bin ich nicht ganz bei Dir. Sollte dort nur wenig Inhalt sein, erinnert der Aufbau an eine dd-Definitions-Liste.

Mir ging außerdem durch den Kopf: Würde man auch drei aside- oder header-Elemente ineinander verschachteln? Was ich sagen will: Ich glaube (bzw. so ist mein persönliches Empfinden) section ist ein eindimensioneles Element. Mehrere auf einer Seite, ja, mehrere ineinander verschachtelt: ich sage nein ;-)

Permanenter Link

Tim Kraut
am 07.04.2016 - 15:00

$white und $black als Variablennamen können schon Sinn ergeben.
Ich verwende in meinen privaten Projekten immer 2 Variablen für jede Farbe. Soll heißen: Eine Variable beschreibt, was $white bedeutet. Also z.B. $white: #fff;. Die Farben kommen alle in eine gemeinsame Datei. Damit habe ich an zentraler Stelle sämtliche Farbdefinitionen festgehalten. Die Namen der Variablen sind dabei explizit nicht funktional (also nicht sowas wie $accent sondern eher $red).

Die 2. Variable beschreibt den Anwendungsfall. Diese Variablen könnten z.B. $footer-background oder $dialog-warning-text heißen. Wichtig ist mir dabei immer, dass ich eine Art Scoping habe (in den beiden Beispielen wären das $footer- und $dialog-warning-). Die beiden Variablen verwende ich dann in den einzelnen CSS-Modulen. Die "Farb-Variablen" aber nie. Diese werden immer nur den "Anwendungsfall-Variablen" zugewiesen.

Mit diesem System kann ich innerhalb kürzester Zeit sämtliche Farbänderungen realisieren. Farbe einer Komponente ändern? Kein Problem - einfach eine andere Farb-Variable zuweisen. Das Grün etwas "grüner" machen? Kein Problem - einfach die Farb-Variable ändern.
Der Preis, den ich für diese Flexibilität bezahle, ist Komplexität. Ob es das wert ist, muss jeder für sich selbst entscheiden. Ich habe bisher gute Erfahrungen damit gemacht.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 08.04.2016 - 09:19

Wichtigstes Schlüsselwort in Deinem Kommentar ist das "private Projekte" - meine eigenen Projekte sehen auch weit aus chaotischer aus als wenn ich "draußen" arbeite. Wie aber auch Jens im Folgekommentar schreibt, es geht nicht alleine um den Farbnamen, sondern auch darum, dass man Projekte so aufbaut, dass idealerweise ein neuer Kollege auf das Projekt kommt und es eindeutig ist, welche Variable was bedeutet, und wenn $white nicht weiß ist, dann ist das nicht intuitiv.

Gut finde ich aber Deinen funktionalen Ansatz - vor allem lässt sich das dann auch gut auf weitere Projekte übertragen. Da kann der $footer schon mal einen hellgrauen, im nächsten Projekt einen dunkelblauen Hintergrund haben. So verstehe ich SASS bzw. LESS.

Permanenter Link

Tim Kraut
am 08.04.2016 - 12:50

Weiß ist in dem System schon weiß. Aber weiß muss ja nicht unbedingt #ffffff; bedeuten und wir nehmen es trotzdem als weiß wahr. Bei wenigen Prozent Abweichung von einem "reinen" Weiß dürfte das den wenigsten auffallen.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 08.04.2016 - 15:04

Hi Tim,
ich weiß ja, was Du meinst. Aber ein bisschen schwanger geht eben auch nicht ;-).
Die Frage bleibt: Ab wann ist dann weiß nicht mehr weiß? Und spätestens, wenn das weiß zu wenig weiß ist, kommt es genau zu dem Dilemma, dass es potentiell Verwirrung erzeugen kann...

Permanenter Link

Tim Kraut
am 08.04.2016 - 15:44

Jaa, da hast du Recht... Wenn weiß nicht mehr wie weiß wirkt, ist $white absolut der falsche Variablenname und sollte dann durch $blue-light, $gray-light oder irgendwas in der Richtung ersetzt werden.
Mir ging es vor allem darum ein System zu beschreiben, wo das wortwörtliche Beschreiben von eigentlich fest definierten Farben (red ist ja z.B. auch definiert) Sinn ergeben kann.

Permanenter Link

Jens Martsch
am 07.04.2016 - 18:12

@Tim Kraut: Ich wage es dir zu widersprechen. Der Vorteil von Variablen liegt klar auf der Hand. Allerdings sind white und black keine variablen Werte, wie ich schon in meinem ersten Kommentar geschrieben habe.
Variablen wie $light und $dark sind die bessere Wahl.

Stellt euch mal vor jeder Browser würde die "black" und "white" aus der Web-Farbpalette anders interpretieren. Das wäre ein Chaos. Jetzt kommt bestimmt wieder jemand und sagt, dass man diese Farben im CSS sowieso mit Hexwerten angeben sollte, oder als RGB.

Oder es kommt ein Entwickler mit ins Team und verwendet $black ohne zu wissen, dass das gar nicht schwarz ist, sondern irgendein Grauton und wundert sich dann, warum sein Element nicht schwarz ist.

Ergo: Variablen für Farben gut, aber nicht für Schwarz und Weiß!

Permanenter Link

Tim Kraut
am 08.04.2016 - 12:59

@Jens Martsch: $light und $dark wären für mich schon wieder funktionale Variablennamen.
Dass in einer technischen Implementierung keine Unterschiede für ein und dieselbe Definition (wie z.B. white) existieren sollten, ist logisch. Hier geht es aber eher um Systeme, die sich in erster Linie an Menschen richten. Natürlich sollte $black auch schwarz sein. Zwischen $black: #000; und $black: #0a0a0a; sehe ich z.B. praktisch keinen Unterschied (je nach Monitor vielleicht sichtbar im direkten Vergleich). Wenn der Designer jetzt unbedingt Schwarz als #0a0a0a; definieren möchte, kann er das tun. Ob man das unbedingt braucht, weiß ich nicht... Du hast aber Recht, dass das System bei richtigen Farben (wie z.B. Rot oder Grün) deutlich mehr Sinn ergibt.

Permanenter Link

Die Kommentare sind geschlossen.