Unter Debian kann man sich die entsprechende Library und die PHP-Bindings aus dem momentanen unstable-Trunk besorgen: http://packages.debian.org/de/sid/libssh2-php

<link href="mystyle.css" rel="stylesheet" type="text/css" />

<style type="text/css">
   h1 { text-align: center }
</style>

Was kaum jemand weiß: Diese Angabe ist auch für Inline-CSS nötig. Also für CSS-Angaben, die man (X)HTML-Elementen über das style-Attribut zuweist. HTML 4 und damit auch XHTML 1 definieren zwar text/css als Default, wenn keine andere Stylesprache angegeben wird, führen diese Definition aber nur als Notfall ein. Die explizite Angabe der Stylesprache ist dennoch vorgeschrieben.

Mann kann sie entweder in einem Content-Style-Type-HTTP-Header oder im head des Dokumentes mit einem meta-Element angeben:

<meta http-equiv="Content-Style-Type" content="text/css" />

-moz-border-radius: 10px;
-webkit-border-radius: 10px;

Obwohl diese Angaben kein wirklich valides CSS 2.1 sind, bewegt man sich wenigstens im Rahmen der CSS-2.1-Spezifikation des W3C. Offensichtlicher Nachteil ist allerdings, dass die Angaben nur in Mozilla- und Webkit-basierenden Browsern funktionieren. Wem das – so wie mir – nichts ausmacht, hat so die einfachste Lösung.

Für alle anderen Browsern hat jeder seine „eigene“ Methode, die abgerundeten Ecken mit eingefügten Bildern zu realisieren. Mir gefallen alle diese Lösungen nicht besonders. Man nimmt mit ihnen semantisch nutzloses HTML in Kauf und vermischt nebenbei Inhalt und Präsentation, obwohl das Paradigma hinter HTML und CSS das eigentlich vermeiden will.

Die beste aller dieser Lösungen ist meiner Meinung nach diese:

.roundedCorners
{
    position: relative;
    padding: 10px;
}

.topLeftCorner
{
    display: block;
    position: absolute;
    top: 0;
    left: 0;
    height: 10px;
    width: 10px;
    background: url(topLeftCorner.png);
}

<div class="roundedCorners">
    <span class="topLeftCorner"></span>
    <span class="topRightCorner"></span>
    <span class="bottomLeftCorner"></span>
    <span class="bottomRightCorner"></span>
</div>

Analog zu .topLeftCorner kann man alle weiteren Ecken mit top, bottom, left und right positionieren.

Die <span>-Elemente verursachen die geringste semantische Verwirrung, wie leere Bilder oder leere Blöcke, die bei bestimmten Browserkonfigurationen sichtbar werden könnten.

Aber elegant ist es trotzdem nicht.

Dabei scheint es mittlerweile Konsens geworden zu sein, die Schrift des Fließtextes mit font-size: 0.8em zu formatieren; also in 80% Größe des beim User voreingestellten Wertes. Relative Schriftgrößen gelten als benutzerfreundlicher, da sie mit den Einstellungen des User skalieren.

Aber gerade deswegen ist 0.8em für den Fließtext in diesem Zusammenhang Unsinn. 1.0em ist die vom User eingestellte Größe, die er für Fließtext optimal empfindet. Die Skalierung auf 0.8em ist damit vom Prinzip her immer eine Verschlechterung.

Motiviert wurde 0.8em durch die Standardeinstellungen in den meisten Browsern, die 12pt und eine Serifenschriftart vorschlagen. Web-Entwickler wünschen sich oft eine serifenlose Schriftart und eine Schriftgröße von 10pt. Davon ausgehend, dass der User seine Standardeinstellungen nicht ändert, skalieren sie die 12pt mit 0.8em runter. Wenn der User seine Einstellungen aber selbst schon auf einer kleinere Schrift angepasst hat – so wie ich z.B. – wird der Text im Endergebnis viel kleiner als erwünscht.

Die Lösung ist eigentlich simpel: Absolute Angaben mit px verwenden. Alle verbreiteten Browser skalieren seit Jahren auch px-Größen, wenn der User es verlangt. Letzendlich drückt nur die px-Angabe das aus, was der Entwickler wirklich mit seinem CSS vorschlagen – denn CSS-Styles sind immer nur Vorschläge, und können vom User letzendlich immer überschrieben werden – will. 0.8em für den Fließtext hingegen ist ein Hack mit Stolperdraht.

Für Schriftgrößen, die tatsächlich in Relation zum Fließtext definiert werden sollen, ist em natürlich auch weiterhin eine sinnvolle Einheit. Beispiele wären z.B. Überschriften oder Fußnoten und Metainformationen.

Prinzipiell ist es optimal, die Schriftgröße des Fließtextes gar nicht zu ändern.

Update

Ok, der Internet Explorer skaliert nicht wirklich px-Schriften. Er skaliert sie nur, wenn man die ganze Seite mit der Zoom-Funktion vergrößert. Was allerdings bei der Benutzung des Internet Explorer die prominente Vergrößerungsfunktionalität ist und deswegen IMO den Sachverhalt nicht wirklich ändert.

Wenigstens habe ich zu Hause ein Backup.