Kategorien
Frontend: HTML5, CSS3, jQuery Webstandards

Brotkrumen-Navigation als ineinander verschachtelte Listen?

(Screenshot) Webkrauts: Doppelt gewinkelte Klammer zu?

Maik Wagner schreibt im heutigen Webkrauts-Türchen „Doppelt gewinkelte Klammer zu“ über die Aussprache von Zeichen wie », → oder > in Screen-Readern und welche davon unbenklich für Brotkrummen-Navigationen verwendet werden können. (Puh, langer Satz.)

Am Ende des Artikels schreibt er, und da gebe ich ihm recht:

Grundsätzlich sollten Breadcrumb-Navigationen immer als Liste ausgezeichnet sein, hierbei eignet sich eine geordnete Liste besser als eine ungeordnete, denn über die CSS-Formatierung kann die Nummerierung ausgeblendet werden, die der Screenreader trotzdem vorliest.

Dabei kam mir folgender Gedanke: Müsste eine Brotkrummen-Navigation nicht eigentlich aus ineinander verschachtelten Listen bestehen um die Tiefe auch semantisch aufzugreifen? In Hauptnavigationen macht man das doch auch so, wenn eine Ebene mit Unterpunkten geöffnet ist.

<ul class="breadcrumb">
<li><a href="">Werners Elektro-Shop</a>
<ul>
<li><a href="">Produkte</a>
<ul>
<li><a href="">Lötkolben</a></li>
</ul>
</li>
</ul>
</li>
</ul>

Schließlich sind die verschiedenen Ebenen miteinander verknüpft und eine ist jeweils die Tochter der anderen, macht also durchaus Sinn, ist aber wahrscheinlich schon wieder zuviel des Guten.

Wenn die Brotkrummen-Navigation nicht aus zu vielen Unterpunkten besteht – was aber meistens nicht der Fall ist -, besteht doch sogar die Möglichkeit, denen, die sich die Website vorlesen lassen, Zusatzinformationen zukommen zu lassen:

<ul class="breadcrumb">
<li><a href="">Werners Elektrop-Shop</a>
<ul>
<li>Hauptkategorie: <a href="">Produkte</a>
<ul>
<li>Unterkategorie: <a href="">Lotkolben</a></li>
</ul>
</li>
</ul>
</li>
</ul>

Diese Zusatzinformationen kann man noch in ein <span>-Element einwickeln, um sie für die Bildschirm-Anzeige zu verstecken. Nicht unbedingt mit display: none;, sonst werden sie gar nicht erst vorgelesen, aber mit dem allseits bekannten text-indent: -9999px; sollte es klappen. Habe ich allerdings nicht getestet.

Wahrscheinlich ist das wieder zuviel des Guten und es reicht, eine Brotkrummen-Navigation als geordnete Liste auszuzeichnen und die Nummerierung auszublenden. (list-style-type: none;) Was meint ihr? $-ility-Experten im Haus?

Kategorien
Frontend: HTML5, CSS3, jQuery Webstandards

„Man kann Tabellen layouten aber nicht mit Tabellen layouten.“

Kategorien
Frontend: HTML5, CSS3, jQuery Webstandards

Bilder zentrieren mit CSS und jQuery

Ich saß heute am neuen Layout und wollte die Bilder, die in den Artikeln auftauchen, mittig ausrichten. Ausnahmen sind Bilder mit den Klassen .alignleft und .alignright.

Gut, dachte ich mir, versuchste es mal mit text-align: center; aber Pustekuchen. Nach ein wenig Recherche schien mir die einzig brauchbare Möglichkeit zu sein, den entsprechenden Bildern ein neues Elternelement zu verpassen, beispielsweise ein <div> oder ein <span> und dessen Inhalt (also auch das Bild) zentriert darzustellen. Da ich 1.) nicht in den Textpattern-Dateien rumwuseln wollte und 2.) das Extra-Markup nicht ins HTML gehört, hab ich mich für die JavaScript-Methode entschieden und dabei jQuery ausprobiert.

Meine Erfahrungen mit JavaScript (oder ECMAScript) sind seit jeher gering, da ich es bisher nicht gebraucht habe und ich immer an Icons die den Mauszeiger verfolgen und sonstige Spielereien denken musste, die ich schon immer fragwürdig hielt.

Der jQuery-Code, den ich dafür nutze, sieht folgendermaßen aus:

$(document).ready(function(){
$(".entry-content img[class!=alignleft][class!=alignright]").wrap("<span class=\"imgbox\"></span>");
});

Es macht nichts anderes als nach dem Laden des Dokuments allen Bildern, die in einem Element mit der Klasse .entry-content enthalten sind, ein <span>-Element mit der Klasse .imgbox drumherum zu verpassen. Eine Ausnahme bilden wie schon gesagt Bilder mit den den Klassen .alignright/left, die bekommen kein <span>.
(.entry-content stammt übrigens aus dem hAtom-Mikroformat, über das ich schon mal geschrieben habe.)

In HTML übersetzt (vereinfacht:

<img src="bildname.jpg" />

wird zu

<span class="imgbox"><img src="bildname.jpg" /></a>

Das CSS sieht so aus:

.imgbox {
text-align: center;
display: block;
}

.entry-content img {
border: 1px solid #CACACA;
background: #FFF;
padding: 5px 5px 5px 5px;
text-align: center;
}

Das <span>-Element wird zu einem Block-Element und bekommt dadurch die komplette Breite des .entry-content. Mittels text-align: center; wird jeglicher Inhalt in dieser Box zentriert, so auch das enthaltende Bild. Dieses besitzt noch die ganzen anderen Standard-Formatierungen erhält wie einen Rahmen, Hintergrundfarbe und einen Innenabstand. Und so sieht das dann aus:

Screenshot eines mittels jQuery-Hilfe zentrierten Bildes

Kategorien
Browser Frontend: HTML5, CSS3, jQuery Webstandards

Mein IE6, die absolut positionierten Listenelemente mit Links und ich

Der IE6 hat ein Problem mit display: block;-Links in absolut positionierten (Listen-)Elementen. Wenn man dem Link keinen Hintergrund zuweist, ist der Link zwar da, kann aber nicht per Drüberfahren erkannt und demnach auch nicht angeklickt werden. Tabbt man sich durchs Dokument, landet man auch beim Link, aber anvisieren mit dem Mauszeiger? No go.

Auch eine Höhen- und Breitenangabe half nicht, einzig und allein ein background: url(leer.gif); half, um den Dämon auszutreiben.

Wieso man Links überhaupt mal absolut positioniert? Nun ja, damit kann man ganz nett eine Imagemap zusammenschustern, das @map@-Element mochte ich noch nie, auch wenn es in XHTML 1 noch existiert.

Kategorien
Frontend: HTML5, CSS3, jQuery Webstandards

Suchergebisse falsch präsentieren

Fernab der Sonnenseiten gibts auch Beispiele für schlecht gelöstes im Web:

Die Suchfunktion des Landes NRW zeigt: Suchergebnisse sollten den Titel einer Seite anzeigen, nicht dessen Dateinamen. Oder könnt ihr mit 071219MAGS.php etwas anfangen?

Kategorien
Frontend: HTML5, CSS3, jQuery Webstandards

CSS-Grids – lieber ohne Framework

Zurzeit wird ja groß und breit über Grid-Frameworks und ihre Nachteile/Vorteile gesprochen. Die Methode Grids/Raster zu verwenden halte ich für gut, gerade um Ordnung und Gestalt auf die Seite zu bringen. Die technischen Ansätze der Grid-Frameworks sind mir aber teilweise zuwider, da hier teilweise sehr in den HTML-Quelltext eingegriffen werden muss.

Man schaue sich nur mal das Beispiel des 960.gs-Frameworks an:

Klassen-Zuweisungen wie container_12, grid_7 prefix_1 und grid_2 alpha sprechen nicht gerade von Semantik und sind arg präsentations-bezogen. Aber genau das wollten wir doch alle vermeiden und semantische Klassennamen wie .sidebar/.aside, .legal oder .error verwenden. (Wobei man die ersteren auch als ID-Attribut verwenden kann.)

Was ich am 960.gs-Framework allerdings gut finde ist, dass Vorlagen für Photoshop und Co. mitgeliefert werden.

Minifazit: Es ist okay, bei der Webgestaltung auf Grids/Raster zu setzen, allerdings sollte man dabei nur bedingt auf Frameworks zurückgreifen und lieber eigene Lösungen entwickeln, um einen Gridaufbau sicherzustellen.

Und das sagen andere:

Kategorien
Frontend: HTML5, CSS3, jQuery Webstandards

Bessere Captchas

Captchas sind sowas von nervig. Das Ausfüllen dauert eine gefühlte Ewigkeit und ob Klein- und Großschreibung egal ist, ist auch nicht immer ersichtlich.

Wieso sind Captchas nicht so aufgebaut:

Benutzerfreundliches Captcha

Statt den Text einzugeben klickt man einfach eine (die richtige) von vier Möglichkeiten an, fertig. Meiner Meinung nach viel schneller, weniger penetrant und vor allem komfortabler. Wahrscheinlich sogar noch ein Stück barriefreier.

Das Captcha stammt von plindberg.

Kategorien
Frontend: HTML5, CSS3, jQuery Netzwelt Webstandards

Ergebnisse der Webworker-Umfrage der Webkrauts

Die Ergebnisse zur Webworker-Umfrage der Webkrauts sind da. (Als hättet ihr es nicht schon längst mitbekommen ;))