Mittwoch02. März 2011

Die ersten Hinweise auf den Entwicklungszweig für YAML 4.0 habe ich ja bereits im Oktober letzten Jahres gegeben. In dem damaligen Beitrag habe ich allerdings noch nicht wirklich Informationen zur Version 4 gegeben sondern eher über die Dinge berichtet, die aus dem 4.0er Zweig in die Version 3.3 vorgezogen wurden. Heute hingegen werde ich ein bisschen aus dem Nähkästchen plaudern, wo die Reise bei YAML 4 hingehen wird. Und damit gehts auch gleich los ...

Namespaces

[Status: 85% fertig] Eines der häufigsten Quellen für Probleme bei der Frontendentwicklung in Verbindung mit Content Management Systemen, speziell bei größeren oder über Jahre gewachsenen Projekten, sind Kollisionen von ID- und Klassennamen. Beileibe nicht jedes CMS gestattet die vollständige Kontrolle über das ausgelieferte Markup. Wordpress weist beispielsweise dem <body> Element dynamisch eine Vielzahl von CSS-Klassennamen zu, was sich für Normalanwender auch kaum unterdrücken lässt. JavaScript Widgets wie Slider, Galerien etc. benötigen für den Zugriff auf ihr Markup sinnvolle IDs und Klassennamen – gleiches gilt für CSS Frameworks.

Für den Entwickler ist es gleichermaßen wichtig, möglichst selbsterklärende und konsistente Bezeichnungenzu verwenden, um die langfristige Wartbarkeit des Codes zu sicherzustellen. Eingänglich klingende, kurze Bezeichnungen wie “wrapper”, “post”, “page” usw. haben daher großes Konfliktpotential. Auf YAML bezogen kollidiert beispielsweise die von YAML verwendete CSS-Klasse .page mit der Verwendung, die Wordpress für die CSS-Klasse “page” vorsieht, die es dem <body> Element standardmäßig zuweist. Die Lösung hierfür heisst: Namespaces.

In YAML 4 werden daher die CSS-Klassen und IDs der Kernbestandteile des Frameworks mit einem Präfix versehen werden. Ein einheitlicher Namespace hat zudem den Vorteil, dass er (wir reden schließlich bei HTML/CSS von einfachen ASCII-Dateien) bei Bedarf leicht angepasst werden kann.

Den gesamten Beitrag lesen


Seite 1 von 1 Seiten