Ahmad Shadeed trifft es wieder mit „Defensives CSS.“ Die Idee ist, dass Sie CSS so schreiben sollten, dass es auf Probleme vorbereitet ist, die durch dynamische Inhalte verursacht werden.
Mehr Elemente als erwartet? Kein Problem, der Bereich kann sich erweitern oder scrollen. Titel zu lang? Kein Problem, er bricht entweder um oder wird gekürzt und stößt nirgendwo seltsam an, da Ränder oder Lücken richtig gesetzt sind. Bild kommt in unerwarteter Größe an? Keine Sorge, das Layout ist so konzipiert, dass der dafür vorgesehene Bereich mit dem Bild gefüllt wird und die Größenanpassung/Zuschneidung entsprechend handhabt.
Es gibt nichts wie ein guter CSS-Entwickler, der nicht defensiv codiert. Das ist, was einen CSS-Entwickler ausmacht, besonders wenn man Konzepte der progressiven Verbesserung und Unbekannte von Browsern/Geräten berücksichtigt.
Ein guter Designer hätte bereits alle möglichen Szenarien mit visuellen Referenzen für die Entwicklung bereitgestellt. Natürlich, wenn ein Designer nicht verfügbar ist, würde es wahrscheinlich auf den Entwickler fallen, aber idealerweise sind dies Entscheidungen, die der Entwickler nicht blind treffen sollte.
Ich stimme teilweise zu. Es ist großartig, einen Designer zu haben, der sich all dieser Möglichkeiten bewusst ist und sie in Mockups gestaltet. Aber es gibt viele Randfälle und ich würde sagen, es ist nicht die Aufgabe eines Frontend-Entwicklers, nur ein Roboter zu sein, der Mockups identisch interpretiert und nicht selbst über diese Situationen nachdenkt. Ich würde fast lieber, dass der Designer nicht zu viel Zeit mit der Gestaltung jeder möglichen defensiven Zustands verschwendet, überlassen Sie das mir, und dann werden wir überprüfen und diskutieren, sobald es ein interaktiver Prototyp ist.
In diesem Kommentar steckt viel „sollte“. Ich wäre begeistert, einen Designer zu treffen, der jede Möglichkeit von Inhaltsbedingungen in seinen Designs berücksichtigt – in Wirklichkeit bekomme ich Lorem Ipsum und unoptimierte Assets in einer schlecht organisierten Sketch-Datei.
Ich denke, es ist mehr als lohnenswert, dass ein Entwickler zumindest über ein Toolkit von Techniken verfügt, um unerwartete dynamische Inhalte zu handhaben, auch wenn die Designer alles richtig machen und den mit 43 Wörtern, 300 Zeichen versehenen Überschriften Rechnung tragen.
Realistisch betrachtet können wir, egal wie gut Designer Bedürfnisse antizipieren und Entwickler defensiv implementieren, schlechte Nutzung nicht verhindern.
So wie ein Teil der Barrierefreiheit die Arbeit mit einfacher Sprache ist, die in der Inhaltsphase erfolgt, geschieht ein guter Teil des Website-„Designs“ nach dem Aufbau der Infrastruktur. Content-Ersteller und Content-Designer müssen gute Entscheidungen treffen.
Es ist schwierig bis unmöglich, für die Bildgröße zu codieren UND zu erraten, wo in einem Bild der Fokus des Inhalts liegen wird. Es ist die Aufgabe der Content-Leute, zu wissen, wo der Hauptwert eines Bildes liegt, und geeignete Bilder zu verwenden oder Bilder mit intelligenten Rändern/Füllungen anzupassen.
Das Aussehen einer Website liegt genauso sehr bei denen, die entscheiden, was auf die Website kommt, wie bei denen, die ihre Strukturen entworfen und gebaut haben.