Nils Werner 25. Mär 2008
Der zweite Artikel der Sourceforge-Schrott-Serie widmet sich einem relativ neuen Dienst von Sourceforge: den Wikis.
Es ist offensichtlich, dass die Wikis nicht von denselben Entwicklern geschrieben wurde, die auch den Rest von Sourceforge entwickelt haben. Stattdessen wurde auf das Angebot von Wikispaces zurückgegriffen. Das ist an sich ja nichts schlimmes... wenn man es richtig gemacht hätte.
Neue URL-Struktur
Zu allererst ist mir die seltsame neue URL-Struktur für Wikis aufgefallen: Normalerweise werden Projekte über www.sourceforge.net/projects/projektname adressiert. Bei den Wikis hingegen verwendet man projektname.wiki.sourceforge.net. Kein großer Fehler, er zeigt jedoch, dass sich niemand wirklich Gedanken gemacht hat, wie man die URL-Struktur vereinheitlichen könnte.
Abgesehen von den Wikis aber im Zusammenhang mit URL-Struktur: Warum existiert www.sourceforge.net/projects/ nicht? Auch ein Zeichen für "nicht viel Gedanken an die Strukturierung verschwendet".
Richtext-Editor
Dann wird dem Benutzer beim Bearbeiten per Default der "Visual Editor", einem WYSIWYG-Editor, angeboten. Das ist meiner Meinung nach keine gute Idee, da der Großteil derjeniger, die mit Sourceforge arbeiten, die Sauberkeit von Wiki-Markup gegenüber der Verwendung von Richtext-Editoren bevorzugen. (Und wenn nicht der Großteil aller Nutzer, dann der Großteil der "Poweruser").
Erst nach den Bearbeiten der Profil-Einstellungen erscheint standardmäßig das einfache Textfeld, wie man es von Wikipedia gewohnt ist. Und auch dann ist die Schriftgröße des Textfeldes schon fast unzumutbar winzig.
Fehlerhaftes Stylesheet
Zugegeben, die bisherigen Fehler bzw. Fehlentscheidungen stellen noch keine großen Probleme dar. Der größte Fehler bei der Integration der Wikis befindet sich jedoch in den unscheinbaren Zeilen 1219ff von static.sourceforge.net/css/sfx.php:
#frame li, #fadbtm li {
font-size: 82.3%;
}
Die Verwendung von prozentualen Schriftgrößen in Verbindung mit <li> sollte bei jedem erfahrenen CSS-Entwickler sätmliche Alarmglocken klingeln lassen.
Denn: Untergeordnete Listen übernehmen sämtliche Eigenschaften der Elternelemente und vereinen diese mit ihren eigenen Anweisungen. Diese Eigenschaft zusammen mit einer relativen Schriftgröße erzeugt also immer kleiner werdende Schriftzeichen.
In diesem Fall sind das 82.3% für die erste Ebene, 67.7% für die zweite Ebene, 55.7% für die dritte Ebene usw. Der Text in, bei Wikis sehr beliebten, Listen wird also bei tiefer werdender Verschachtelung immer kleiner. Mehr als drei Ebenen sind fast schon nicht mehr möglich, da der Text einfach unleserlich wird. Siehe dazu folgendes Beispiel.
Resumee: Schrott
Zugegeben, abgesehen von dem Stylesheet-Patzer sind alle Fehler nur Kleinigkeiten, die sich umschiffen lassen. Dieser eine Fehler jedoch macht das gemeinsame Pflegen von größeren, verschachtelten Listen tatsächlich unmöglich.
Dabei wäre das Reparieren so einfach:
#frame li li, #fadbtm li li {
font-size: 100%;
}
Und warum das, trotz so vieler Beschwerden, noch nicht geändert wurde, erkläre ich in einem der noch folgenden Artikel. :-)
Quellen
