Entries tagged as webauthoring

19 Feb 2009 Grün hatte ich noch nie

Als ich vor 9 Monaten – irgendwie auffällige Zeitspanne – zuletzt dem Blog ein neues Kleidchen überzog, da schwante mir bereits, dass ich den Grunge-Look eines nicht allzu fernen Tages satt haben würde. Dem allgemeinen Trend folgend (vgl. etwa die schlichte Eleganz bei serotonic oder Klaus – schnell hin, sonst stellt er es wieder um!), hat nun auch hier die Schlichtheit Einzug gehalten. Unter dem Gesichtspunkt streßfreier Frontendgestaltung über sämtliche Browserabarten hinweg sehr empfehlenswert übrigens.

Die Schlichtheit ist nicht allein optischer Natur, auch funktional galt die Devise: Alles, was keine Miete zahlt, fliegt raus!. Nein, ich habe die allseits beliebten Seitenleisten nicht vergessen – ich habe nur momentan keine Verwendung dafür. Alles, was an Seitenleistenschnickes noch bleiben durfte, ist im Wesentlichen in das nochmals verfeinerte Archiv verbannt. Der Eintragsfuß ist merklich leichtgewichtiger, stets darauf vertrauend, dass meine kleine Besucherschar vor Intelligenz strotzend ohne Frontendkrücken den Weg zu Trackback-URL, Permalink und Kommentarformular finden wird. (Macht mir keine Schande!)

Bye bye, addThis-Widget. Ciao, letzte Artikel und Kommentare. Adios, „Antwort auf”-Dropdown im Kommentarformular. Icons? Auf ein Minimum reduziert! Wir müssen halt alle sparen in diesen Zeiten allgemeiner Teuerung. (Deswegen gibt's das Dropcap da oben jetzt auch nicht in jedem Artikel. Zur Feier des Tages und aus leichter Angeberei schien es mir hier aber angemessen.)

Ansonsten gibt es technisch nach wie vor hochelastische em-Maße (das war jetzt aber echt das letzte Mal – was 'ne Rechnerei!) und frei nach Richard Rutters vertikalem Rhythmus komponierte Zeilen und Abstände. Ich hoffe, das hält in jedem Browser und auch sonst – meine Test sagen: Ja. Kurze Testphase, alles nochmal überschlafen, ein oder zwei massentaugliche Features nachrüsten und dann verspreche ich: Diesmal wird es sogar released! Ehrenwort! (Naja. Mal gucken.)

So. Und wer jetzt was sagen will, kann sich gleich mal das Kommentarformular angucken. Ich hab da auch extra nochmal frisch gewischt.

03 Feb 2009 Eine Alternative: Textile

Grob gesagt unterteilen sich die Nutzer von Serendipity bei der Erstellung von Einträgen meiner Erkenntnis nach in zwei Gruppen: Nutzer eines WYSIWYG-Editors und diejenigen, die reinen (X)HTML-Code in die Textkästen zur Eintragserstellung schreiben. Generell ist der zweite Ansatz vorzuziehen, wenn man Wert auf »sauberes« (lies: valides, semantisch korrektes) Markup legt, allerdings kann man das durchaus auch mit einem WYSIWYG-Editor erreichen, wenn man ein paar Spielregeln befolgt.

Eine echte, aber (soweit ich das mitbekomme) von s9y-Nutzern nur selten eingesetzte Alternative ist das Textile-Plugin (wird mit s9y ausgeliefert). Auch ohne Pluginaktivierung kann man Textile zunächst auf textism.com mal generell ausprobieren und sich von der schlichten Schönheit der Markup-Befehle überzeugen lassen. (Die wahre Schönheit von Textile besteht allerdings darin, dass es diese Auszeichungen stets in sauberes (X)HTML umsetzt.)

»Vorreiter« in puncto Textile mit Serendipity ist Robert, der seit einiger Zeit Textile benutzt. Bei Robert findet man bereits einige interessante Einblicke in die Arbeit mit Textile, u.a. den wichtigen Hinweis, Textile nicht mit dem Serendipity-Markup-Plugin zu mischen. (Zu dem anzumerken wäre, dass das Serendipity-Markup durch Textile ohnehin 100% überflüssig wird.)

Nachtrag: Auch das Plugin Typographic Smart Quotes (serendipity_event_typoquote) beißt sich mit Textile. Es verhindert die korrekte Auszeichnung von Hyperlinks, da es die in der Textile-Syntax notwendigen Anführungszeichen ebenfalls umwandelt.

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.