• man fragt einen Bekannten, der sich mit PHP und WordPress auskennt, ob er einem hilft
• in einschlägigen Foren einen Anfrage stellen
• auf freelancer Foren das Gesuch gegen Bezahlung aufgeben (bäääähh )
• man setzt sich auf seinen Hintern und versucht es selbst

Jetzt kann natürlich jeder selbst entscheiden, was er / sie gern selbst machen würde. Wer Option 1 — 3 wählt, kann hier eigentlich schon aufhören mit lesen.

Alle anderen angehenden WordPress Profis sind herzlich dazu eingeladen hier zu erfahren, wie man sich selbst ein Plugin schreibt. Und zwar auf die harte Tour: objektorientiert — yeah!

An wen richtet sich dieses Tutorial? Wie  geht’s los?

Dieser Artikel richtet sich grundsätzlich an Personen, die bereits Kenntnisse im Umgang mit PHP haben und denen das grundlegende Konzept der objektorientierten Programmierung nicht unbekannt ist.

So, was brauchen wir hier so? Erstmal ein Grundlagenwissen in PHP — logisch. Dann sollte man sich etwas mit dem System WordPress an sich auskennen. Hier empfiehlt es sich mal in den WordPress Codex reinzuschauen. In diesem Codex findet man eine verhältnismäßig gute Dokumentation darüber, wie man seinen Blog erweitert oder eben ein WordPress Plugin aufbauen kann. Dann brauchen wir noch die Seite von Adam Brown — WordPress hooks database. Auf der Seite findet man sämtliche Hooks von WordPress inkl. Revisionen.

Hook? Captain Hook oder was??

WordPress hat die tollen Eigenschaft, dass man sich nahezu an jeder Stelle ins System “einhängen” kann um den Ablauf seinen Bedürfnissen anzupassen. Es gibt zwei Arten von Hooks: Actions und Filter.

Actions

Ein Action Hook ist ein Hook, der sich zu einem bestimmten Zeitpunkt ins System einklinkt. Dabei kann man dann z.B. eine eigene PHP-Funktion aufrufen. Die reagieren also auf bestimmte Aktionen des Systems.

Filter

Filter dienen der hauptsächlich der Änderung von Texten. Erst nach diesen Änderungen werden sie dann z.B. in der Datenbank gespeichert, oder angezeigt.

So, das war ein absolut minimaler und oberflächlicher Exkurs in die Hooks von WordPress. Detailwissen gibt es dann im WordPress Codex. Aber jetzt legen wir mal los. Unser WordPress Plugin soll mal etwas Quelltext bekommen.

Das Grundgerüst — die Klasse

/*
   Plugin Name: Mein erstes WordPress Plugin
   Plugin URI: http://www.guardian-online.de
   Description: Das ist mein allererstes WordPress Plugin
   Author: Benno Mielke
   Author URI: http://www.guardian-online.de
   Version: 0.0.1
*/

if( !class_exists( 'myPlugin' ) ) {
   class myPlugin {

      function __construct() {
         register_activation_hook( __FILE__, array( &$this, 'activate' ) );
         register_deactivation_hook( __FILE__, array( &$this, 'deactivate' ) );
      }

      function activate() {
         // hier setzen wir unsere Hooks, z.B.:
         add_action( 'edit_category_form', array( &$this, 'myHookCategory' ) );
      }

      function deactivate() {
         // hier räumen wir wieder auf, wenn das Plugin deaktiviert wird, z.B.:
         remove_action( 'edit_category_form', array( &$this, 'myHookCategory' ) );
      }

      function myHookCategory() {
         // hier kommt der Quelltext, den wir ins System bringen wollen
         echo '<h3>Mein erster Hook, yay!</h3>';
      }
   }
}

Also eigentlich sollte der Aufbau bisher nicht sonderlich verwunderlich sein. Jeder der schon mal etwas mit objektorientierter Programmierung zu tun hatte, müsste mit dem Klassenprinzip vertraut sein. Aber fangen wir trotzdem mal oben an …

Der Kommentarblock

Der Kommentarblock ist relativ wichtig — auch im Aufbau. Hier liest das System die Grundinformationen aus, welche später in der Übersichtsseite der Plugins erscheinen. Also übernehmt diesen Block so und ändert einfach die Informationen.

Die Klasse an sich

… und es beginnt hier mit einer kleinen “Sicherheitseinrichtung”. Die Zeile

if( !class_exists( 'myPlugin' ) ) { 

prüft, ob unsere Klasse schon mal existiert. Wobei … eigentlich falsch ausgedrückt. Es wird hier geprüft, ob unsere Klasse noch nicht (man achte auf das !) existiert — in dem Fall wird sie “angelegt”. Es reicht ja, wenn sie einmal existiert und nicht 100.000 Mal. Macht ja keinen Sinn.

Danach kommen die OOP-typischen Methoden und Attribute, Funktionen und Variablen, oder wie auch immer Wir haben einen Konstruktur in Zeile 14, eine Art zweiten Konstruktur in Zeile 19, mit dem wir unsere Hooks am System anmelden, einen nicht auf den ersten Blick erkennbaren Destruktor in Zeile 24, mit dem man wieder aufräumen sollte (Hooks deaktivieren, Datenbankeinträge entfernen etc.), und in Zeile 29 haben wir endlich die erste eigene Plugin-Funktion, die auch tatsächlich mal etwas “sinnvolles” für uns macht — nämlich eine Ausgabe in der Kategorie-Ansicht im Backend.

Der Konstruktor

Der Konstruktor dürfte auf den ersten Blick etwas seltsam aussehen. Es sind nur zwei Funktionen vorhanden:

register_activation_hook( ... );
register_deactivation_hook( ... );

Die Funktion register_activation_hook()

Diese Funktion dient dazu, dem WordPress System mitzuteilen, welche Methode ausgeführt werden soll, wenn das WordPress Plugin aktiviert wird. Erst danach können die eigentlichen Hooks greifen. In unserem Fall rufen wir activate() auf, um unsere Hooks am System anzumelden.

Die Funktion register_deactivation_hook()

Hier haben wir quasi das Gegenteil der Funktion register_activation_hook(). Wird das WordPress Plugin daktiviert, wird die Funktion aufgerufen, die als Parameter übergeben wurde. In dem Fall ist das deactivate() — unser Pseudo-Destruktor.

So weit so gut. Aber was jetzt?

Jetzt kommt noch ein kleiner, aber sehr entscheidender Teil: wir müssen unseren Konstruktor irgendwie aufrufen. Denn schließlich wollen wir ja unsere tollen Funktionen am System anmelden. Dazu fügen wir am Ende der Datei, direkt hinter der schließenden Klammer der ersten if–Abfrage, folgenden Quelltext ein:

if( class_exists( 'myPlugin' ) ) {
   $myPluginObject = new myPlugin();
}

if( isset( $myPluginObject ) ) {
   add_action( 'init', array( &$myPluginObject, 'activate' ) );
}

Was passiert hier noch? Eigentlich auch wieder nicht viel Aufregendes: wir instanziieren (super tolles Wort ), erstellen ein neues Objekt aus unserer Klasse. Damit ist ja bekanntlich der implizite Konstruktor-Aufruf verbunden. Somit sind wir am System mit unserem WordPress Plugin registriert.

Mit der nächsten Zeile setzen wir einen Hook auf ‘init’. Dieser Hook greift dann, wenn das WordPress System geladen wird. Tjoa … und dann können wir unser Plugin schön verwenden und erweitern. Das Einzigste was noch zu erledigen ist: die PHP-Datei muss in den Ordner wp-content/plugins

Wer hierzu noch spezielle Fragen hat, kann sich selbstverständlich bei mir melden. In diesem Sinne wünsche ich euch happy coding Doods

Update!

Ein Dank gilt Frank, der mich auf eine Kleinigkeit aufmerksam gemacht hat: oberhalb des Konstruktors war eine protected Variable namens myOptions definiert. Diese hat hier nichts verloren und wurde entfernt

Das Kleid macht nicht den Mann, der Sattel macht kein Pferd.

(Angelus Silesius, * 1642   † 1677)

WordPress Theme Splendio

So sprach er — A. Silesius, bürgerlicher Name Johannes Scheffler, war ein deutscher Lyriker und Theologe. Gemäß seiner Aussage könnte man in Bezug auf das Webdesign zwar denken, dass ein super toll aussehendes WordPress Theme noch lange kein super tollen WordPress Blog macht, aber ich gebe mein Bestes

Nachdem das alte Theme meines Blogs nun schon in die Jahre gekommen war, hier auch nochmal ein ganz großes Danke an Alex Oeser, der sein Hirnschmalz für mich gab, wurde es nun doch mal langsam Zeit ein neues “Kleid” anzuziehen.

Da ich momentan leider keine Zeit habe mich selbst um ein schönes Theme zu kümmern, war ich heute auf der Suche im www. Die Masse an Themes sind gewaltig. Da fällt die Auswahl schwer. Wer allerdings meine Arbeiten gesehen hat, weiß, dass ich total steil auf minimalistische WordPress Themes gehe. Von daher konnte ich schon einen Großteil des Angebots als Ausschuss betrachten.

Nachdem ich auf der Seite vom Smashing Magazine einen Eintrag “Free WordPress 3.1 Theme: Splendio (With PSD Sources)” gesehen habe, war ich begeistert. Ein Theme mit Pastellfarben und netten Plugins basierend auf HTML 5. Es kommt mit PSD Files und den empfohlenen Plugins (WP Featured Content Slider, Flickr RSS (hier deaktiviert) und WP PageNavi). Nach ein paar Anpassungen der Theme Files war es dann auch schon erledigt — es sieht aus, wie ich es gerne hätte. Super!

Aufruf

Wen du Interesse daran hast mir eventuell ein niedliches (minimalistisches!) WordPress Theme zu erstellen, lass dich nicht aufhalten. Die Credits sind dir natürlich sicher

Bildquelle: Design Disease, designdisease.com, Stand: 13.11.2011

Demonstration

Link zur Demo des jQuery ToolTip

Vorschau des jQuery ToolTip

Es ist hier im Artikel extrem basic gehalten und kann aber nach Wünschen relativ einfach umgestaltet werden. Das Resultat soll folgendermaßen aussehen:

Die HTML-Umsetzung

Um das ganze Problem relativ einfach zu halten, bedarf es nicht viel Quältext. Wir brauchen ein wenig Markup (HTML), etwas Schönheitskosmetik (CSS) und ein paar Werkzeuge (jQuery). Wir jetzt eine CSS-Datei oder das jQuery Framework eingebunden wird, lass ich an der Stelle mal weg. Wer es nicht weiß, kann gern nachfragen

Fangen wir mit dem HTML an. Dabei bedarf es im Grunde “nur” einer (horizontalen) Liste:

<ul class="tTipList hList">
<li class="relPos">
<a href="#" title="Tool Tip Nummer 1 Link">
<img src="http://dummyimage.com/70x35/000/fff.jpg" alt="Tool Tip Nummer 1" width="50" height="33" />
</a>
<span>Tool Tip #1 Inhalt</span>
</li>
<li class="relPos">
<a href="#" title="Tool Tip Nummer 2 Lnk">
<img src="http://dummyimage.com/70x35/000/fff.jpg" alt="Tool Tip Nummer 2" width="50" height="33" />
</a>
<span>Tool Tip #2 Inhalt</span>
</li>
<li class="relPos">
<a href="#" title="Tool Tip Nummer 3 Lnk">
<img src="http://dummyimage.com/70x35/000/fff.jpg" alt="Tool Tip Nummer 3" width="50" height="33" />
</a>
<span>Tool Tip #3 Inhalt</span>
</li>
<li class="relPos">
<a href="#" title="Tool Tip Nummer 4 Lnk">
<img src="http://dummyimage.com/70x35/000/fff.jpg" alt="Tool Tip Nummer 4" width="50" height="33" />
</a>
<span>Tool Tip #4 Inhalt</span>
</li>
</ul>

Hier gibt es eigentlich viel zu zu sagen. Es ist eine Liste mit der Klasse tTipList und die soll horizontal (hList) angeordnet werden.

Jedes Listenelement hat einen Link (welcher in dem Fall mal ein Bild ist). Nach diesem Link ist ein span–Bereich. Das ist der eigentliche ToolTip, welcher beim Drüberfahren angezeigt werden soll. Achtung: ich gehe hier von Bildern als Link aus — darauf beziehe ich mich auch gleich in dem jQuery ToolTip Quelltext.

Das CSS

Auch das ist bis auf ein paar allgemeine Klassen zur Formatierung sehr einfach gehalten:

body {font:13px/1.231 Helmet, Freesans, sans-serif}
img {border: 0}

.hList {margin: 0}
.hList li {display: inline-block; float: left}
.hList a {text-decoration: none}

.relPos {position: relative} /* !! Wichtig, sonst kann li.tTip nicht
daran ausgerichtet werden !! */

.tTipList {margin: 50px 0 0 100px}
.tTipList li {margin-left: 5px}
.tTip {
position: absolute; /* an li ausrichten */
left: 0; /* wird mittels jQuery ermittelt */
top: -35px;
display: none;
white-space: nowrap;
background: #fff; border: 1px solid #aaa;
padding: 5px;
-webkit-box-shadow: 1px 1px 5px 2px rgba(0, 0, 0, 0.4);
-moz-box-shadow: 1px 1px 5px 2px rgba(0, 0, 0, 0.4);
box-shadow: 1px 1px 5px 2px rgba(0, 0, 0, 0.4)
}

Auch hier ist keine Zauberei am Werk. Das einzigste was wichtig ist: die Listenelemente selbst müssen ein position: relative; erhalten, dass wir den ToolTip mit position: absolute; daran ausrichten können. Wir erinnern uns: position: absolute; richtet sich an dem ersten Element aus, welches nicht position: static; (Default-Wert) enthält!

So … fehlt ja nur noch der Feenstaub: das jQuery himself

jQuery ToolTip Plugin

( function( $ ) {
var tTipWrapper = $( 'ul.tTipList' );

tTipWrapper.children().each( function() {
var that = $( this ),
spanTag = that.find( 'span.tTip' ),
tTipW = spanTag.outerWidth( true ),
imgW = that.outerWidth( true ),
mLeft = that.css( 'marginLeft' ).replace( /px/, '' ),
left = Math.round( ( spanTag.outerWidth( true ) - imgW ) / 2 ),
setLeft = Math.round( left - (mLeft / 2) );

that.hover( function() {
spanTag.css( 'marginLeft', -setLeft );
spanTag.stop( true, false ).show( 400 );
that.siblings().stop().fadeTo( 400, 0.4 );
}, function() {
spanTag.stop( true, true ).hide( 0 );
that.siblings().stop().fadeTo( 400, 1, function() { that.siblings().css( 'filter', '' ); } );
} );
] );
} )( jQuery );

So, dröseln wir das mal etwas auf …

• (Zeile 2) wir suchen in unserer DOM-Struktur nach den Listen, bei denen dieser Effekt gewünscht ist
• (Zeile 4) bei jedem Listenelement (Kindelement von ul.tTipList) arbeiten wir folgendes ab:
• (Zeile 5) Caching des aktuellen Listenelements
• (Zeile 6) Suche nach dem span-Tag, welcher den Inhalt für den ToolTip enthält
• (Zeile 7) Breite des Textes samt margin–Angaben herausfiltern
• (Zeile Breite des Bildes cachen
• (Zeile 9) Hat das Listenelement ein margin-left, soll das gespeichert werden, da wir den ToolTip nach links ausrichten werden. Zu beachten ist hier, dass that.css( ‘marginLeft’ ) eine Angabe mit px zurückliefert. Wir brauchen allerdings nur den Wert selbst und schneiden px einfach ab.
• (Zeile 10) Differenz zwischen Tooltip– und Bildbreite berechnen, Ergebnis halbieren
• (Zeile 11) margin-left halbieren und von der Differenz abziehen (hier sollte mit Math.round() gerundet werden)
• (Zeile 13) bei mouseenter:
• (Zeile 14) setze ermittelte Position nach links (bedenke: position: absolute;)
• (Zeile 15) Animations Queue sofort beenden / leeren, weil sonst unschöne Effekte entstehen
• (Zeile 16) die anderen Elemente leicht ausblenden — nette Fokussteuerung
• (Zeile 17) bei mouseleave:
• (Zeile 18) ToolTip wieder verstecken
• (Zeile 19) und die anderen Elemente wieder einblenden

Und dann hätten wir es auch schon. Das hier ist selbstverständlich nur eine ziemliche Basic Version und man kann es schön weiter ausbauen. Ich wollte damit aber auch nur die Grundlagen legen. Viel Spaß beim testen und rumprobieren

Hinter CreateCom verbirgt sich das multimediale Unternehmen von Frank Lehmann aus Leipzig. CreateCom bietet Lösungen aus dem Bereich klassische sowie neue Medien.

Ich habe den Inhaber, Frank, vor ein paar Wochen kennengelernt. Nach einigen E-Mails und Telefonaten haben wir uns dazu beschlossen mal ein kleines Projekt zu starten — frei nach dem Slogan von CreateCom “Kontakte nutzen — Synergien bilden”. Hier haben wir uns relativ schnell und unkompliziert dazu entschieden, dass wir uns mal ein WordPress Template-Projekt zur Brust nehmen.

Dabei liefert CreateCom das Layout und ich gestalte das Layout als XHTML-Version sowie als WordPress Template. Eine Vorschau des Templates kannst du am Ende des Artikels einsehen.

Was kann das Template?

Das WordPress Template wird für den Anfang folgende Eigenschaften Besitzen:

• valider Quelltext nach XHTML 1.1
• CSS3 basierende Stylesheets mit Fallbacks für ältere Browser
• zwei frei definierbare Menüs unterhalb des Headers
• ein weiteres Menü im linken Footer-Bereich
• Abwärtskompatibilität bis zum Internet Explorer 6
• Aufbereitung der Seite mit Media Queries für Mobile Endgeräte
• Thumbnails für die Artikelausschnitte (Excerpts)
• Hierarchische Kommentarfunktion

Interesse bekommen?

Falls jemand Interesse an diesem Template bekommen hat, kann sich gern hier in den Kommentaren verewigen, oder sich per E-Mail direkt bei mir melden (look@webinfluenza.de). Die Entwicklung wird sicherlich noch ein paar Tage dauern, ist jetzt aber schon in einem verwendbaren Status.

Die Nachteile vorweg

Wie oben schon nebenbei erwähnt, sind Media Queries Bestandteil des CSS3. Aber halt … was sind Media Queries??

Media Queries — was ist das? Wozu dienen sie? Wann macht der Einsatz Sinn?

Media Queries sind logische Ausdrücke, die einem Webdesigner die Möglichkeit bieten, mehr Kontrolle über das Rendering-Verhalten eines bestimmten (mobilen) Gerätes zu “erlangen” (ähnlich den Conditional Comments / Browserweichen für bestimmte IE-Versionen). Logischer Ausdruck bedeutet, dass es nur wahr oder falsch als Ergebnis haben kann: trifft zu, oder nicht.

Damit ist möglich abzufragen, welche Eigenschaften bzw. Fähigkeiten ein (mobiles) Gerät besitzt. Beispielsweise ist hier die Bildschirmauflösung oder die Ausrichtung (Hoch– bzw. Querformat) gemeint.

Also haben wir hier die Möglichkeit konventionelle Internetseiten auf mobile Geräte wie Handy, Smartphone oder Tablet-Computer anzupassen. Auch hierbei ist wohl zu überlegen, ob sich dieser Aufwand generell lohnt. Die Zielgruppe ist entscheidend.

Wie geht’s denn überhaupt los?

Jeder der schon mal mit CSS gearbeitet hat, weiß wie man eine solche normale CSS-Datei einbinden kann:

<link rel="stylesheet" media="all" href="style.css" />

Somit wäre eine CSS-Datei namens style.css eingebunden, welche auf sämtliche Ausgabegeräte angewandt wird — media=“all”. Nun wollen wir zum Beispiel ein Stylesheet definieren, welches unsere Website für Smartphones aufbereitet bzw. abändert. Dazu definieren im:

<link rel="stylesheet" media="only screen and (min-device-width: 320px)
   and (max-device-width: 480px )" href="smartphone.css" />

Damit hätten wir ein Konstrukt, welches nur für Bildschirmanzeigen (screen) UND eine (Gerät-)Mindestbreite von 320 px UND eine (Gerät-)Maximalbreite von 480 px bestimmt ist. Wir rufen uns hier in Erinnerung: jeder dieser Ausdrücke muss wahr sein, dass diese CSS-Datei auch wirklich eingebunden wird. Sonst wird sie übergangen. Damit hätten wir unsere Grundlage für Smartphones.

Hier sei noch angemerkt, dass beides Ausrichtungen des Displays auf dem Smartphone dabei inbegriffen sind (horizontal / vertikal bzw. Landscape / Portrait).

Und dann? What’s next?

Jetzt kann die Schinderei beginnen. Wir haben unsere Grundlage, die CSS-Datei für die Smartphones gelegt.

Meiner Meinung nach sollte als erstes überdacht werden, wie man die Seite jetzt grundsätzlich strukturiert. Ist bisher ein drei-Spalten-Layout eingesetzt, sollte man sich überlegen, ob man das nicht abändert. Immer im Hinterkopf: wir prüfen auf eine Auflösung zwischen 320 px und 480 px. Ein relativ wichtiger Punkt sind hier auch Menüs. Hier auf Guardian Online befindet sich folgendes horizontales Menü:

Da könnte man beispielsweise ein schönes vertikal gerichtetes Menü draus basteln, und die einzelnen Menüpunkt untereinander setzen.

Der nächste Step sollten Bilder sein. Ist im Header ein schönes großes Bild von 980 px x 200 px (wie bei mir), dann geht es darum, dieses Bild zu verkleiner. Auch das Hintergrundbild muss eventuell angepasst werden. Das hängt aber von der jeweiligen Seite ab.

Das leidige Testen

… bleibt natürlich auch hier nicht erspart. Den größten Vorteil hat hier wohl der Multimedia-Junky, bzw. der, der sich glücklich schätzen darf und ein oder zwei Smartphones und ein iPad besitzt. Aber gibt auch Alternativen: online Tools, welche versuchen solchen mobilen Endgeräte zu simulieren. Leider kann man sich auf diese Ausgaben nicht 100% verlassen.

Hier eine kleine Auswahl an Seiten, die einem das Leben erleichtern können:

• Der W3C Eintrag zu Media Queries
• der iPhone Safari Browser — Entwicklerecke mit Hinweisen zur Optimierung
• ProtoFluid — online Tool zum Testen der Media Queries für verschiedene Geräte
• Hardboiled CSS3 — Media Queries für die gängisten mobilen Geräte

Damit sollte die Grundlage für die Erstellung einer optimierten Internetseite für mobile Endgeräte gelegt sein. Auf Guardian Online befindet sich bisher noch keine mobile Version — aus Zeitgründen. Ich bitte das zu entschuldigen

In diesem Sinne … happy coding

Nachteil bei der Verwendung von em: das Elternelement vererbt die Größenangabe nach unten (also an die Kindelemente) weiter. Beispiel:

<body style="font-size: 62.5%;">
   <div style="font-size: 1.4em;">
      <p>Paragraph 1</p>
      <p style="font-size: 1.2em;">Paragraph 2</p>
   </div>
</body>

Erläuterung / Problemstellung

Wir wissen, dass die Standardschriftgröße der meisten Browser auf 16px voreingestellt. Damit ist im body eine Schriftgröße 62.5% = 10px, im div–Element 10px x 1.4 = 14px und im zweiten p–Element 10px x 1.2 = 12px. Falsch!

Die Schriftgröße vom div-Element wird an das zweite p-Element mit durchgereicht. Das bedeutet dort ist keine Schriftgröße von 12px, sondern von 10 x 1.4 x 1.2 = 16,8px. Das kann ein Problem großes Problem bei komplexen Layouts werden. Bei absoluten Größenangabe passiert sowas nicht.

Die Alternative: Angabe mit rem

rem soll hierzu Abhilfe schaffen. Demnach soll rem (“root em”) sich grundsätzlich auf das oberste Root Element beziehen. Bezogen auf unsere Beispiel von oben würde dann die Rechnung aufgehen, dass das zweite p–Element tatsächlich eine Schriftgröße von 12px hätte, da das Root Element (hier: body) eine Größe von 62.5% (entspr. 10px) hätte -> 10 x 1.2 = 12px.

What’s the catch dude?

Bis hierhin eigentlich genial. Warum zum Murphy benutze ich das noch nicht?! Hmm … ich habe bis hier her einen wichtigen Punkt vergessen zu erwähnen: das gibt’s nur bei der Verwendung von CSS3.

Daraus ergibt sich wieder welche Problematik? Genau, damit ist die Cross Browser-Fähigkeit unserer tollen seite im … naja da, wo sie nicht hingehört

Der IE bis einschließlich Version 8 kann damit nicht viel anfangen. Der Opera angeblich auch nicht — bin leider noch nicht selbst zum Testen gekommen. Aber man kann ja eine Art Fallback bauen…

body {
   font-size: 62.5%;  /* entspr. 10px (meistens) */
}
div {
   font-size: 14px;   /* erstmal auf Nummer sicher gehen */
   font-size: 1.4rem; /* auf 14px */
}
div p:last-child {    /* Achtung: auch CSS3, fuer CSS 2 p.last verwenden */
   font-size: 12px;
   font-size: 1.2rem;
}

Damit kann sich der Browser aussuchen mit welcher Angabe er umgehen kann. Er greift sich erst die px–Angabe. Kennt er die rem–Einheit, nimmt er den diesen Wert und überschreibt die px–Angabe. Wie beim Militär: der letzte Befehl zählt

In diesem Sinne … happy coding

Manchmal ist es doch einfach zum verrückt werden. Da bietet CSS 2 schon viele schöne Features, aber die scheinbar trivialen Dinge sind nicht mit dabei. Beispiel: float bottom;.

Szenario: wir wollen auf einer Seite zwei div-Container so verschachteln, dass der äußere am unteren Rand “klebt”. Viele verzweifeln und versuchen das Problem vielleicht sogar mit JavaScript zu lösen. Dabei gibts einen einfacheren Weg, den ich euch jetzt aufzeigen will.

Ausgangslage

Wir haben eine Seite mit einem Wrapper, der die Seite komplett umschließt: #page_wrapper. Darin sind dann diverse Bereich wie Header, Menü, Sidebar, Hauptbereich und Footer enthalten. Am Ende des Hauptbereichs (#content) soll ein kleiner Bereich für Zusatzinformationen (#info; das gewünschte div float bottom) platziert werden.

Lösungsansatz für das div float bottom

Dazu schreiben wir jetzt folgenden code:

<div id="page_wrapper">
   <div id="content">
      <p>Ich habe viiiiiiiel Inhalt und bin sehr lang</p>

      <div id="info">
         <p>Zusatzinformationen</p>
      </div>
   </div>
</div>

Das entsprechende CSS um das Problem in den Griff zu bekommen:

* {
   padding: 0;
   margin: 0;
}

#page_wrapper {
   width: 980px;
   margin: 0 auto;
}

#content {
   width: 560px;
   height: 300px;
   background-color: #abcdef; /* zur visuellen Darstellung */
   position: relative;        /* (1.) */
}

#info {
   width: 300px;
   height: 50px;
   background-color: #fedcba;
   position: absolute; /* (2.) */
   bottom: 0px;        /* (3.) */
   right: 0px;         /* (4.) */
}

Damit “klebt” der info–div am unteren (rechten) Rand des content–Container. Wichtig hierbei ist die Positionierung der Elemente. Das Element, welches das klebende enthalten soll, muss relativ positioniert werden. Das Element, welches nach unten “floaten” (div float bottom) soll, muss absolut am relativ positionierten Element ausgerichtet werden. Dann kann man natürlich noch entscheiden, in welche Richtung es ausgerichtet werden soll.

Probleme (Peekaboo Bug) / Ausblick

Wird keine Höhenangabe der Elemente gemacht, und die äußeren Elemente haben keinen Inhalt, kann es zu Problemen kommen. Ein Ansatz wäre die min-height–Anweisung.

Eine Alternative ist, dass man einen Container mit der Eigenschaft clear: all; einbaut. Das Problem nennt sich auch “Peekaboo Bug” und ist gerade im IE6 anzutreffen.

Peekaboo Bug — Lösung

Man gibt dem Elternelement folgendes CSS mit:

* html #page_wrapper { height: 1%; }

Das sollte es gewesen sein

Hat man es jedoch beispielsweise mit landwirtschaftlichen Unternehmen auf ländlichen Gegenden zu tun, muss man durchaus mal damit rechnen, dass immer noch 10% — 15% der Besucher mit den Internet (H)Explorer 6 durch das WWW stolpern.

In diesem Fall sollte man sich mal mit der Browserweiche auseinandersetzen. Den Löwenanteil kann man über typische CSS Conditional Comments abfangen. Was aber, wenn das nicht mehr damit zu realisieren ist? Wie kann man noch ansetzen?

Problemstellung

In einem aktuellen Projekt erstelle ich einen News Blog. In dem Header sind (transparente) Social Icons im PNG-Format hinterlegt. Nun wissen wir ja, dass der IE 6 da echt zicken kann, weil der Alpha-Kanal fehlt. In der header.php sieht der Bereich folgendermaßen aus:

<div id="header_social">
   <p id="social_icons">
      <a href="<?php bloginfo( 'rss2_url' ); ?>" title="RSS Feed"><img src="<?php bloginfo( 'template_url' ); ?>/images/social_rss.png" alt="RSS Feed" /></a>
      <a href="http://www.twitter.com/benno_m_" title="... on Twitter"><img src="<?php bloginfo( 'template_url' ); ?>/images/social_twitter.png" alt="... on Twitter" /></a>
      <!-- ein paar Icons mehr //-->
   </p>
</div>

Die Grafiken haben wie gesagt einen transparent Hintergrund — der IE 6 stinkt hier etwas ab und stellt der Hintergrund einfach weiß dar.

Lösungsansatz

Da ich hier nur schwer mit CSS anetzen konnte, bin ich auf PHP umgeschwungen. Es wird der verwendete Browser vom User abgefragt und auf die Version getestet. Weiterhin habe ich im Bilderordner des Templates einen Unterordner angelegt, der die Grafiken enthält, welche statt transparentem Hintergrund eine farblich angepasste Hintergrundfarbe enthalten. Wir also der IE 6 verwendet, soll die Bilder aus diesem Ordner verwendet werden, sonst nicht.

Folgender Ansatz zur Implementierung einer Browserweiche:

<div id="header_social">
   <p id="social_icons">
<?php
      $browser = $_SERVER['HTTP_USER_AGENT'];

      if( preg_match( '=MSIE 6.0=i', $browser ) ) { /* Binde IE 6 Grafiken ein */
?>
         <a href="<?php bloginfo( 'rss2_url' ); ?>" title="RSS Feed"><img src="<?php bloginfo( 'template_url' ); ?>/images/ie6/social_rss.gif" alt="RSS Feed" /></a>
         <a href="http://www.twitter.com/benno_m_" title="... on Twitter"><img src="<?php bloginfo( 'template_url' ); ?>/images/ie6/social_twitter.gif" alt="... on Twitter" /></a>
<?php
      }

      else { /* Binde normale transparent Grafiken ein */
?>
         <a href="<?php bloginfo( 'rss2_url' ); ?>" title="RSS Feed"><img src="<?php bloginfo( 'template_url' ); ?>/images/social_rss.png" alt="RSS Feed" /></a>
         <a href="http://www.twitter.com/benno_m" title="... on Twitter"><img src="<?php bloginfo( 'template_url' ); ?>/images/social_twitter.png" alt="... on Twitter" /></a>
<?php
      }
?>

Die if–Abfrage prüft hier die Rückgabe der Browserinformationen und schaut ob irgendwo der Teilstring MSIE 6.0 vorhanden ist. Somit lässt sich relativ einfach eine Browserweiche über PHP basteln.

Alternativen / Probleme bei dieser Art von Browserweiche

Sicherlich ist die hier vorgestellte Lösung nicht die eleganteste. Das sollte sie auch nicht, sie sollte funktionieren Es gibt sicherlich 3.982, 53 andere Möglichkeiten das Problem zu lösen. Jedoch kam mir diese zuerst in den Sinn.

Weniger Schreibarbeit hätte man auch, wenn man die Abfrage jeweils in die a-Tags mit einbaut — z.B. über den ternären Operator von PHP. Ich habe darauf allerdings zum Verständnis hier darauf verzichtet. Meine entgültige Implementierung sieht dann noch etwas anders aus

*** Update ***

Mir ist durchaus klar, dass es diverse Hacks gibt, die dem IE Transparenzen beibringen können. Davon möchte ich hier allerdings Abstand nehmen, da mir die Einbindung einer weiteren JS Library für ein paar kleine Icons nicht sinnvoll erscheint. Darüber hinaus soll dieser Beitrag zum Nachdenken anregen — dazu, dass nicht bei jedem kleinen Problem eine extra JavaScript Bibo zum Einsatz kommt. Diese Bibos haben oftmals Nachteile, die den Designer einschränken — und Einschränkungen haben wir ja schon genug

Nur leider gibt’s noch ein Problem: die definierte Zielgruppe hat nach Analyse zu 18% den Internet Explorer 6 im Einsatz. Immer noch so viel. Okay, starten wir den mal … und machen ihn nach Begutachtung ganz schnell wieder zu — grauenvoll. Das Layout ist ziemlich zerschossen.

Dieses Szenario ist wohl vielen bekannt Oftmals sind die Eigenheiten der IE-Familie etwas nervig und man muss sich damit rumschlagen.

Nach und nach werde ich versuchen die bekanntesten Bugs im IE hier zu sammeln und zu erläutern sowie die gängisten Workarounds aufzuzeigen. Heute fangen wir mal mit dem Double Margin-Problem an.

Nehmen wir mal an, wir haben zwei nette kleine Container, die nebeneinander angeordnet werden sollen.

#left_wrapper, #right_wrapper {
   width: 300px;
   float: left;
   height: 120px;
   margin-left: 10px;
}

Ganz simples Beispiel sollte man denken. Aber der IE 6 zeigt selbst bei diesem Beispiel schon ein erschreckendes Ergebnis: der Abstand nach Links ist doppelt so groß wie er sein sollte — nämlich 20 Pixel. Warum?

Grund

Wird ein Element mit der CSS-Eigenschaft float ausgezeichnet, sollte durch den Browser automatisch die display–Eigenschaft auf inline gesetzt werden. Das geschieht allerdings beim IE 6 nicht. Allerdings tritt dieses Verhalten nur auf, wenn die float–Richtung und margin–Angabe in die gleiche Richtung gesetzt werden (wie hier: links).

Workaround / Lösung

Die Lösung ist relativ einfach: das entsprechende Element mit der float–Angabe bekommt zusätzlich die Eigenschaft:

display: inline;

Anbei noch eine Datei, die diesen Bug demonstriert…

IE 6 Doube Margin

Weiterführende Hilfe

Du hast trotzallem Probleme bei der Darstellung? Poste einfach einen Kommentar und hinterlass’ deine E-Mail, dann versuchen wir das zu beheben

Mehr dazu:

WordPress 3.1 Release Candidate 3 is now available. After careful evaluation of the 3.1 features in RC2, we recognized the need to make some adjustments. There are some significant differences from previous versions of 3.1, so please review the changes if you have been developing against a beta or RC version.

The biggest change is the removal of AJAX list tables, which had been an effort to move all of our list-style screens to full AJAX for pagination, searches, and column sorts, and to consolidate the list-style screens into a single API that plugins could leverage. Unfortunately, with more testing came realizations that there were too many major bugs and usability issues with how the functionality was implemented, so we’ve spent the last week rolling back the most important portions of the feature.

Quelle: http://wordpress.org

Ich bin gespannt wie es wird und hoffe, dass ich mal die Zeit finde um das anzutesten

**UPDATE**

Genau einen Monat später ist die offizielle Version WordPress 3.1 mit dem Codename “Reinhardt” erschienen. Originalartikel “WordPress 3.1, lots of fun”.