toscho.design» CSS

CSS: tab-size

Thomas Scholz — Fri, 06 Jan 2012 05:19:10 +0000

Als Kontrapunkt zum letzten Artikel hier mal eine so unterhaltsame wie nutzlose CSS-Spielerei: Alle Browser haben sich inzwischen darauf geeinigt, daß das Zeichen TAB (U+0009, der Tabulator) wie acht Leerschritte darzustellen sei. Ein schwachsinnig hoher Wert, wenn man Code darstellen möchte – zumindest kenne ich niemanden, der das in seinem Editor eingestellt hat.

Rettung ~~naht~~ gibt es vielleicht irgendwann: Im CSS Text Level 3 wird die Eigenschaft tab-size vorgeschlagen. Die Diskussion dazu findet man in der CSS-Mailingliste des W3C.

pre
{
    tab-size: 4; /* Nimm vier Leerzeichen! */
}

Das setzt freilich voraus, daß der Browser das Zeichen TAB im Shadow DOM in ein Pseudo-Element packt. Und das können derzeit nur Firefox und Opera. Mit einem Vendorpräfix.

pre
{
    -moz-tab-size: 4;
    -o-tab-size:   4;
    tab-size:      4;
}

Der Test, der auch andere Präfixe prüft, zeigt in Opera und Firefox das erhoffte Ergebnis:

WebKit (hier Chrome) und der IE 9 machen leider dieses:

Fazit: Taugt erstmal nur fürs Userstylesheet. Immerhin. In den nächsten zwei Jahren werden wir unseren Code weiterhin ein bißchen vorbereiten müssen und Tabs in Leerzeichen umwandeln – oder auf die ollen Nischenbrowser pfeifen.

CSS langweilt mich

Thomas Scholz — Wed, 04 Jan 2012 08:07:49 +0000

1998 habe ich mich mal zwei Tage hingesetzt und die taufrische CSS-2.0-Spezifikation durchgelesen. Vieles hat nirgendwo funktioniert. Ich fand’s trotzdem toll.

Quälend langsam haben dann einzelne Browser ihre skurrilen Interpretationen der Regeln eingebaut. Da gab es eine Menge zu lernen und zu hacken. Jeder Browser hatte nicht nur Macken, die zu den Macken der anderen inkompatibel waren, sondern auch ein rasch wechselndes Set proprietärer Eigenschaften. Es hat Spaß gemacht, da herumzukurven, im Usenet oder auf Mailinglisten mit anderen Leuten zu tüfteln und zu testen.

Heute ist das weg. Mit den superkaputten Browsern ist auch das Gefühl verschwunden, beim Umgang mit CSS den Kopf zu brauchen. Klar, es gibt immer noch kleine Hacks und vorläufige proprietäre Implementationen. Meistens laufen die nur auf ein weiteres Snippet in der IDE hinaus. Aber früher, als man nicht einmal width schreiben konnte, ohne von mindestens drei Browsern eins in die Fresse zu kriegen, war das irgendwie … spannender.

CSS3 hat uns viele neue Eigenschaften gebracht aber kaum neue Konzepte. Viele Module sind nicht einmal kompatibel zueinander, und das Entwicklungstempo ist – so wirkt es auf mich – deutlich gesunken. Kein Wunder, ich verlöre angesichts dieses Wustes auch die Lust.

Manches nervt sogar. Ich habe die Nase voll von Schättchen und Verläufen, von abgelutscht aussehenden Ecken und Schrift mit Pseudo-Prägeeffekt. Kitsch. Hier wird das alles demnächst verschwinden.

Der Grund für das Fefe-Theme war nicht Fefe. Der Grund waren all die anderen Layouts, die ich in den letzten Jahren verfaßt habe. Bei denen ich zu viel Zeit mit zu leichtem Code verbringen mußte.

Ich bin, wie Aristoteles einst so schön gesagt hat, ein krummes Holz, das mal in die andere Richtung gebogen werden muß. Von mir selbst.

WordPress: Adminbar in Systemfarben

Thomas Scholz — Wed, 06 Apr 2011 20:38:19 +0000

Ich finde die neue Adminbar recht praktisch, zumindest mit der Debug-Bar.

Leider sieht sie dämlich aus: Hellgrau auf Mittelgrau, zeitgemäß verhunzt mit Schatten und abgerundeten Ecken. Kinkerlitzchen, CSS3 vom Schlimmsten.

Ich habe diesen Quatsch mal aufgeräumt, die Farben auf die des Betriebssystems umgestellt und ein Plugin daraus gemacht:

Admin Bar In System Colors

Das kann hoffentlich jede und jeder gut lesen.

Forks, Fragen oder ~~Fer~~ Verbesserungsvorschläge?

Umfangreiche Browsertests habe ich noch nicht gemacht – keine Zeit! – und vielleicht sollte ich das Standardstylesheet komplett ersetzen, statt es zu überschreiben. Auch über die feste Höhe samt Pixelschriftgröße werde ich sicher nochmal nachdenken. Und die kleine Grafik für aufklappbare Menus kann man kaum noch erkennen …

Weiterlesen

WordPress: Internet Explorer ohne CSS-Hacks ansprechen

Thomas Scholz — Tue, 28 Sep 2010 07:43:50 +0000

Den Internet Explorer betrachten die meisten Webentwickler zu Recht als chronische Krankheit. Neben anderen Browsern sieht auch die kommende Version 9 eher bedrückend aus. Ehe wir diesem Browser keine Extrawurst mehr braten müssen, wird noch viel Zeit vergehen.

Um den IE im Stylesheet gesondert anzusprechen, brauchen wir weder Hacks im CSS noch eine zusätzliche Datei oder gar (pfui!) eine serverseitige Browserweiche. Wir müssen nur das Element über Conditional Comments anpassen. Diese Idee hatte Paul Irish schon 2008.

Ich habe das neulich in einem WordPress-Theme eingesetzt und mag es so sehr, daß ich künftig all meine Themes damit ausrüsten werde.
Ein wenig umständlich: Die Sprachattribute werden in WordPress mit der Funktion language_attributes() erzeugt – und die hat ein fest eingebautes echo, das man nicht abschalten kann. Ich will nun nicht drei Meter Code in der header.php stehen haben, deshalb habe ich mir zwei kleine Funktionen gebaut. Die Funktion get_language_attributes() ist obendrein etwas schlanker als das Original, und sie gibt das Attribut dir nur aus, wenn der Text von rechts nach links läuft. Andernfalls ist es an dieser Stelle überflüssig.

Doch zum Code, er gehört in die functions.php:

/**
 * html5 start tag + language attribute + conditional tags for IE Win
 * @link   http://paulirish.com/?p=88
 * @param  bool $print
 * @return void|string
 */
function htmlstart($print = TRUE)
{
    $out  = '';
    $lang = get_language_attributes();
    $ies  = array (
        6 => 'lte6 lte7 lte8'
    ,   7 => 'lte7 lte8'
    ,   8 => 'lte8'
    ,   9 => ''
    );

    foreach ( $ies as $n => $class )
    {
        $out .= "";
    }

    $out .= "$lang>";

    if ( ! $print )
    {
        return $out;
    }

    print $out;
}

if ( ! function_exists('get_language_attributes') )
{
    /**
     * Returns the language attributes.
     *
     * Unobstrusive copy from the core.
     * Requires WP 3.0+
     *
     * @param string $doctype The type of html document (xhtml|html).
     */
    function get_language_attributes($doctype = 'html') {
        $output = is_rtl() ? 'dir="rtl"' : '';

        if ( $lang = get_bloginfo('language') )
        {
            $output .= ( ( get_option('html_type') != 'text/html'
                || $doctype == 'xhtml' )
                ? ' xml:' : '') . 'lang="' . $lang . '"';
        }

        return apply_filters('language_attributes', $output);
    }
}

Im Theme rufen wir die Funktion dort auf, wo früher die Doctype-Deklaration und das Start-Tag standen.
Die Ausgabe sieht (hier aufgehübscht) etwa so aus:







    "de-DE">

Nein, das ist kein sehr schönes Markup mehr. Aber so richtig schlimmes auch nicht. Obendrein validiert es.

Im Stylesheet können wir den Internet Explorer jetzt ganz einfach mit der passenden Klasse ansprechen:

.ie8
{
    top:        10px;
}
.lte7
{
    top:        15px;
}

Das kann ich mir viel besser merken als Kommentarhacks oder Spielereien mit ungültigen Selektoren und Eigenschaften.

Mehrere Internet Explorer auf einem Windows kann man sich mit der Utilo IE Collection einrichten. Zum Testen der Conditional Comments habe ich im Labor eine kleine Seite eingerichtet: CC-Test.

WordPress: Moderationslinks für Kommentare

Thomas Scholz — Thu, 29 Apr 2010 20:58:09 +0000

Trotz des Antispam-Plugins schlüpft auch hier manchmal ein Müllkommentar durch den Filter, oder ich vertippe mich … für diese Fälle bietet WordPress an, Kommentare zu bearbeiten, als Spam zu markieren oder ganz zu löschen. Im Backend.

Das ist mir ein wenig zu umständlich; deshalb habe ich in meiner Klasse ›XWP‹, die zusätzliche Templatetags erzeugt, folgenden kleinen Schnipsel eingebaut, den ich von Joost de Valk abgeguckt habe:

    /* Generates comment moderation links.
     *
     * @author Joost de Valk
     * @link   http://yoast.com/wordpress-functions-supercharge-theme/
     * @param  int $id Comment id - use get_comment_ID()
     * @return void
     */
    public static function delete_comment_link($id)
    {
        if ( ! current_user_can('moderate_comments') )
        {
            return;
        }

        global $post;

        $redirect = get_permalink( $post->ID );

        $links = array (
            'delete'  => 'cdc',
            'spam' => 'cdc&dt=spam',
            'edit' => 'editcomment'
        );

        $return = '';

        foreach ( $links as $name => $param )
        {
            $return .= "$name";
        }

        print $return . '';

        return;
    }

In der comments.php rufe ich die Funktion innerhalb des Kommentarloops auf:

XWP::delete_comment_link( get_comment_ID() );

Das erzeugt etwa dieses Markup:

comment_admin">
  delete
  spam
  edit

Mit ein wenig CSS aufgepeppt …

.comment_admin
    {
        float:              right;
        font:               .9em/1 Calibri;
        text-align:         center;
    }
.comment_admin a
    {
        color:              #444;
        background:         #f9f9f9;
        text-decoration:    none;
        border:             1px solid #bbb;
        border-radius:      4px;
        box-shadow:         0 2px 3px rgba(0,0,0,0.2);
        display:            inline-block;
        width:              3em;
        margin:             4px;
        padding:            4px 15px;
    }
#content .comment_admin a:hover
    {
        background:         #666;
        color:              #fff;
        border:             1px solid #222;
    }

… sieht das Ergebnis dann so aus:

Nach einem Klick landet man in der Bearbeitungsmaske im Backend, dann erst wird der Kommentar per Knopfdruck gelöscht oder als Spam markiert.

Mehr so’n Zeug:

Designlinks 12

Thomas Scholz — Wed, 28 Apr 2010 10:19:33 +0000

Wird mal wieder Zeit. Aber zuerst entspannen wir uns ein bißchen:

Quelle: CollegeHumor.

›Do not use PHP references‹, empfiehlt Johannes Schlüter, denn Referenzen kosten Tempo, Übersicht und Flexibilität. Ob seiner klaren und verständlichen Darstellung dieses kniffligen Themas möchte ich den Artikel jetzt schon in die Liste der zehn besten dieses Jahres rücken.

Nicholas C. Zakas: History of the user-agent string. Warum die UA-Strings heute oft so sonderbar aussehen. Die neue Kennung des IE 9 lautet:

Mozilla/5.0 (compatible, MSIE 9.0; Windows NT 6.1; Trident/5.0)

Anhängsel irgendwelcher Zusatzsoftware werden nicht mehr eingebaut; damit schrumpft die Liste der möglichen Kennungen gewaltig – was es Proxys erheblich erleichtert, gespeicherte Versionen einer Webseite auszuliefern. Das erklärt Billy Hoffman gut in: ›The Big Performance Improvement in IE9 No One is Talking About‹. Er rät auch dazu, die gzip-komprimierte Version nur noch anhand des Accept-Headers zu versenden und den User-Agent zu ignorieren, damit beispielsweise ein Safari-Nutzer die Version bekommt, die der Firefox-Nutzer zuvor in den Proxy gehievt hat.

Man kann dezimale Zeichenreferenzen mit beliebig vielen führenden Nullen versehen. So läßt sich das A als A schreiben oder als A
›hakre‹ hat mal ausprobiert, wie weit man damit gehen kann: ›HTML Entity Boundaries – Zero Padding‹.
Ein Experiment, dessen praktischer Nutzen sicher weit unter seinem Unterhaltungswert liegt. Doch zeigt es, wie weit die Entwickler vorausdenken und wo sie die Grenze ziehen zwischen ›das versuche ich noch‹ und ›das wird zu langsam‹. Wenig überraschend frißt Firefox die meisten Nullen – bis zum Erstickungstod.

Anne van Kesteren hat auch ein Experiment mit gewaltigem Geekpotential hingestellt: Live style sheet editing!
Und da muß ich einfach mal den Quelltext zitieren:



 
  Live style sheet editing!

Zum Schluß noch ein Link für die Freunde der Maus: Harmony, ein Zeichenprogramm in Javascript und Canvas. Das macht wirklich Freude.

Text-rendering: illegibility

Thomas Scholz — Mon, 26 Apr 2010 05:11:26 +0000

Wenn zwischen Absicht und Ergebnis fremder Code steht, dann braucht der geübte Binärschubser seine wichtigste Kompetenz: Fluchen. So auch ich, als ich gestern von Christoph Schnieder dieses kleine Horrorstück zugesandt bekam:

Tatort war ein Palm Pre WebOS, Tatwerkzeug der eingebaute Browser auf WebKit-Basis.

Um das überhaupt nachzuvollziehen, habe ich den MobiOne Emulator für Palm Pre installiert. Das ging verdächtig leicht, und das Ergebnis half mir überhaupt nicht. Es war nämlich in Ordnung:

Dieser Emulator ist im Wesentlichen ein zurechtgestutztes Eclipse; seine Abhängigkeit vom Gastsystem erkennt man schon daran, daß er dessen Schriften benutzt. Unbrauchbar.

Dann habe ich das Palm webOS SDK installiert, das in einer virtuellen Maschine läuft – und das Problem ganz genau wiedergibt. Das scheint also ein recht realistisch arbeitendes Werkzeug zu sein. Etwas umständlich finde ich nur das englische Tastaturlayout, das ich nicht umstellen konnte.

Nach allerlei Tests habe ich endlich die Ursache gefunden: Ich hatte im Stylesheet eine Deklaration stehen, von der ich annahm, sie werde nur von Gecko interpretiert.

p,
address,
li
    {
        text-rendering:optimizeLegibility;
    }

Diese Eigenschaft stammt aus SVG, wie man leicht an der dämlichen Binnenmajuskel erkennt. Sie sollte Firefox dazu anregen, auch bei kleineren Schriftgraden als 20px das Kerning zu respektieren.
Was genau der Palm Browser hier versucht, vermag ich nicht zu sagen. Vielleicht hängt es mit der Schriftgröße zusammen, denn Überschriften, die mindestens 20px groß sind, werden noch gezeigt.

Ich habe die ganze Regel jetzt weggeworfen und einen Bugreport geschrieben.

Sicher ließe sich das auch hinter einem proprietären Selektor für Mozilla verstecken, aber davon will ich eigentlich weg. Und wenn ich damit leben kann, daß Mozilla-Nutzer noch keine abgerundeten Ecken sehen, dann darf ich genauso gut unterstellen, daß sie sich an schlampiges Kerning gewöhnt haben. Also nehmt es mir nicht übel, ja?

Ach ja, das aktuelle Ergebnis:

Da der Browser jetzt nur die Systemschriften des Palm OS verwendet, setzt er keine Kursivschnitte für serifenlose Schriften mehr um, und eine Monospace-Schrift findet oder nutzt er auch nicht. Das ist nicht schlimm, aber man kann es unter »Aha. Mist!« ablegen.

CSS: Knapp, frisch und lange haltbar

Thomas Scholz — Sat, 24 Apr 2010 09:59:28 +0000

Vor einiger Zeit habe ich mal gezeigt, wie man mittels eines UNIX-Timestamps in der Adresse dem Browser immer das aktuelle Stylesheet darbietet:

stylesheet"
  media="screen,projection"
  href="/wp-content/themes/toscho/css?d=1229632675"
  title="screen+projection"
  type="text/css"
>

Nachteile der alten Variante

Das Grundprinzip verwende ich immer noch, aber im Zuge des letzten Redesigns habe ich es um ein paar Nuancen verfeinert. An der alten Variante haben mich nämlich einige Dinge gestört:

Ich mußte den Cache des Clients immer per PHP validieren, was unnötig Zeit kostet.
Die resultierende URL sieht lang und umständlich aus. Durch das Fragezeichen darin fühlten sich nicht alle Browser zum Cachen angeregt.
Das Stylesheet mußte unter dem selben Host liegen wie das Theme, was parallele Requests erschwert.

Umzug auf die Subdomain

Nun habe ich hier noch eine ungenutzte Domain herumliegen – mundonaut.de –, auf der mein Bruder eigentlich ein bißchen bloggen wollte. Oder sollte.
Trotz Prüfungen, Umzug und Magisterarbeit hat er das bis heute seltsamerweise nicht geschafft, und so gammelte die Domain nur so vor sich hin. Schade.

Ich habe dort jetzt eine Subdomain angelegt: t4.mundonaut.de, auf der ich alle kleinen Dateien für dieses Theme parke: Bilder, Javascripte und Stylesheets.

Die können jetzt von den Browsern parallel zu dieser Seite und ihren Inhaltsbildern heruntergeladen werden, die nur wenige Verbindungen pro Host öffnen – IE 7 beispielsweise nur zwei. Außerdem exisitieren für die Subdomain keine Cookies; das reduziert auch den HTTP-Overhead ein wenig.

Schöner Dateiname

Den UNIX-Timestamp habe ich vom Parameter in den Dateinamen verlegt. Die neue Adresse des Stylesheets – ich benutze jetzt nur noch eines für alle Medientypen und eins für alte Internet Explorer – sieht nun beispielsweise so aus:

http://t4.mundonaut.de/1271536949.css

Den lokalen Dateipfad habe ich fest ins Theme geschrieben; mittels filemtime() erzeuge ich den passenden Namen.

In der .htaccess der Subdomain t4 lenke ich die Anfragen dann auf die jeweils passende Datei:

# Ein UNIX-Timestamp enthält genau 10 Ziffern: \d{10}
RewriteEngine On
RewriteRule ^\d{10}\.css main.css [L]
RewriteRule ^\d{10}\.ie\.css ie.css [L]

Jetzt kümmert sich der Server um die Validierung des Client-Caches; der macht das natürlich viel schneller als ich.

Kompression

Auch die übernimmt der Server. Bei meinem Webhoster all-inkl.com ist die Kompression für Textdateien ohnehin schon angeschaltet; auch darum muß ich mich nicht mehr kümmern. Müßte ich es, so verwendete ich mod_deflate:

AddOutputFilterByType DEFLATE text/plain text/css

Der Apache speichert das Ergebnis; so hält sich die Mehrarbeit in engen Grenzen.

Lokal komprimiere ich das Stylesheet vor: Ich entferne unnötige Leerzeichen, Zeilenumbrüche und Kommentare. Für das Script gibt es auch eine Weboberfläche im Labor: CSS Compressor.

ETag

Damit die Cache-Validierung besser klappt, habe ich noch ETags aktiviert:

FileETag MTime Size

Obacht! Ältere Apachen (vor Version 2.2.12) erzeugen einen kaputten ETag für automatisch komprimierte Dateien. Der sieht dann so aus:

ETag: "47b5361382042"-gzip

Damit kann man den Cache des Clients bestenfalls verhindern. Ich habe All-Inkl darauf hingewiesen – und einen Tag darauf hatte ich einen aktualisierten Server. Das nenne ich Service.

Expires

Als Sahnehäubchen gibt es noch eine ausgedehnte Verfallszeit:

# Lang lebe euer Cache!
ExpiresActive On
ExpiresByType image/png                "access plus 1 year"
ExpiresByType image/jpeg               "access plus 1 year"
ExpiresByType image/gif                "access plus 1 year"
ExpiresByType image/x-icon             "access plus 1 year"
ExpiresByType image/icon               "access plus 1 year"
ExpiresByType application/x-javascript "access plus 3 months"
ExpiresByType text/css                 "access plus 3 months"

Nachteile der neuen Variante

Das Theme ist jetzt fest an diese Domain gebunden und nicht mehr portabel. Das spielt hier keine Rolle; aber wer Themes schreibt, deren Einsatzort unbekannt ist, kann damit wenig anfangen.

Die ETag-Direktive kann nur bei einem halbwegs aktuellen Server benutzt werden, und mod_rewrite braucht man auch.

Andererseits läßt sich das Verfahren auf jedes Layout übertragen, ob es nun von WordPress erzeugt wird oder nicht.

WordPress-Plugin: Backend Style Enhancements

Thomas Scholz — Fri, 23 Apr 2010 13:16:12 +0000

Zwar läßt sich das WordPress-Backend ganz gut per Userstylesheet über den Selektor body.wp-admin ansprechen – doch technisch unbedarften Leuten hilft das eher wenig. Für eine Freundin, die ebenso wie ich eine Navigation lieber rechts oder oben sieht, habe ich deshalb mal fix ein kleines Plugin erstellt.

Es ist ganz einfach, spricht aber ein paar Dinge an, die ich im Framebreaker-Tutorial nicht berührt habe. So mag es sich vielleicht als Lehrstück eignen. Ich verkneife mir heute einen langen Text; stattdessen habe ich alles ausführlich kommentiert und verlinkt.

Das Stylesheet selbst setzt die Navigation nach rechts, gibt Links bei :hover einen Unterstrich und entsorgt Lucida Grande und Verdana, die ich beide nicht mehr sehen mag. Außerdem repariert es ein paar Breitenangaben – die Entwickler konnten sich wohl nicht vorstellen, daß jemand 14px als Mindestschriftgröße setzt. Das muß man leider als Massenpsychose diagnostizieren.

Im Ganzen sei es bitte nur als Beispiel dafür gesehen, was man ändern kann.

/*
Plugin Name: Backend Style Enhancements
Plugin URI:  http://toscho.de/p1660
Description: Some minor fixes for the WP backend.
Version:     1.0
Author:      Thomas Scholz
Author URI:  http://toscho.de
Created:     22.04.2010
*/

/**
 * We need just the constructor.
 */
new Toscho_Backend_Style;

/**
 * Adds a stylesheet to the WordPress backend.
 *
 * @version 1.0
 */
class Toscho_Backend_Style
{
    /**
     * The address for our stylesheet.
     * Should match [0-9a-z-].
     *
     * @see #add_query_arg()
     * @see #print_link_element()
     * @var string
     */
    protected $query_arg = 'tbecss';

    /**
     * Constructor
     */
    public function __construct()
    {
        /* Register the query argument. */
        add_filter('query_vars', array ( $this, 'add_query_arg') );

        /* What should happen, if we find the query? */
        add_action('template_redirect', array ( $this, 'print_css') );

        /* Like wp_head, just for the backend. */
        add_action('admin_head', array ( $this, 'print_link_element') );

        /* Since this plugin isn’t listed on
         * http://wordpress.org/extend/plugins/
         * we won’t waste the user’s time.
         */
        add_filter('http_request_args',
            array ( $this, 'prevent_plugin_upgrade_check' ), 5, 2);

        return;
    }

    /**
     * Registers the query arg in WordPress
     *
     * @param  array $vars Already registered query args.
     * @return array
     */
    public function add_query_arg( array $vars )
    {
        return array_merge( $vars, array ( $this->query_arg ) );
    }

    /**
     * Prints the CSS content.
     *
     * @return void
     */
    public function print_css()
    {
        if ( ! isset ( $_GET[$this->query_arg] ) )
        {
            return;
        }

        // Don’t waste time in wp-includes/template-loader.php
        define('WP_USE_THEMES', FALSE);

        header('Content-Type: text/css;charset=utf-8', TRUE);

?>@charset "utf-8";
.wrap a:hover
{
    text-decoration:    underline       !important;
}
.wrap a.button:hover
{
    text-decoration:    none            !important;
}
body,
td,
input,
select,
#adminmenu *
{
    font-family:        Calibri         !important;
}
textarea, [type="text"]
{
    font-family:        Consolas        !important;
}
body,
#wpbody,
.form-table .pre
{
    color:              #000            !important;
}
td
{
    vertical-align:     top             !important;
    line-height:        1.4             !important;
}
#adminmenu
{
    float:              right           !important;
    margin:             5px -150px 0 0 !important;
}
#adminmenu .wp-submenu li
{
    width:              151px           !important;
}
#wpbody-content
{
    float:              right           !important;
    width:              100%;
}
#wpbody
{
    margin-left:        0               !important;
    margin-right:       170px           !important;

}
/* Ugly, yes. But if we just return, WP will
         * proceed and append the default page. */
        exit;
    }

    /**
     * Prints the link element into the admin head.
     *
     * @return void
     */
    public function print_link_element()
    {
        $url = get_option('siteurl') . '/?' . $this->query_arg;
        print "";

        return;
    }

    /**
     * Blocks update checks for this plugin.
     *
     * @author Mark Jaquith http://markjaquith.wordpress.com
     * @see    http://wp.me/p56-65
     * @param  array $r Request information
     * @param  string $url
     * @return array
     */
    public function prevent_plugin_upgrade_check($r, $url)
    {
        if ( 0 !== strpos($url,
             'http://api.wordpress.org/plugins/update-check') )
        { // Not a plugin update request. Bail immediately.
            return $r;
        }

        $plugins = unserialize( $r['body']['plugins'] );
        $p_base  = plugin_basename( __FILE__ );

        unset (
            $plugins->plugins[$p_base],
            $plugins->active[array_search($p_base, $plugins->active)]
        );

        $r['body']['plugins'] = serialize($plugins);

        return $r;
    }
}

Als Lohn für das ~~geduldige Lesen~~ schnelle Herunterscrollen:

Download Plugin Backend Style Enhancements

Meine Kommentare ersetzen natürlich nicht eure Fragen. Also stellt sie bitte!

Typographie: Blocksatz vermeiden

Thomas Scholz — Tue, 13 Apr 2010 11:25:37 +0000

Ich habe Lesen ganz unsystematisch gelernt, ohne den Einsatz des Zeigefingers oder kleiner Schmuckbildchen. Und so lese ich heute, wenn ich einmal in Fahrt gekommen bin, immer zwei Zeilen auf einmal: Die obere Zeile entschlüssele ich, während ich mir von der darunterliegenden einen ›Schnappschuß‹ erstelle. Wenn ich es so hinschreibe, klingt das ganz umständlich, aber ich schaffe doch 100—150 Seiten pro Stunde.

Wenn der Rhythmus stimmt.

Blocksatz in der YAML-Dokumentation

Damit meine ich nicht allein den Rhythmus der Sprache – bei dem Tempo spreche ich innerlich ohnehin nicht mehr mit – sondern den visuellen Eindruck. Viele kleine Absätze mit großem Abstand behindern meine Technik ebenso wie ein sehr hoher Zeilenabstand. Aber am schlimmsten finde ich schlechten Blocksatz.

Guter Blocksatz fällt nicht auf. Daran erkennt man gelungene Typographie: Der Abstand zwischen den einzelnen Zeichen (Kerning) paßt zu den Wortzwischenräumen und bleibt über viele Zeilen hinweg sehr konsistent. Ein geübter Setzer stimmt also Zeichen-, Wort- und Zeilenabstände aufeinander ab.
Im Ergebnis paßt der Grauwert am rechten Rand zu dem des übrigen Textes.

Schlechter Blocksatz kriegt nur den rechten Rand hin und zerstört den Rest. Zwischen den einzelnen Worten entstehen Abstände, die manchmal den größten Raum der Zeile beanspruchen und untereinander einen River of White Space bilden; Anfang und Ende eines Satzes muß der Leser suchen, weil das visuelle Signal (langer Abstand) dem Inhalt (der Satz geht weiter) widerspricht.

In der Ausgabe am Bildschirm haben wir als Autoren oft keinen oder wenig Einfluß auf die tatsächlich verwendete Schriftgröße. Eine zuverlässige automatische Silbentrennung können wir auch nicht benutzen, und ein Kerning, das für jede Zeile paßt, können wir uns ganz aus dem Kopf schlagen.

Guter Blocksatz ist in HTML und CSS nicht möglich. Selbst in E-Books wird er sehr, sehr schwer.

Aber ich kann doch …

… eine feste Breite und Schriftgröße vorgeben, Umbrüche und Trennstriche manuell setzen und so einen akzeptablen Blocksatz erreichen?

Glücklicherweise nicht. Die Schriftgröße des Lesers ist unbekannt. Ebenso die verwendete Schrift. Wer HTML und CSS benutzt, der hat automatisch Koautoren; das ist eingebaut. Noch gibt es ein paar ›Designer‹, die sagen: »Selber schuld! Wer meine Vorgaben überschreibt, darf sich nicht beschweren.«
Als Physiker ignorierten die vermutlich auch die Schwerkraft, und als Lehrer die jugendliche Neugier.

… Javascript und Canvas benutzen?

Das scheitert an Browsern, die kein Canvas unterstützen, an abgeschaltetem Javascript und an der sehr schlechten Zugänglichkeit in eingebetteter Texte.

Worauf ich hinaus will, ist aber keine typographische Frage, sondern: Für wen schreibe ich eigentlich? Für den willenlosen Leser ohne eigene Ansichten und Präferenzen? Oder für einen mündigen Leser, der beides eben hat und darum auch von meiner Ansicht überzeugt werden kann – oder ihr ein spannendes Argument entgegensetzt?
Für den ersten brauche ich gar nicht zu schreiben; das lohnt sich nicht. Und den zweiten sollte ich besser nie mit Blocksatz ärgern.

Lektüre

Jukka "Yucca" Korpela: How do I justify text on both sides on Web pages?
Ilene Strizver: Justified Type
Typolexikon: Blocksatz
Fritz Weisshart: Blocksatz, Silbentrennung und die Screen Reader (nachgetragen am 20. 10. 2010)