Entries tagged as html

25 Jan 2009 plainList in s9y

Nachdem die notwendigen Anpassungen der Kern-Plugins in Serendipity so ziemlich abgeschlossen sind, geht es nun schrittweise an die sogenannten »additional plugins« – dabei handelt es sich, wie der Name bereits sagt, um zusätzliche Plugins, welche über Spartacus (bzw. das dazugehörige Plugin) nachinstallierbar sind.

Die Schwierigkeit in der Code-Aktualisierung jeglicher Plugins besteht in der Anforderung, die Ausgabe des Plugins möge mit dem veränderten Code idealerweise genau so aussehen wie vorher, damit möglichst wenige Templates aktualisiert werden müssen. Ein klassisches, leider sehr oft vorzufindendes Code-Beispiel in Plugins für s9y ist etwa so etwas:

<a href="...">...</a>
<br />
<a href="...">...</a>
<br />
[...]

Ich weiß nicht, wie man darauf kommt, so etwas zu verwenden – es ist doch ziemlich eindeutig, dass der semantisch korrekte Code für sowas eine ungeordnete Liste wäre:

<ul>
    <li><a href="...">...</a></li>
    <li><a href="...">...</a></li>
    [...]
</ul>

Nun gilt es jedoch, bei ungeordneten Listen (ul) die Bullets (•) und bei geordneten Listen (ol) die Numerierung zu vermeiden, um die »alte« Darstellung in s9y zu erhalten. Dafür haben wir auf Vorschlag von Garvin die neue CSS-Klasse plainList eingeführt. Diese erfordert folgenden Codeschnipsel in der style.css des verwendeten Templates:

.plainList {
    list-style: none;
    margin-left: 0;
    padding-left: 0;
}

Wichtig: Unbedingt die korrekte Groß-/Kleinschreibung beachten, plainlist und PlainList beispielsweise würden in CSS nicht erkannt!

Nun werden Listen, denen die Klasse plainList zugewiesen wurde (<ul class="plainList>, <ol class="plainList">), ohne Bullets oder Numerierung sowie ohne Einrückung und damit in (Seitenleisten-)Plugins genau so wie vorher dargestellt. (Wobei man natürlich diese Klasse auch z.B. in Blogeinträgen einsetzen kann.)

14 Jan 2009 WYSIWYG: Best practice

WYSIWYG-Editoren sind eigentlich ein Albtraum für Netzgestalter und Templateautoren. Natürlich sind solche Editoren für Benutzer – spezielle solche, die des (X)HTML nicht mächtig sind – eine feine Sache. Sieht aus wie Word, produziert aber einen Blogeintrag. Der Haken aus Gestaltersicht ist leider oft der (X)HTML-Code, der dabei herauskommt.

WYSIWYG-Editoren wie etwa Xinha, welcher seit Version 1.4 in Serendipity der Standard-WYSIWYG-Editor ist, erlauben dem Benutzer im Grunde alles, was man in so einen Eintrag einfügen können wollte – und damit beginnt das Dilemma auch schon. Kein Templateautor kann erahnen, was Benutzer möglicherweise in Einträge einfügen könnten, geschweige denn, wie, und das alles in einem Template abdecken. Und schon sind wir wieder bei Sokrates

Müssen nun also alle Blogger (X)HTML lernen? Nein. Mit ein paar einfachen Grundregeln und etwas Disziplin ist es durchaus möglich, mit Xinha (wie auch vergleichbaren Editoren) »vernünftig« Einträge zu erstellen. Ich gehe mal der Reihe nach die Buttons in Xinha durch, überspringe aber diejenigen, welche den generierten Code nicht beeinflussen:

  1. font und size: Finger weg! Die Schriftart und -größe regelt das Template. Abgesehen davon verwenden WYSIWYG-Editoren hier veraltete HTML-Elemente. Xinha setzt die Schriftgröße zudem in der ungünstigen Maßeinheit pt.
  2. Format: Superwichtig! Hier sollte man bevor man irgendetwas tippt stets die korrekte Auszeichnung (Überschrift, Absatz, Adresse, Formatiert) für ein Stück Text wählen. Das sorgt dafür, dass die entsprechenden Textbausteine in halbwegs korrektem (X)HTML ausgezeichnet werden.
  3. Physische Auszeichnungen wie fett, kursiv etc. bis hin zu tiefgestellt kann man gerne verwenden (mit Ausnahme von unterstrichen, was Links vorbehalten sein sollte). Hier benutzt Xinha im Übrigen sogar z.B.<strong> statt <b>. Sehr gut.
  4. Ausrichtung: Linksbündig & Co. – auch das sollte dem Template überlassen werden. Speziell Blocksatz kann zudem durchaus Darstellungsprobleme im Browser auslösen. Lieber nicht verwenden.
  5. Listen sind eine Ausnahme, bei der vorher keine Formatierung gewählt werden sollte. Eine Liste muss nicht in einen Absatz verpackt werden.
  6. Einzug vergrößern/-kleinern ist fast schon gefährlich – damit setzt Xinha blockquotes um. Im Grunde braucht man nur »Einzug vergrößern«, wobei man auch hier vorher keinen Absatz setzt, dann aber innerhalb des eingerückten Bereiches einen Absatz setzt. Aufheben des Einzuges nicht vergessen.
  7. Farben: Finger weg! Auch das regelt das Template. Schriftfarbe sollte ebenfalls Links vorbehalten sein.

Natürlich schadet es nie, den erzeugten Code hinterher zu kontrollieren – vorausgesetzt, man kennt sich ein wenig mit (X)HTML aus. Ganz wichtig ist dabei vor allem, auf unnötige <br />-Elemente zu achten. Aus demselben Grund ist es auch unbedingt wichtig, nur dann einen Zeilenvorschub mittels Enter zu erzeugen, wenn es erwünscht ist, sprich: Wenn auf einen Textbereich ein weiterer folgt. Ansonsten erzeugt Xinha nämlich u.U. so etwas hier: <p><br /><p>. Pfui!

Generell empfiehl es sich, Xinha nicht zusammen mit dem NL2BR-Plugin für s9y zu verwenden, da Xinha ansonsten auch den Code zum Einfügen von Bildern aus der Mediendatenbank mit <br />-Elementen dekoriert, was die Darstellung von Bildern in Einträgen ziemlich entstellt.

07 Jan 2009 Sokrates für Browserflüsterer

Ich weiß, dass ich nichts weiß.

Sokrates

Genau so geht es uns, die wir mit beruhigender Stimme (vulgo: CSS) auf die störrischen Pferde, Verzeihung: Browser, einreden. Wir wissen nichts, und das Ausmaß des Nichtwissens wird eigentlich täglich größer.

Nicht nur wissen wir nicht, mit welchen Browsern – von Versionen will ich gar nicht erst anfangen – Besucher unsere Seiten betrachten – wir wissen nicht mal, ob sie sie überhaupt betrachten; manche lassen sie sich auch vorlesen. (Und womit? Mit Recht!) Zwar glauben wir nach sorgfältiger Analyse unserer Logdateien und Besucherstatistiken in etwa verlässliche Werte zu haben, mit welcher Bildschirmauflösung unser Durchschnittsbesucher daherkommt, ob das jedoch der Breite (von der Höhe haben wir uns gedanklich längst verabschiedet) des Viewports entspricht, wissen wir jedoch auch nicht. Und selbst wenn: Es kommen täglich neue Auflösungen dazu. Ein Blick in die Statistiken verkommt da schnell zum heiteren Endgeräteraten (320x240, was ist das? PSP?).

Wir gestalten munter in der Annahme, jeder grafische Webbrowser käme ab Werk mit einer voreingestellten Schriftgröße von 16 Pixeln daher (was in der Theorie auch stimmt), aber wir wissen natürlich nicht, ob und wie der einzelne Benutzer das ggf. verändert hat. Das passt allerdings ganz gut dazu, dass wir auch nicht wissen, ob und wie der Einzelne die Zoom-Funktion(en) der jeweiligen Endgeräte nutzt – vergrößern, verkleinern, nur Text oder gleich alles? Wir haben, offen gesagt, keinen blassen Schimmer. Wagemutige Benutzer könnten sogar mit einem Benutzerstylesheet oder veränderten Farben durch die Untiefen des Netzes browsen. Möglich wär's, man weiß es nicht.

Ganz ehrlich, Du hast keine Ahnung. ist für einen Netzgestalter keine Beleidigung. Es entspricht schlicht den Tatsachen.

29 Dec 2008 Core plugins in s9y 1.4

»Core plugins« sind die Ereignis- und Seitenleisten-Plugins, welche mit dem Kern von Serendipity ausgeliefert werden, also nicht nachträglich manuell oder via Spartacus-Plugin installiert werden müssen. Beginnend mit der Version 1.4 von s9y geben einige dieser Plugins anderen (besseren) HTML-Code aus, was zu Abweichungen in der Darstellung führen kann, falls das Template, welches man verwendet, auf diese Änderungen nicht vorbereitet sind. Sämtliche Templates, die mit s9y ausgeliefert werden, sind ab Version 1.4 natürlich bereits präpariert.

Die Änderungen betreffen die folgenden Plugins wie folgt:

serendipity_archives_plugin
wird nun als ungeordnete Liste (<ul>) ausgegeben
serendipity_authors_plugin
wird nun als ungeordnete Liste (<ul>) ausgegeben
serendipity_syndication_plugin
wird nun als ungeordnete Liste (<ul>) ausgegeben
serendipity_plugin_comments
Code etwas aufgeräumt (meine Notizen sind hier leider lückenhaft – ich meine, auch hier seien unnötige <br /> durch <div>-Verpackungen ersetzt worden)
serendipity_plugin_history
einzelne Textbausteine in <div> verpackt
serendipity_plugin_recententries
wird nun als Definitionsliste (<dl>) ausgegeben
serendipity_plugin_entrylinks
Inline-Styles und unnötige <br /> entfernt
diverse <div> in <span> umgewandelt
serendipity_plugin_shoutbox
unnötige <div> im Formular entfernt
unnötige <br /> entfernt, statt dessen Textbausteine in <div> verpackt

Die Anpassungen im CSS (normalerweise style.css des verwendeten Templates), die notwendig sein könnten, sind der style.css des Templates »Serendipity v2.3« (/templates/default/style.css) zu entnehmen. Dort findet man am Ende eine Liste der Änderungen, die man lediglich noch an das eigene Template anpassen muss.

Warum ist der neue Code nun »besser«? Nehmen wir beispielsweise das Plugin serendipity_archives_plugin: Es generiert eine Liste von Links zu bestimmten Abschnitten des Archivs des Blogs. Der semantisch korrekte Code dafür ist also eindeutig eine Liste, keine Ansammlung von über Zeilenumbrüchen getrennten Links. Das bedeutet, zur Auszeichnung des ausgegebenen Inhaltes wird das HTML-Element verwendet, welches dafür vorgesehen ist, keine Krücke.

29 Dec 2008 s9y 1.4 freigegeben

Knappe neuneinhalb Monate nach v1.3 wurde heute Version 1.4 der besten Blogengine der Welt freigegeben. Die Liste der Verbesserungen und neuen Features ist ellenlang, das Beste aber ist, dass es immer noch »Luft nach oben« gibt.

Unter anderem für mich ein »besonderer« Release, weil Serendipity nunmehr »ab Werk« Bulletproof als Template verwendet. Das BP-Entwicklungsteam hat eigens für diesen Zweck ein zusätzliches Colorset für BP gestrickt, welches den Look des alten Standardtemplates emuliert.

Mein persönliches Highlight in 1.4 aber sind die Veränderungen im generierten HTML-Code diverser Kernplugins (also der Plugins, welche mit Serendipity ausgeliefert werden) – nicht nur, aber zugegebenermaßen auch, weil das die Baustelle war, an der ich aktiv mitgearbeitet habe. Etliche Kernplugins liefern nun semantisch korrektes HTML aus, und es ist mein persönlicher Neujahrsvorsatz, in diesem Bereich auch 2009 weitere Verbesserungen in das Projekt einzubringen, da ich es für einen wesentlichen Aspekt halte.

Ein Artikel, wie diesen Veränderungen CSS-seitig zu begegnen ist, folgt.