Peter Kröner, Webdesigner & Frontendentwickler - Weblog und Portfolio von Peter Kröner, einem Webdesigner und Frontendentwickler aus Westerkappeln bei Osnabrück.

Das in HTML5 eingeführte Search-Input (<input type="search">) ist im Prinzip ein Formularelement, das sich nur durch sein Aussehen von einem normalen Textfeld unterscheidet:

Webkit-Browser sind bei der Implementierung von Search-Inputs Vorreiter und haben die bemerkenswerte Eigenschaft, überhaupt gar kein Styling von Suchfeldern zuzulassen! Das folgende CSS resultiert nicht in einem Eingabefeld mit rotem Rahmen:

input[type=search]{
    border:2px solid red;
}

Francesco Schwarz hat nun herausgefunden, wie man diese Blockade lösen kann. Die CSS3-Eigenschaft appearance (Spezifikationen, Artikel) ermöglicht es, HTML-Elemente wie Teile des System-Interfaces zu gestalten oder eben eine solche Gestaltung auch aufzuheben. Um also ein Suchfeld mit rotem Rahmen zu versehen, muss man (zumindest bei Webkit-Browsern) appearance zurücksetzen:

input[type=search]{
    appearance:none;
    border:2px solid red;
}

Dieser Reset funktioniert zwar auch nicht perfekt (das Lupen-Icon bleibt erhalten) aber immerhin kann man so zumindest ein wenig eigenes Styling unterbringen. Aber es bleibt die Frage, warum sich überhaupt diese Mühe machen sollte.

Meiner Interpretation nach ist das Search-Input im Prinzip ein Präsentationselement wie <font> und <blink>. Einerseits kann ich schon nachvollziehen, was mit dem Element erreicht werden soll – Web- und Systeminterfaces zusammenzuführen ist ein hehres Ziel. Aber sind nicht eigentlich Gestaltungsfragen der Job von CSS? Wäre nicht so ein Suchfeld-Wie-Im-OS-Styling genau das, wofür es appearance gibt? Den Webkit-Entwicklern kann man aus dem absonderlichen Styling-Verhalten des Search-Inputs auch keinen Strick drehen, da es nicht so aussieht, als sei irgendwo genauer spezifiziert, wie genau sich denn das Element verhalten soll. Die ganz am Anfang des Artikels zitierte Passage ist alles, was die HTML5-Spezifikationen zum Search-Input zu sagen haben.

Und so bin ich bin bisher noch kein Fan von <input type="search"> geworden. Schwammig spezifizierte Präsentationselemente sollten eigentlich den HTML-Friedhof bevölkern und nicht in HTML5 herumgeistern.

Ergänzung: Eric Eggert zwitscherte mir gerade, dass man bei Apple mit dem Search-Input tatsächlich sogar noch mehr macht als den Style zu verbiegen. Eine Reihe von zusätzlichen HTML-Attributen rüstet Funktionen aus den Suchboxen des Mac-Betriebssystems nach, was dem Search-Input durchaus Sinn verleiht. An der Kritik an den HTML5-Spezifikationen ändert der Alleingang eines Browserherstellers (mag er noch so sinnstiftend sein) aber natürlich nichts.

Ich habe ja eigentlich dem IE6 abgeschworen und halte das bisher auch gegen erbitterten Widerstand von allen möglichen Seiten durch, aber dieser eine Hack ist einfach zu genial um ihn nicht zu bloggen. Für mich ist er eine unterhaltsame Kuriosität, aber vielleicht hilft es ja dem einen oder anderen noch-IE6-Unterstützer auch mal wirklich – insbesondere wenn besagte IE6-Unterstützer HTML5 verwenden wollen.

HTML5 belebt, wie wir alle wissen, das <hr>-Element wieder. Es dient nicht mehr horizontaler Trennstrich, sondern markiert thematische Umbrüche in Texten – für Szenenwechsel innerhalb eines Kapitels in einer Geschichte zum Beispiel. Diese neue Rolle ändert freilich nichts daran, dass Browser das Element immer noch als horizontalen Strich anzeigen, was in den neueren Versionen aller Browser auch kein Problem darstellt. Entweder will man das <hr>-Element gar nicht mehr sehen und schafft es mit display:none; aus der sichtbaren Welt oder man entfernt seinen Rahmen mit border:none;. Das ist besonders dann sinnvoll, wenn man es als Container für ein dekoratives Hintergrundbild einsetzen möchte, ähnlich wie die Trenner mit Zweig in meinem Blogdesign. Das Problem: Da macht der IE6 nicht mit, border:none; bewirkt in ihm bei <hr>-Elementen rein gar nichts.

Wenn der Hintergrund einfarbig ist, lässt sich das Problem dadurch lösen, dass man im IE6 color für die <hr> auf den Wert der Hintergrundfarbe setzt, denn im IE6 ist offenbar border-color nicht für Rahmenfarben zuständig. Wenn man allerdings keinen einfarbigen Hintergrund hat, nützt das freilich nichts mehr. Also macht man das Folgende:

hr {
	display: list-item;
	list-style: url(hintergrund.png) inside;
	height: 48px;
	filter: alpha(opacity=0);
}

Ja, der IE6 unterstützt display:list-item; und list-style die man durch kreativen Mißbrauch ganz wunderbar instrumentalisieren kann. Einfach das Hintergrundbild als Bulletpoint einsetzen und das ganze Element via Alpha-Filter unsichtbar machen. Liegt ja auch ganz nahe, sowas. Respekt an den Autoren dieses Hacks, dessen Blogpost ich beim googlen zu einem ganz anderen Thema gefunden habe.

Eine Frage, die mich in letzter Zeit öfter mal via E-Mail und Blog-Kommentar erreicht hat, ist die nach dem Sinn der browserspezifischen CSS-Präfixe wie bei -moz-box-shadow und -webkit-border-radius. Die Antwort auf die Frage wieso bauen die das nicht gleich richtig ein? ist recht einfach: Die CSS-Eigenschaften sind in 90% aller Fälle Work-In-Progress-Varianten der richtigen CSS3-Eigenschaften. Der CSS2.1-Standard schreibt vor: wenn etwas zwar teilweise, aber nicht vollständig implementiert ist, soll man als verantwortungsvoller Browsermacher das Prefix davorkleben um anzuzeigen: das ist noch nicht die richtige Implementierung, sondern (erst mal) nur unsere Implementierung.

Besonders anschaulich wird das am Beispiel von border-top-left-radius. Bei Webkit-Browsern rundet man die obere linke Ecke einer Box wie folgt ab:

-webkit-border-top-left-radius:10px;

Bei Firefox geht das hingegen wie folgt:

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

Da ist nicht nur das Präfix unterschiedlich, sondern gleich der ganze Name der CSS-Eigenschaft – da steht also noch einige Arbeit für Webkit- und Gecko-Entwickler an. Aber sobald die Implementierung standardkonform umgesetzt ist, fliegt das Präfix raus. So ist es jüngst beim Firefox 3.5 geschehen, wo man schon vor einiger Zeit opacity korrekt umgesetzt hatte und dafür nun das alte -moz-opacity rausgeworfen hat.

Die restlichen 10% der CSS-Präfixe entfallen auf echte proprietäre CSS-Eigenschaften wie das -ms-filter des IE8. Mehr Infos zu CSS-Präfixen bzw. vendor specific CSS extensions gibt es in diesem feinen Artikel nebst weiterführenden Links von Bobby van der Sluis (via Guymon).

Ein Design wie das meines Blogs sind praktisch kaum mit flexibler Breite umtzusetzen. Die diversen Schatteneffekte würden es nötig machen, an allen Kanten und Ecken von Boxen mehrere Einzelgrafiken einzusetzen – das geht, ist aber mühsam, unwartbar und schadet der Performance. Eine Lösung hierfür kündigt sich mit der CSS3-Eigenschaft box-shadow an. Die Vorstellung dieses feinen Stücks CSS-Technik ist ein neuer Teil für die Serie schönes neues CSS, deren andere Teile ich an dieser Stelle auch nochmal empfehlen möchte:

• Textschatten mit CSS
• Alternative Farbangaben
• Über font-size-adjust
• Der General Sibling Combinator
• Die Appearance-Eigenschaft
• CSS-Transforms
• Die Rückkehr der Tabellen
• Box-sizing

Kompletten Artikel lesen