CSS & HTML-Tutorials auf nicogutmann.de http://tuts.nicogutmann.de Ein weiteres tolles WordPress-Blog Sun, 27 Jun 2010 21:47:18 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Ordnung und Stetigkeit http://tuts.nicogutmann.de/2009/11/04/ordnung-und-stetigkeit/ http://tuts.nicogutmann.de/2009/11/04/ordnung-und-stetigkeit/#comments Wed, 04 Nov 2009 16:53:50 +0000 admin http://tuts.nicogutmann.de/?p=182 Vor allem CSS-Dateien sind oft recht groß und werden schnell unübersichtlich. Farbliche Akzentuierungen, unterschiedliche Schriftgrößen, etc sind in so einer Textbasierten Datei nicht möglich. Trotzdem kann man und sollte man dieses Chaos wenigstens ein Stück weit beseitigen, das erspart einem selbst eine Menge Zeit und auch den Betrachtern deiner CSS-Dateien (Bei Fehlersuche, bei Kopieren von Passagen) und ist ziemlich simpel umzusetzen.

Es fängt am Anfang an

Bereits ganz oben in einer CSS-Datei ist es wichtig einige Dinge zu definieren, hinzuschreiben. Was ihr genau hinschreibt, ist euch überlassen, aber zumindest der Name der Website, das Erstellungsdatum und die Farben sollten dort ihren Platz finden:

/*
/////////////////////////////////Name des Dokumentes: "screen.css"Erstellt von: "Nico Gutmann"
Erstellt für: "tuts.nicogutmann.de"
Erstellungsdatum: "06.08.2009"
Letzte Ąnderung: "03.11.2009"Farben:
----------------
blau: #054c98
lila: #8a24ac
rot: #bf2304
grün: #359721/////////////////////////////////
*/

Das ist mein Kopfbereich, der genügt mir persönlich sehr und die wichtigsten Aspekte wurden aufgegriffen.

Kommentiert alles mögliche

Kommentare sind elementar für die Grundordnung einer CSS-Datei. Dabei solltest du klare Abtrennungen machen und ähnlich bei einem Text mit Teilüberschriften arbeiten.
Da es nicht möglich ist, Schriftgrößen zu verändern oder auch farbliche Akzente zu setzen, muss das auch andere Weise geschehen. Auch hier ist die finale Exekution dir überlassen, ich arbeite gerne mit Querstrichen und Trennstrichen:

/* /////////////////////// Allgemeines /////////////////////// */html,body {
   height: 100%;
}/* /////////////////////// Wrapper & Kopf /////////////////////// *//* Umhuellendes Div
-------------------------*/#seite {
   width: 100%;
   min-width: 800px;
   max-width: 960px;
   min-height: 100%;
   height: auto !important;
   height: 100%;
   margin: 0 auto;
   position: relative;
   font-size: 80%
}

Einrücken bei den Kindern

So hast du bereits eine ganz gute Ordnung in deinem Stylesheet. Um den Deckel draufzumachen, kannst du noch mit inrückungen dort arbeiten, wo du mit Kindselektoren arbeitest. Bei einem Menu dann beispielsweise die Definition für die einzelnen Menupunkten von dem Menuobjekt einrücken:

/* /////////////////////// Navigation /////////////////////// */ul#navi {
   background: url(imgs/header.png) no-repeat;
   margin: -50px 0 10px;
   padding: 145px 0 0 0;
   border-bottom: 1px solid #000;
   overflow: hidden;
   height: 36px;
   width: 100%;
}    #navi li {
      float: left;
      width: 25%;
      height: 36px;
      line-height: 37px;
      text-align: center
   }       #navi a {
         color: #555;
         display: block;
         width: 100%;
         text-decoration: none
      }

Stetigkeit in den Namen

Neben den strukurellen Aspekten darf die Namensgebung einzelner Klassen, IDs und Bereiche nicht unterschätzt werden. Such dir sinnvolle Namen aus und bleibe bei allen Projekten bei diesen.
Das umhüllende Element einer Seite wird gerne #wrapper genannnt, ich nenne es #seite, bei all meinen aktuellen Projekten. Die Navigation natürlich dann #navi und den unteren Teil #site-info. Dabei ist es wichtig diese Namen beizubehalten, damit ihr ersten immer genau wisst, wobei es sich handelt, wenn ihr auf eure CSS-Dateien nach längerer Zeit wieder zugreifen müsst und ihr könnt euch Teile eurs HTML-Markups und des CSS kopieren und ohne Änderungen in ein neues Projekt einbinden, was viel Zeit sparen kann.

Mehrere CSS-Dateien

Bei großen Projekten (diese Website zähle ich nicht dazu) ist es auch durchaus sinnvoll seine Stile auf mehrere CSS-Dateien auszulagern, denn nach einer bestimmten Länge findet man einfach nichts mehr, auch wenn man seine CSS-Datei noch so gut auskommentiert hat.
Dabei ist es natürlich jedem frei und auch ab und an projektabhängig, wie man diese Dateien auslagert und benennt. Ich persönlich finde eine sinnvolle Separation in 3 Dateien sinnvoll: layout.css, inhalt.css und menus.css.

Dabei kommen alle Eigenschaften, die das Layout betreffen in die layout.css Datei, dazu gehören dann die Eigenschaften, die das Layout ohne konkrete Inhalte definieren, wie Seitengröße, Kopfbereich, Site-Info und die Positionierung der Objekte.
Die inhalt.css-Datei erklärt sich von selbst und da bei größeren Projekten oft viele Menupunkte die Website beherrschen, gibt man dem Menu/den Menus auch noch eine eigene Datei.

Das ist natürlich eine subjektive Anordnung, es gibt auch einige, der ihre Stile komplett nach Eigenschaften separieren. Da kommen dann alle Positionierungen in eine Datei, alle Schriftdefinitionen, alle Abstände, etc. Davon halte ich persönlich nicht viel, da wird man doch bekloppt.

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/11/04/ordnung-und-stetigkeit/feed/ 0 “Valid XHTML” und A- A A+ – Weg damit! http://tuts.nicogutmann.de/2009/11/02/valid-xhtml-und-a-a-a-weg-damit/ http://tuts.nicogutmann.de/2009/11/02/valid-xhtml-und-a-a-a-weg-damit/#comments Mon, 02 Nov 2009 14:48:34 +0000 admin http://tuts.nicogutmann.de/?p=167 Webseiten sollen nach den Webstandards geschrieben werden. Barriefreiheit ist seit einigen Jahren ein immer verbreiterter Schlachtruf, den vor allem große Websites mittlerweile gerecht werden wollen. Das muss natürlich auch nach außen kommuniziert werden, damit jeder sieht wie gut sie sich doch damit auskennen und, dass sie nun auch “barrierefrei” sind. Dazu gehören nicht nur die “Valid HTML”-Buttons, denn das reicht heutzutage schon lange nicht mehr.

Valid-Buttons

Fangen wir aber damit auch einmal an, mit den schönn Buttons und Links, die zur Validator verlinkt werden, um zu demonstrieren, dass sie valides, sprich fehlerfreies, (X)HTML geschrieben haben.
Das ist schon sehr löblich und ist der erste Schritt zu einer gut geschriebenen Website, mehr aber auch nicht.

  • Es sagt nichts über die Semantik des HTML-Markups aus. Es sagt nur, dass keine Syntax-Fehler (Vergessen ein Tag wieder zu schließen, etc) im Code sind.
  • Ein User, der sich nicht mit Webdesign auskennt, kann damit nichts anfangen. Wer sich damit auskennt und interessiert daran ist, kontrolliert selbst.
  • Oft werden zwar die Buttons eingebunden, doch der Validator meckert dann trotzdem. Sehr peinlich.
  • Wer Seiten mit einem CMS konfiguriert hat und Inhalte nicht selbst verwaltet, sondern ein ahnungsloser Kunde, kann die Fehler nicht vermeiden und diese können sich schnell einschleichen (Ergebnis: Validator meckert).

Dieselben Argumente gelten natürlich auch für den CSS-Button, nur, dass es dort viel leichter ist, dass es valide wird.

Optimized for Internet Explorer 6, Auflösung:…

Ein Glück ist dieser Satz, den sicherlich jeder kennt, aus den meisten Websits verschwunden. Mit Recht, mit Recht auch keine weiteren Erwähnungen dazu. Bahh.
Eine Website sollte in jedem Browser und bei jeder Auflösung funktionstüchtig sein!

Schriftgrössen

Die Zeit der vielen Buttons ist seit geraumer Zeit jedoch wieder vorbei und es verirren sich nur noch relativ wenige Buttons auf Websites. Dafür hat sich eine neue Spezies aufgemacht, Websites zu verschandeln und unsinnige Aktionen durchzuführen: Schriftgrößen-Anpassungs-Buttons. Alleine der von mir erfundene Name, ist schon abschreckend genug, um verwendet zu werden.

Diesen “Trend” machen weniger die privaten Seiten mit, vielmehr die mittelgroßen und auch viele großen Unternehmen mit. Diese Buttons, meist gekennzeichnet mit -A A A+ und in unterschiedlichen Größen, sollen den Usern zeigen, dass sie barrierefrei geworden sind. Ist ja auch sinnvoll: Wem der Text zu klein ist, kann ich durch Klick auf den Button vergrößern, Leute, die Adleraugen haben, können ihn verkleinern. Macht Sinn?

Macht keinen Sinn für Leute, die das wirklich brauchen:

  • User, die Text vergößert haben wollen, werden es bereits schwer genug haben, diese Buttons zu finden.
  • User, die den Text vergrößert benötigen, haben zumeist eine Sehschwäche, was dann für alle Texten im Internet und am Computer gillt und haben ihren Browser und/oder Computer bereits dafür eingestellt.
  • Die Unterschiede der Schriftgrößen sind geringfügig, so dass es für die Mehrzahl der betroffenen User ohnehin nichts bringt.
  • Aus welchem Grunde soll der Text verkleinert werden? Dann ist die vordefinierte Schriftgröße des Designers falsch angelegt.
  • Oft haben Entwickler, die diese Funktion einbauen, wenig Ahnung von wahrer Barrierefreiheit und somit ist der Rest des Markups, die Kontrastierung der Farben, etc Barrieren und dass für eine größere Benutzeranzahl.
  • Mitunter ist es sogar so, dass der Entwickler zwar diese Funktion eingebaut hat, jedoch vergessen hat sein Layout dafür auszurichten und somit es das Layout zerschießt.

Natürlich stört diese Funktion meistens nicht, sie stellt im Prinzip kein Nachteil dar. Jedoch gibt es keinerlei Grund diese Funktion einzubauen und ist somit unsinnig.

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/11/02/valid-xhtml-und-a-a-a-weg-damit/feed/ 5 Wordpress E-Commerce http://tuts.nicogutmann.de/2009/10/23/wordpress-e-commerce/ http://tuts.nicogutmann.de/2009/10/23/wordpress-e-commerce/#comments Fri, 23 Oct 2009 13:21:00 +0000 admin http://tuts.nicogutmann.de/?p=154 Ich muss zugeben: Am Anfang war ich sehr skeptisch was ein Shop-System für Wordpress anging und es hat auch eine Zeit lang gedauert, bis es mich überzeugt hat. Die große Schwierigkeit zu Beginn lag unter anderem daran, dass es im Prinzip keine vernünftige deutsche Website gibt, die einem dieses Plugin näher bringt, auch auf der offiziellen englischen Website und in der Community gab es wenig. Wie so oft musste man sich das Ganze selbst ansehen und testen, testen, testen.

Die Sprachbarriere

Ein großer Nachteil gleich zu Beginn nach der Installation war, dass es alles andere als komplett übersetzt war. Es war zwar möglich die Sprache auf “deutsch” zu stellen, doch damit war es auch schon, übersetzt war kaum etwas und was übersetzt wurde, hatte einige Fehler drin.
Somit muss man sich wohl oder übel selbst an die Übersetzung machen, sowohl im Backend, aber hauptsächlich im Frontent, was sehr viel Zeit kostet.

Das Gute war, dass mit Variablen und einer externen Sprach-Datei gearbeitet wird, so dass man sich bei der Übersetzung der Hauptbegrifflichkeiten nur in dieser Sprachdatei aufhalten muss. Die Datei findest du im wp-e-commerce-Plugin-Ordner im Ordner “languages”:

wp-content/plugins/wp-e-commerce/languages/DE-de.php

Da nicht alle Variblen dort definiert wurden, musst du dir auch noch die englische Sprachdatei daneben setzen, die ist nämlich komplett definiert. Es ist eine sehr mühsame und zeitaufwendige Arbeit, weshalb ich euch meine Übersetzungsdatei einmal zum Download anbiete.
Diese ist im Prinzip “neutral” gehalten, wobei die ein oder andere Variable auf ein bestimmtes Projekt von mir gezielt übersetzt wurde.

Die wichtigen Dateien

E-Commerce für Wordpress ist ein sehr gutes Plugin, um kleine Shops in seine Website einzubinden und bietet sehr viel Anpassungsmöglichkeiten und ist aus diesem Grunde sehr flexibel.

Der Ordern-Aufbau ist ähnlich dem von Wordpress himself: Im “Index” befinden sich die allgemeinen Variablen und Funktionen, sowie alle Dateien für den Backend-Bereich. Dann gibt es den Ordner “themes”, in dem du dir dein eigenes Theme erstellen kannst und die aktuellen natürlich auch bearbeiten. In diesem Ordner kannst du alles für den Frontend-Bereich bearbeiten:

wp-content/plugins/wp-e-commerce/themes/default

cart_widget.php
Diese Datei ist sehr übersichtlich aufgebaut, beinhaltet auch nur den Warenkorb, der die Produkte anzeigt, die der User in den Warenkorb gepackt hat. Das Widget kannst du bei den Wordpress-Widgets einstellen.
category_widget.php
Wenn du einen Shop aufbaust, der aus mehreren Kategorien besteht, kannst du dieses Widget, das dir alle Kategorien auflistet, in dieser Datei bearbeiten.
functions.php
Das ist nochmal für den Backend: Bei den Shop-Optionen kannst du, je nach Theme, definieren ob und wo die Paginierung erscheint. Zum Anpassen an dein Design ist diese Datei unwichtig
grid_ & list_view.php
Auch diese Dateien sind im Grunde unwichtig, es sei denn du kaufst dir auf der offiziellen Website von E-Commerce die Funktionen “Grid View” und “List View”, um deine Produkte ausrichten zu können. Hier werden dafür dann die Einstellungen gespeichert, unwichtig für den normalen Gebrauch.
products_page.php
Hier beginnt es richtig interessant zu werden: Die Startseite des Shops. Hier werden all deine Produkte (wenn du möchtest) aufgelistet. Den Aufbau und die Details der Ansicht kannst du selbst bestimmen.
shopping_cart_page.php
Das ist die “Checkout”-Seite oder auch die “Kassen”-Seite. Zunächst werden die Produkte aufgelistet, die der User gekauft hat mit Bild, der Anzahl und dem Preis. dann auch gleich das Formular für die Lieferadresse und die Zahlunsgart. Hier wird der Kauf fix gemacht.
single_product.php
Diese Datei beinhaltet die Variablen und das Markup für die Produkt-Seiten, also die Detail-Ansicht für das einzelne Produkt mit dem Preis, den Beschreibungen, den Zusatz-Beschreibungen, der Anzahl, den Versandkosten, etc.

Das waren die Dateien in dem Theme Ordner. Viel mehr musst du auch nicht wissen, wobei du natürlich noch sehr viel mehr (vor allem im Backend) ändern kannst, in dem du die Dateien im “Index” bearbeitest.

Eine Datei, die vielleicht noch wichtig ist, ist die Datei “transaction_result_functions.php”, die den Inhalt der Email-Bestätigung und den Text nach dem Kauf definiert. Wer sich mit PHP auskennt wird hier weniger Probleme haben, wer sich nur grob, so viel ich, damit auskennt, sollte auf die Namen der Variablen schauen, die sich in jeder Datei des Plugins ähneln. So findet man sich recht schenll zurecht und kann auch diese Datei ohne Probleme nach seinen Wünschen gestalten.

Fazit

Das E-Commerce-Plugin von Wordpress lässt sehr viel Spielraum für die komplette Anpassung an seine Website, man muss aber sich damit erst einmal vertraut machen, dann ist es aber relativ einfach und man kann damit sehr viel anfangen. Leider ist der Shop irgendwie nicht ganz fertig entwickelt worden und vor allem für nicht-englischsprachigen Länder nur nach vielen Umstellungen zu gebrauchen.
Der Shop bietet sehr viele Möglichkeiten, wobei diese im Vergleich zu einem kompletten Shopsystem, wie xtCommerce natürlich nur bedingt mithalten kann, aber auch nur dann, wenn es ein sich um ein komplexen Shop handelt.

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/23/wordpress-e-commerce/feed/ 10 Ich versteh’ nur Bahnhof http://tuts.nicogutmann.de/2009/10/19/ich-versteh-nur-bahnhof/ http://tuts.nicogutmann.de/2009/10/19/ich-versteh-nur-bahnhof/#comments Mon, 19 Oct 2009 13:32:51 +0000 admin http://tuts.nicogutmann.de/?p=139 Diesen Spruch kennt wohl jeder von euch. Man verwendet den Spruch gerne, wenn einer in einer fremden Sprache spricht und/oder, wenn ein Physiker über den Doppler-Effekt spricht: Wir verstehen nichts! Kommunikationsprobleme kommen in jeder Sprache, in jeder Kultur und auch in den besten Familien vor: Der Mensch versteht die Sprache der Tiere nicht, der Mann die Frau nicht und umgekehrt und der Hochdeutsche versteht kein Wort bayrisch.

Bedeutung des Wortes

Semantik nennt man die Bedeutungslehre der Wörter. Wenn ich “Bahnhof” schreibe, kann sich jeder sofort ein visuelles Bild davon machen und kann es sofort zuordnen. Wenn ich nun aber z.B. nur das Wort aus der deutschen Sprache kenne und aufgefordert werde einen Satz zu bilden, dann hört sich das so an:
Bahnhof, Bahnhof, Bahnhof, Bahnhof, Bahnhof, Bahnhof, Bahnhof.
Vielleicht wollte er ja das hier sagen, kannte die Worte aber nicht, weil er sich mit der deutschen Sprache bislang nicht auseinandergesetzt hat, obwohl er berits seit geraumer Zeit in Deutschland lebt:
Ich fahre heute Nachmittag zum Bahnhof, um einen Freund abzuholen.
Hier weiß jeder genau was gemeint ist. Jedes Wort hat eine Bedeutung und richtig zusammengebracht ergibt das eine sinnvolle Information, die man verarbeitet und versteht.
Nun hat sich der gute Mann natürlich der Kritik angenommen und ein wenig Deutsch gelernt:
um Bahnhof abzuholen einen ich fahre Freund.
Ich verstehe die einzelnen Wörter, kann jedes einzelne für sich verstehen. Zusammengebracht zu diesem Satz machen die Begriffe an den Stellen aber gar keinen Sinn und ich verstehe den Satz auch nicht, könnte mir evtl. vorstellen, was es bedeuten könnte, wenn in dem Gespräch die ganze Zeit über dieses Thema gesprochen.

Der naive Webdesigner

Was hat das nun mit Webdesign und Webstandards zu tun? Bleiben wir bei dem Beispiel von oben und transformieren das in die HTML-Sprache: Anstelle des Bahnhofs nehmen wir nun eine Tabelle “<table>”.
Jeder versteht den Begriff, kann sich über seine Form und seine Bedeutung ein Bild machen. Nehmen wir einmal den guten Mann und ersetzen ihn durch einen Webdeveloper, der kaum ein Wort &quotHTML” spricht, nur einmal was von Tabellen gehört hat, dass er aus dem Lexikon (Dreamweaver) oder von einem Freund kennt.
“Damit kann man doch gut arbeiten.” Denkt er sich.
Also baut er es fröhlich in seine Website ein bzw. baut sie damit auf. Ist doch ganz praktisch: Tabellen kann man schön für alles verwenden, funktioniert und jeder sieht die Website und kann die Inhalt lesen.
Jeder? Greifen wir das Beispiel von oben nocheinmal auf. Dieser junge Mensch versucht mir zu erklären, dass er einen Freund vom Bahnhof abholen wird. Mit Wörtern kann er es leider (noch) nicht, also versucht er es mir pantomimisch darzulegen. Die Zeichensprache ist immerhin in so gut wie jedem Land veständlich, zu Not kann man es noch aufzeichnen. Es funktioniert und ich verstehe ihn.
Klappt mit ihm, dann klappt es auch mit allen anderen auf der Welt und ich brauche die Sprache gar nicht zu lernen, da ich mich ja auch so verständlich machen kann.

Wir schließen dich aus

Was ist aber mit Leuten, die andere Zeichen verwenden, andere Bedeutungen dafür haben bzw. in der Websprache, was ist mit den Usern, die Browser verwenden, in der die Website nicht ehr so toll aussieht, Busg enthält oder einfach den fehlerhaften Code richtig interpretieren, also falsch darstellen?
Was ist mit den Usern, die andere Arten von Browsern benutzen, weil sie körperlich oder geistig nicht mit der Standard-Software arbeiten können, sich natürlich trotzdem im Web aufhalten?
Was ist mit den Robots, die sich durch den Code quälen, um deine Website in den Suchmaschinen dieser Welt aufnehmen möchten?
Alleine sind sie vielleicht nur ein Prozentsatz der Besucher auf einer Website, zusammen aber ergeben sie eine relevante Gruppe an Usern, die auf deine Website keinen oder nur bedingten Zugriff haben und so auch noch im Web benachteiligt werden, wo es doch “für alle” da ist.

Jeder <Tag> hat seine Bedeutung

Aus diesen Gründen und noch mehr (Übersichtlichkeit, kleinere Dateien, Nachhaltigkeit) ist es sinnvoll semantisches HTML-Markup zu schreiben. Was bedeutet das?
Jeder Tag, jedes HTML-Element hat eine Bedeutung, an die man sich orientieren sollte und dann sinnvoll einsetzen. Es gibt Tags für Überschriften (h1-h6), für Paragrafen (p), für Tabellen (table), für Divisionen (div). Eine Seiten-Navigation ist eine, zumeist ungeordnete, Liste (ul, ol), “label” kennzeichen das folgende Eingabefeld in Formularen, aus Texten hebt man Wörter mit dem “em”-Tag oder dem “strong”-Tag hervor, Zitate werden mit “blockquote” oder dem “q”-Tag gekennzeichnet.
Es gibt sie, also benutze sie auch sinnvoll. Verwende sie nicht im Übermaß, du brauchst nicht jedes Element mit einem “div” umschließen und nicht komplett auf Tabellen verzichten. Jedes Element hat seine Bestimmung, wenn man auch ab ud zu etwas mehr darüber nachdenken muss und es nicht immer eine richtige Lösung gibt bzw. eine optimale Lösung.
Mach dich verständlich im Web, damit deine wertvolle Website auch jeder besuchen kann und genießen kann. Es liegt an dir ;) .

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/19/ich-versteh-nur-bahnhof/feed/ 0 Lupe raus: Mikroformate http://tuts.nicogutmann.de/2009/10/19/lupe-raus-mikroformate/ http://tuts.nicogutmann.de/2009/10/19/lupe-raus-mikroformate/#comments Mon, 19 Oct 2009 12:40:48 +0000 admin http://tuts.nicogutmann.de/?p=127 Der neue Star am HTML-Himmel gibt es schon seit einiger Zeit, hat es aber bislang nicht auf die großen Bühnen der Welt geschafft – zu unrecht. Mikroformate sind vor allem für Maschinen interessant, die sich durch das Markup robben, auf der Suche nach semantischen Auszeichnungen, um den Inhalt zu verstehen. Dafür gibt es natürlich sehr viele HTML-Tags, die den Inhalt gut beschreiben, leider gibt es mehr inhaltliche Varianzen, als es HTML-Tags gibt. HTML 5 wird dem in einiger Zeit ein weiteres Stück entgegen wirken, doch dies noch lange nicht vollständig.

Sinn und Zweck

Aus diesem Grunde wurden Mikroformate entwickelt, damit Maschinen (Robots, Software-Programme oder auch das IPhone) die Inhalte besser “verstehen” können und für sich nutzen können. Damit kann man nicht nur Suchmaschinen-Robots beeinflussen, sondern auch Inhalte in andere Programme speichern, wie z.B. Kontaktdaten in Outlook reinkopieren oder eine Telefonnumer mit dem IPhone direkt anrufen lassen.
Es gibt noch einiges mehr, was man damit anstellen kann, ich gehe in meinem Artikel jedoch nur kurz darauf ein, denn es ist ein riesiges, aber sehr spannendes Thema (Mehr dazu in der Linksammlung).
Da mehrere Programme und Software mit diesen Mikroformaten arbeiten wollen, gibt es inoffizielle Spezifikationen und Namen, die verwendet werden können. Diese Liste wird ständig fortgeführt und haben, da Mikroformate auch international einheitlich sein sollen, englische Namen (microformats).

hCard (vCard)

Es gibt, wie bereits oben geschrieben, unterschiedliche Gebiete Mikroformate zu verwenden. Für einzelne Personen ist die Visitenkarte das Hauptkommunikationsmittel, um seine Kontaktdaten an den Mann zu bringen. Diese gibt es nun nicht nur als gedruckte Version auf Papier, sondern, dank der Mikroformate, auch im Web – hCards (HTML-Cards) oder vCards (Visit Card).
Dabei ist die Einbindung in das HTML-Markup ziemlich einfach; Wir arbeiten einfach mit Klassen und geben den Begriffen smoit auch für Maschinen eine Bedeutung. Maschinen können mit einer Adresse wenig anfangen und alleine durch den address-Tag wissen sie überhaupt, dass es sich um eine Adresse handelt. Doch können Sie nicht denken und somit erkennen Sie auch nicht, was in diesem Address-Tag steht:

<address>
Nico Gutmann<br />
Mustertraße 12<br />
12345 Musterstadt
Tel.: 01234 / 56789
Email: max@nicogutmann.de
</address>

Die Maschinen erkennen nun, dass es sich um eine Adresse handelt, abernicht um was für eine Adresse und sie erkennen nicht den Inhalt der Adresse. Wo ist der Name, was ist die Straße und der Ort? Es wird nicht definiert.
Hier kommen die Mikroformate ins Spiel. Durch Sie können wir nun den Maschinen erklären was wir genau meinen, in dem wir ihnen eine Klasse zuweisen:

<address class="vcard">
<span class="fn">Nico Gutmann</span><br />
<span class="street-address">Mustertraße 12</span><br />
<span class="postal-code">12345</span> <span class="locality">Musterstadt</span>
Tel.: <span class="tel">01234 / 56789</span><br />
Email: <span class="email">max@nicogutmann.de</span>
</address>

vcard, fn, street-address, zip-code und locality sind feste Namen für Mikroformate und definieren die Adresse nun sehr konkreter, wodurch nun auch z.B. Outlook diese einzelnen Felder als solche erkennt. Eine Liste von allen Namen findest du auf www.mikroformate.de.

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/19/lupe-raus-mikroformate/feed/ 0 Alles auf Anfang http://tuts.nicogutmann.de/2009/10/14/alles-auf-anfang/ http://tuts.nicogutmann.de/2009/10/14/alles-auf-anfang/#comments Wed, 14 Oct 2009 11:48:16 +0000 admin http://tuts.nicogutmann.de/?p=104 CSS-Reset, Alles-auf-Null-setzen, alle-Abständen-zurücksetzen. Man kann nennen wie man lustig ist, jeder meint dasselbe: Wir geben jedem Browser dieselbe Ausgangssituation, so dass browserspezifische Probleme eingeschränkt werden. Dieses Reset sollte man bei jedem Projekt zu Beginn definieren. Er wird auf jeder guten CSS-basierten Website zu finden sein und erleichtert die Arbeit, auch wenn es Am Anfang vielleicht nicht den Anschein hat.

Einen Schritt zurück

Bevor wir mit der Technik anfangen (runterscrollen ist unfair), noch ein Vorwort zu den Gründen für ein Reset bzw. zur Begriffserklärung:
Schau dir einmal meine Startseite ohne CSS-Datei an, komplett nackt, das reine Skelett:


Wie man sieht, sieht es nicht gerade schön aus, aber dennoch übersichtlich und man kann sich gut orientieren. Überschriften sind größer und deutlicher als der Fließtext, Listen sind mit Listenpunkten gekennzeichnet, Links sind blau markiert und unterstrichen, und es werden Abstände eingehalten, damit es übersichtlich bleibt.
Was würde passieren, wenn diese Einstellungen nicht vordefiniert wären und man kein CSS anzeigen lassen kann?


Sehr unübersichtlich und unmöglich richtig zu verstehen, oder? Aus diesem Grund haben diese Voreinstellungen durchaus ihren Sinn und müssen von den Browser-Programmierer eingebaut werden.

Ein Browser kommt selten allein

Nun ist es leider so, dass es nicht nur einen Browser gibt, mit dem man sich eine Website ansehen kann, es gibt gleich ein halbes Dutzend. Und natürlich sprechen sich die Entwickler der einzelnen Browser nicht ab und so hat jeder Browser andere Einstellungen. Auf den ersten Blick vielleicht nicht sichtbar, aber spätestens wenn du anfängst mit CSS zu layouten, werden diese kleinen Unterschiede richtig sichtbar und für Ärger sorgen.

Das Reset

Um diesen Ärger einzugrenzen bzw. ganz zu vermeiden, ist es sehr sinnvoll diese Voreinstellungen zu egalisieren, sprich zu eliminieren. Durch Erfahrungen und Ausprobieren weiß man nun welche Voreinstellungen es gibt und welche man demnach auf Null setzen muss. Das muss man nicht auswendig lernen, man bekommt irgendwann ein Gespür dafür bzw. lernt diese von Zeit zu Zeit kennen.
Nun gibt es zwei Grundgerüste, die verwendet werden, die das gleiche machen, aber unterschiedliche Selektoren verwenden. Um einen Überblick über alle vordefinierten Eigenschaften zu bekommen, kann man dieses CSS hier verwenden:

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
   margin: 0;
   padding: 0;
   border: 0;
   outline: 0;
   font-weight: inherit;
   font-style: inherit;
   font-size: 100%;
   font-family: inherit;
   vertical-align: baseline
}
:focus {
   outline: 0;
}
body {
   line-height: 1;
   color: black;
   background: white
}
ol, ul {
   list-style: none
}
table {
   border-collapse: separate;
   border-spacing: 0
}
caption, th, td {
   text-align: left;
   font-weight: normal
}
blockquote:before, blockquote:after,
q:before, q:after {
   content: ""
}
blockquote, q {
   quotes: "" ""
}

Das ist aber sehr umfangreich und meist ist es auch nicht notwendig so umfangreich zu werden (Bei großen Projekten mit mehreren Programmierer schon eher). Davon gibt es dann noch eine abgespeckte Variante, die einfach alle Selektoren aufruft, die Voreinstellungen besitzen. Nicht jeder Selektor besitzt dabei alle Eigenschaften, aber das macht ja nichts:

html, body, div, span, applet, object,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, cite, code,
del, dfn, em, img,b, i, q,
small, strike, strong,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
   margin: 0;
   padding: 0;
   border: 0;
   list-style: none;
   outline: 0;
   font-style: normal
}

Dann gibt es noch eine Variante, die ich persönlich verwende und viele andere auch, da sie kurz und schmerzlos ist und all die Selektoren, die oben aufgelistet wurden, vereint: Der Univeralselektor * (Sternchen). Damit definiert man, wie der Namensteil “Universal” bereits ankündigt, Eigenschaften für alle Selektoren, unabhängig davon, ob sie vererbbare Elemente sind, oder nicht. Diese Eigenschaften, die dort definiert werden, gelten für alle Selektoren und werden in allen Browsern, die noch im Einsatz sind, verstanden:

* {
   margin: 0;
   padding: 0;
   border: 0;
   list-style: none;
   outline: 0;
   font-style: normal
}

Was denn nun?

Es ist also vollkommen egal, welche Variante des Resets du verwendest, es kommt immer auf das Gleiche heraus: Alle Voreinstellungen werden eliminiert. Meistens ist es gar nicht notwendig alle Voreinstellungen zurückzustellen, somit ist dann die kürzere Variante sinnvoller.

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/14/alles-auf-anfang/feed/ 0 Mach es kurz und knackig http://tuts.nicogutmann.de/2009/10/09/mach-es-kurz-und-knackig/ http://tuts.nicogutmann.de/2009/10/09/mach-es-kurz-und-knackig/#comments Fri, 09 Oct 2009 13:26:43 +0000 admin http://tuts.nicogutmann.de/?p=96 DIVities, Diviät, Div-Suppen, man kennt die Begriffe. Es beschreibt auf sarkastische Art und Weise, dass man zu viele Divisionen (Div-Tags) für sein Markup verwendet bzw. für alles Mögliche. Das ist ein Extrem, es gibt aber auch Entwickler, die ihre Seite semantisch korrekt deklarieren (Menu als Liste, Überschriften in h-Tags, etc) und trotzdem eine Div-Suppe fabrizieren, zumindest in Vorspeise-Größe.
Der Sinn und Zweck von Divisionen (div) ist mittlerweile in Vergessenheit geraten und es ist fast schon Standard geworden jedem Bereich von Header über den Inhalt bis zur Site-Info (Footer) in ein Div-Tag zu packen:
<div id="header"></div>
<div id="inhalt"></div>
<div id="site-info"></div>

Das erscheint in erster Linie nun nicht verkehrt, ist es aber zumeist, wenn man bedenkt, dass sich in dem Div #header zumeist nur eine Überschrift befindet bzw. das Logo in einem zusätzlichen h-Tag.

Der Zweck von Divisionen

Erst einmal zurück zum Begriff der Division: Ein div-Tag wurde entwickelt, um mehrere Objekte die inhaltlich zusammengehören, in direkte Verbindung miteinander zu setzen, ein Beispiel hierfür wäre ein simpler Text mit mehreren Zwischenüberschriften, die aber einem Grundthema angehören. Dieser Artikel beispielsweise:
<div class="textbox">
<h2>Mach es kurz und knackig</h2>
<p>DIVities, Diviät, Div-Suppen, man kennt die Begriffe...</p>
<h3>Mach es kurz und knackig</h3>
<p>Erst einmal zurück zum Begriff der Division:...</p>
</div>

Der Artikel behandelt ein Thema und kann bzw. sollte auch im Markup als zusammenhängender Text verstanden werden. Gehen wir zurück zu dem Beispiel mit dem #header und sehen uns ein Beispiel an, wie viele diesen (hier vereinfacht gezeigt) deklarieren:
<div id="header">
   <h1>Ich bin eine Überschrift</h1>
</div>

Die Division #header besitzt ein einziges Element und wird vermutlich nur sehr selten mehr enthalten. Hier ist ein div-Tag total überflüssig und sollte weggelassen werden.
Ähnlich verhält es sich auch mit Navigationen, die im Prinzip ja zumeist nur aus einer Liste bestehen:
<ul id="navi">
   <li>Menupunkt</li>
   <li>Menupunkt</li>
   <li>Menupunkt</li>
</ul>

Auch hier wird oft noch ein Div herumgebastelt, was eben nicht seinen ürsprünglichen Zweck erfüllt, sondern aus anderen (meist gar keinen) Gründen gebaut wird. Weg damit, wenn es nicht unbedingt gebraucht wird!

Eine kluge Vorransgehensweise

Ich glaube und hoffe, dass das Prinzip nun verstanden wurde, sonst hätte ich auch noch ein paar Beispiele im Ärmel ;) .
Ich schreibe mein HTML-Markup nach semantischen Aspekten, soweit nichts Neues. Dabei achte ich nicht auf das Layout, sondern ganz alleine auf den Inhalt, somit kommen bei mir Div-Tags zunächst überhaupt nicht oder ganz selten zum Einsatz. Wenn ich das semantische Markup geschrieben habe, sehe ich mir alle noch einmal an und versuche Elemente, die zusammengehören, zu verknüpfen und stecke sie in ein gemeinsames Objekt, dem Div.
Somit komme ich nicht in Versuchung Divities auszulösen und alles in so einen Tag zu setzen, sondern verwende es nur, wenn es für mich sinnvoll erscheint, wodurch man nicht nur viel Bytes und Zeit spart, sondern auch eine stärkere Übersicht erhält.

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/09/mach-es-kurz-und-knackig/feed/ 0 CSS 2.1 – Zurück in die Zukunft http://tuts.nicogutmann.de/2009/10/08/css-2-1-zuruck-in-die-zukunft/ http://tuts.nicogutmann.de/2009/10/08/css-2-1-zuruck-in-die-zukunft/#comments Thu, 08 Oct 2009 13:53:21 +0000 admin http://tuts.nicogutmann.de/?p=79 Das wird hier wohl kein langer Artikel, aber es soll aufzeigen, dass viele Webentwickler sich dank der, nennen wir es einmal, langsam Vorranschreitung des Internet Explorers aus dem Hause Microsoft nicht herantrauen CSS in seinen vollen Zügen einzusetzen. Dabei spreche ich nicht von CSS 3, auf das ich mich schon sehr freue, sondern von dem im Jahre 1999 entwickelten CSS 2.1.
Ja, die offiziell aktuelle CSS-Version gibt es schon eine gefühlte Ewigkeit und trotzdem kann man sie nicht in vollen Zügen einsetzen, oder? Auf diese Frage gibt es ein eindeutiges: Jein.

Der IE6 ist noch unter uns

Fakt ist leider immer noch, dass der Internet Explorer 6 noch relevant ist, wenn es darum geht sine Website in Browsern zu testen, das wird sich wohl auch im Jahre 2010 noch nich ändern bzw. nur geringfügig. Fakt ist aber auch, dass wir uns aus diesem Grunde nicht in Richtung Zukunft orientieren sollten, ganz im Gegenteil. Es geht nur darum wie wir es machen.
Es gibt recht viele Selektoren, Pseuoklassen und Eigenschaften in CSS 2.1, die der IE6 nicht versteht, seine Nachfolger Nummer 7 und 8 hingegen schon, die Browser, wie Firefox, Safari, Chrome oder Opera natürlich allemal (Safari kann sogar schon CSS 3 in seiner neuesten Version). Diese Selektoren/Pseudoklassen können trotzdem verwendet werden, ohne die Seiten für den IE 6 auszuschließen.

Keine Gleichheit für Alle

Form follows Function, diesen Leitsatz sollte sich jeder hinter die Ohren oder noch besser vor seinen Arbeitscomputer schreiben. Eine Website muss in erster Linie funktionieren, ohne Einschränkungen, ohne Barrieren (Barrierefreiheit), über das Aussehen lässt sich bekanntlich immer streiten. Um die Kurve zu meinem Leitzsatz “Benutz CSS 2.1″ wieder zu bekommen, sage ich: Eine Website muss nicht in jedem Browser pixelgenau gleich aussehen und ein User, der mit einer alten Technik unterwegs ist, sollte nicht dafür auch noch belohnt werden. Das Wichtige ist: Die Website behält seine Grundstruktur, behält seine Idee und seine Seele.

Ich hatte früher einen Schwarz-Weiß-Fernseher, der Rest in meiner Straße und fast alle in meinem Dorf hatten einen Farbfernseher. Manche hatten einen mit 50 Zentimetern Durchmesser, andere mit 40, ich mit knappen 30 Zentimeter. Um 20:00 Uhr haben alle die Tagesschau gesehen und wir haben sie alle empfangen und den gleichen Informationsgehalt empfangen, nur ich eben nicht mit den ganzen schönen Farben und ein wenig gequetschter bzw. sehe die Moderatorin evtl. nicht ganz. Glaubst du das Erste hätte, nur weil ein paar Leute noch mit S/W-Fernseher unterwegs waren, ihre Sendungen ebenfalls in schwarz-weiß gezeigt, damit alle es genau gleich sehen und keiner bevorteilt wurde, aus gestalterischen Gesichtspunkten?

Kenne deinen Feind

Nun sollte man nicht einfach drauflos schreiben und sich nicht mehr um die User, die mit einem älteren Modell unterwegs sind, kümmern, das wäre der falsche Weg. Man muss aber seinen Feind kennen, wie man so schön sagt, und auf ihn reagieren.
Lange Rede immer sehr viel Sinn: CSS 2.1 kann man sehr gut verwenden, wenn dadurch keine Schäden in der Usability und im Informationsgehalt entstehen, die so erheblich sind, dass der User sich nicht mehr zurecht findet, wichtige Informationen nicht mehr erhalten kann oder die Seite gar nicht mehr bedienen kann.

CSS 2.1: Einige sinnvolle Selektoren

Wovon rede ich denn nun genau? Welche Selektoren kann ich benutzen, welche Pseuoklassen gibt es denn, die der IE 6 nicht versteht, dennoch verwendet werden könnten? Ich selbst verwende für diese Tutorial-Seite einige davon, weil sie einfach praktisch sind:

Pseudoklasse :after

Die Pseudoklasse :after versteht auch der IE 7 nicht und fügt einfach Eigenschaften, die man dafür definiert, hinzu, nachdem das Objekt geschlossen wurde ohne zusätzlichem Markup.
Hier kann man super Hintergrundbilder zusätzlich einbinden, da es bislang nicht möglich ist einem Objekt mehr als ein Hintergrundbild zuzuweisen. Das ändert sich in CSS 3 zum Glück.
.info-box:after {
content:"";
display:block;
width:224px;
height: 45px;
background: url(imgs/beitrag_fusszeile-rechts.png);
}

Pseudoklasse :before

Ähnlich verhält es sich mit :before, nur das das Definierte eben vor dem Objekt in Erscheinung tritt. Auch das habe ich auf dieser Website verwendet und zwar die Überschriften für die Codes, wie CSS-Code, etc:
code:before {
display: block;
height: 15px;
color: white;
position: absolute;
top: -10px;
left: 10px;
background: black url(imgs/bg-code.gif) 3px center no-repeat;
padding: 2px 5px 2px 20px;
content: "CSS-Code:";
}

Content-Eigenschaft

Wie vielleicht schon aufgefallen ist, verwende ich die Eigenschaft content in diesen Selektoren. Diese Eigenschaft ist auch nur dort anwendbar und mit ihr kann man dem Objekt Inhalt verpassen. Das geht von einem einzigen Punkt bishin zu einem Bild (nicht für den IE bis einschließlich 8).

Attributselektoren

Attributselektoren sind eine feine Sache und können verdammt viel Arbeit erleichtern und Markup sparen. Mit ihnen kann man Attribute wie alt,type,class,id,name,href, etc direkt per CSS ansprechen und Objekten, die diese Attribute besitzen individuell ansprechen.
Das ist sehr Sinnvoll bei Verlinkungen (Unterschdiung zwischen externen und internen Links), bei Formularen (Input-Felder für Namen und Absendebuttons) oder auch bei Sprachauswahlen (lang=”en”). Es funktioniert im Prinzip ganz einfach und ist beliebig variabel:
a[href] {
background: url(imgs/icon-externer-link.png) no-repeat;
}
a[type="submit"] {
width: 100px
}
img[alt~=Galerie] {
width: 200px /* Alle Bilder die das Wort "Galerie" enthalten */
}

Das ist alles noch innerhalb von CSS 2.1. CSS 3 bietet in dieser Richtung dann noch viel mehr und es wird alles noch individueller werden.

Nachbar-Selektoren

Eine weitere sehr schlaue Entwicklung, mit dem ihr benachbarte Objekte ansprechen könnt ohne mit IDs oder Klassen um euch zu werfen. Meist wird das dann verwendet, wenn man Abtsände definieren möchte, auch ich habe es auf dieser Website verwendet:
p+h4 {
margin-top: 15px
}
Ich verwende auf unterschiedlichen Seiten Überschriften vierter Ordnung (h4), nicht nur in reinen Textabschnitten, sondern auch in Listen. Nun möchte ich aber nur den Überschriften Luft nach oben lassen, die in Textpassagen vorkommen und das recht simpel.
Nun wurde der Artikel doch länger als befürchtet, doch es musste alles gesagt werden, was gesagt wurde :) .

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/08/css-2-1-zuruck-in-die-zukunft/feed/ 1 Raus aus der Hässlichkeit http://tuts.nicogutmann.de/2009/10/05/raus-aus-der-hasslichkeit/ http://tuts.nicogutmann.de/2009/10/05/raus-aus-der-hasslichkeit/#comments Mon, 05 Oct 2009 13:15:25 +0000 admin http://tuts.nicogutmann.de/?p=46 Die meisten Websites erfüllen ihren Zweck: Sie informieren einen, sie geben dir die Informationen, die du benötigst. Oft ist es das dann aber auch, es ist nicht mehr, aber auch nicht weniger. In einer so schnelllebigen Welt und in einer Informationsgesellschaft ist das sicherlich nicht verkehrt, dass der Content an erster Stelle steht und schnell erfassbar ist. Zumindest bei Zweiterem kann das Design dazu beitragen, dass dieser Zustand verstärkt wird.

Schlechtes Design ist überall

Vor einigen Jahren hat man noch ins Telefonbuch gesehen, wenn man einen Friseur in einer Nähe gesucht hat oder einen Handwerker, weil das Klo verstopft ist. Mittlerweile geht man dafür ins Internet, da erzähle ich dir sicherlich nichts Neues. Es spielt sich alles im Web ab und kein Unternehmen, sei es noch so klein, kann es sich leisten nicht online zu sein.
Zumeist machen Unternehmen aber eben diesen Fehler: Sie wollen einfach “nur” online sein. Wie die Website aufgebaut ist, was sich darin befinden soll, wie sie gestaltet ist und dass sie auch bei Google gefunden werden sollen, ist dabei eher nebensächlich.

Wer sich einmal ins Internet getraut hat, hat damit einen ersten Schritt getan. Da bleiben aber nun viele stehen und wollen nicht die Treppe weiter hinauf laufen, denn nun sind sie doch eine Stufe höher als &uot;die Anderen”. Falsch! Sie stehen nun auf der gleichen Stufe, neben zig Konkurrenten, was für die Meisten genug ist, wenigstens nicht darunter.

Abheben tut man sich von der Konkurrenz dadurch nicht und abhängen tut man sie schon gar nicht. Was tun, was tun? Ein User entscheidet, wenn auch unterbewusst, in den ersten 2-3 Sekunden, wie er die Website zuordnet. Viel länger will er auch nicht suchen müssen, um seine gewünschten Informationen zu bekommen. Wenn diese nicht da sind, schmeißt er die Suchmaschine wieder an und sucht den Nächsten.
Design kann diesen ersten Eindruck und auch die wichtigen Informationen sehr stark beeinflussen, stärker als viele vielleicht glauben oder zugeben wollen.

Accessibility = schlechtes Design

Es gibt immer mehr Websites, die sich daran versuchen barrierefrei beziehungsweise barrierearm zu sein. Manchen gelingt es weniger, manchen mehr, die meisten haben aber eines gemeinsam: Das Design ist sehr langweilig, sehr ungrafisch, sehr einfach gestaltet oder manchmal auch hässlich (zumeist aber mit sehr brauchbaren Inhalten, was einiges wieder zurecht rückt)!
Diese drei Beispiele sind übrigens alle auf der ersten Seite von Google zu finden, wenn man “barrierefrei” eingibt. Ob diese nun wirklich die meisten Barrieren aus dem Weg geräumt haben, habe ich erstmal nicht beurteilt:


  • www.Barrierefreies-Webdesign.de

    “Ein behindertengerechtes Internet gestalten” – Das ist ihr Claim, mit dem Augenmerk auf gestalten. Über Geschmack lässt sich bekanntlich streiten, in meinen Augen wurden hier viele augenkrebserregende Elemente eingebaut, was wenigstens den sterilen Klinik-Look erklären würde.


  • barrierefrei.e-workers.de

    “Best Viewed With An Open Mind” – Das steht unten im Footer, leider haben die Herren Gestalter der Site kein open mind für uns Gestalter, denn auch hier ist die Gestaltung so groß und klotzig wie es nur möglich war.


  • www.WebForAll-Heidelberg.de

    “Projekt für Barrierefreiheit im Internet” – Dieser These kann man nur untertützend beistehen. Jedoch scheint das hier nur für die Technik dahinter zu gelten. Ich benötige relativ lange, um mich auf der Startseite zurecht zu finden, was vor allem an dem schlechten Design liegt.

Muss das sein? Müssen barrierearme Websites hässlich sein und darf man sich bei diesen Projekten grafisch nicht entfalten? Doch! Man darf es, man sollte es! Design hilft sogar oft der Usability und das Thema und der Inhalt kann man damit stark unterstützen.
Welche größere Benutzergruppe kann man damit schaden? Sehbehinderte nicht, Hörgeschädigte auch nicht, ebensowenig wie Farbenblinde, wenn man rein von den Formen ausgeht, oder Menschen mit physischer Behinderung. Es kommt kaum einen, der sich von einem guten Design abschrecken lässt, ich kenne keinen.

Es gibt natürlich auch schöne Beispiele, die barrierearm sind und mit einem ansprechenden und passenden Design überzeugen, wobei ich mich da bei der Suche schwer getan habe:


  • www.BLE.de

    Die Bundesregierung macht auch ab zu entwas richtig: Eine klare, schöne Seite mit viel Weißraum und passenden Farben und Bildmotiven.


  • Kulturbanause.de

    Ein Kulturbanause ist dieser Webdesigner sicherlich nicht. Sehr schöne Grafiken und dazu noch ein ordentliches Markup (mit Steigerungspotenzial).


  • www.KfZ-SV-Kuehn.de

    Sicherlich hätte man hier noch einiges mehr herausholen können, aber schon bereits ein sehr guter Weg. Sehr ungewöhnlich dieses klare und moderne Design im Bereich KfZ, mehr davon.

Es ist also möglich, wenn man sehr viel Ahnung von dem hat was man tut und warum. Viele Unternehmen, Webseiten-besitzer trauen sich meistens nicht an zu grafischen Elementen, weil es dann nicht auf den ersten Blick nach einer barrierearmen Website aussieht.
Das ist doch völlig irrelevant, ich habe diesbezüglich auch einen Beitrag über Valid-HTML-Buttons, Schriftvergrößerungen, etc geschrieben, weil viele Websites meist mehr Schein als Sein sind. Was zur Zeit sowieso IN zu sein scheint, wenn man sich die Politik oder Großunternehmen, wie RWE oder die Banken ansieht, ein Claim, der sich durch fast alle Gesellschaftsschichten durchzieht.

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/05/raus-aus-der-hasslichkeit/feed/ 0 Guten <Tag>: Eine Auflistung http://tuts.nicogutmann.de/2009/10/05/guten-freunde/ http://tuts.nicogutmann.de/2009/10/05/guten-freunde/#comments Mon, 05 Oct 2009 13:13:02 +0000 admin http://tuts.nicogutmann.de/?p=42 HTML besteht aus Tags (englische Aussprache, bitte: Tääks), das ist kein Geheimnis. Jeder Tag hat eine Bedeutung, die man von jedem kennen sollte, wenn man sich mit semantischem Markup beschäftigen möchte. Leider gibt es bisher nicht für alle Objekte spezielle Tags, somit muss man sich oft mit der Frage konfrontieren, welcher Tag nun für den Inhalt am sinnvollsten ist.

Let’s get it started

Ich habe einmal alle wichtigen Tags augelistet, sie es zur Zeit (bis HTML 4.01) gibt. Es sei dazu angemerkt, dass ich nicht jegliche Tags hier aufliste, sondern nur die heute noch angewandten und für das Layout relevanten (ohne html, meta, body, etc).

<a> – Anchor – Anker
Das ist der Tag, der Seiten miteinander verknüpft oder wie es für Anker in dem Sinne üblich ist: Zu deinem definierten Punkt auf der Seite springt (durch #).
Art: Inlineelement
<abbr> – Abbreviation – Abkürzung
Abkürzungen verkürzen einem vieles, nicht jeder kennt sie immer. Durch diesen Tag können sie erklärt werden und in voller Länge gezeigt werden (title-Tag). Beispiele für Abbreviationen sind: z.B., USA, bspw., etc, PS.
Art: Blockelement
<acronym> – Acronym – Abkürzungswort
Sehr ähnlicher Verwendungszweck wie der abbr-Tag und doch zu unterscheiden. Acronyme sind Abkürzungen, die gleichzeitig auch ein Wort sind und als Wort ausgesprochen werden können, wichtig für Screenreader. Beispiele für Acronyme sind: NASA, PETA oder Kripo.
Art: Blockelement
<b> – Bold – Fett
Dieses Tag macht aus einer normalen Schrift eine fettgedruckte Schrift, mehr nicht. Weder für Suchmaschinen, noch für Screenreader hat er eine Bedeutung.
Art: Inlineelement
<blockquote> – Blockquote – Zitatenblock
Daduch werden längere Zitate mit mehreren Absätzen definiert.
Art: Blockelement
<br> – Break – Zeilenumbruch
Das folgende Objekt springt in die nächste Zeile. Bei Texten wird das gemacht, um den Überblick in einem Paragrafen zu verbessern.
Art: Inlineelement
<div> – Division – Bereich
Vorsicht: Sparsamer Umgang. Dieser Tag sollte nur dann eingesetzt werden, wenn mehrere Objekte miteinander in Verbindung gebracht werden sollen, zu einem Bereich verschmelzen sollen.
Art: Blockelement
<dl> – Definitionlist – Definitionsliste
Hier seht ihr gerade eine Definitionsliste im Einsatz. Es wird im Grunde verwendet, um Begriffe zu definieren, zu beschreiben. Das Einsatzgebiet kann sich auch breiter ziehen
Art: Blockelement
<dt> – Definitontag – Definitionsbegriff
Der zu beschreibende Begriff wird durch diesen Tag definiert.
Art: Inlineelement
<dd> – Definiton description – Definitionsbeschreibung
Hier kommt dann die Beschreibung rein. Diese kann sich von einem Satz bishin zu ganzen Absätzen, Listen, Überschriften ausweiten..
Art: Blockelement
<em> – Emphasises – Hervorhebungen
Durch den em-Tag werden bestimmte Schlagwörter für Suchmaschinen und Textbrowser und Screenreader hervorgehoben und stärker ausgesprochen.
Art: Inlineelement
<fieldset> – Fieldset – Bereichsfestlegung
Schwer zu übersetzen, leicht zu beschreiben: Es unterteilt Textfelder bei Formularen in Bereiche auf, je nach Inhalt (Persönliches, Geschäftliches, etc)
Art: Blockelement
<h1>-<h6> – Headline – Überschrift
Jeder Text benötigt Überschriften, der den Textinhalt kurz erläutert und dem Leser eine Hilfestellung gibt. Hier wird hierarchisch vorgegangen: H1 sollte pro Seite nur einmal vorkommen und beschreibt die komplette Seite (eine Seite), h2 spielt bei Suchmaschinen eine wesentliche Rolle.
Art: Blockelement
<i> – Italics – Kursiv
Hebt den Text nicht hervor, dient nur zur Gestaltung. Sollte sparmsam eingesetzt werden.
Art: Inlineelement
<label> – Label – Kennzeichnung
Hauptsächlich bei Formularen eingesetzt, wird es als Kennzeichnung eines Textfeldes, Radiobuttons, Textberichs, etc verwendet. Es gibt an, was eingetragen werden soll.
Art: Inlineelement
<li> – List-Item – Listenpunkt
dürfen nur an zwei Stellen vorkommen: Bei geordneten und bei ungeordneten Listen. Darin können weitere Blockelemente, wie Paragrafen oder Überschriften vorkommen. Divs haben dort nichts verloren
Art: Blockelement
<ol> – Ordered List – Geordnete Liste
Eine Auflistung mit einer bestimmten Reihenfolge, die man auf keinen Fall umändern kann, um den Zusammenhang zu verstehen, gehören in eine Geordnete Liste.
Art: Blockelement
<p> – Paragraph – Paragraf
p-Tags teilt fast ausschließlich einen Text in Paragrafen, in Absätze unter, z.B. wenn ein neuer Gedanke beschrieben wird. Darin dürfen keine weiteren Blockelemente stehen.
Art: Blockelement
<q> – Quote – Zitat
Neben blockquote, ist der q-Tag eine weitere Option Zitate zu definieren. Dieser wird aber nur für kurze Zitate verwendet und kann auch inmitten eines Textblocks stehen.
Art: Inlineelement
<span> – Span – Abgrenzung
Objekte können duch den span-Tag spezielle Definitionen per CSS bekommen oder Attribute verwiesen bekommen, wie die Sprache (lang=”").
Art: Inlineelement
<strong> – Strong – kräftig
Ähnlich des em-Tags hebt er bestimmte Objekte, Textbereiche, Wörter hervor. Er verstäkrt den Begriff und dieser wird kräftiger und lauter ausgesprochen.
Art: Inlineelement
<table> – Table – Tabelle
Tabellen kommen auschließlich bei der Ausgabe tabellarischer Daten vor, wie z.B. bei einem Terminkalender oder einer Sporttabelle.
Art: Blockelement
<th> – Table-Head – Tabellenkopf
Eingebaut in einer Tabelle beschreibt er die Überschrift einer Tabellenzeile, damit der Leser beispielsweise bei einer Nummer weiß, ob es sich um eine Telefonnummer, einer Hausnummer oder eine Kontonummer handelt.
Art: Blockelement
<tr> – Table Row – Tabellenzeile
Dieser Tag teilt die Tabelle in Zeilen ein. Eine Zeile kann mehrere Zellen besitzen.
Art: Blockelement
<td> – Table Data – Tabellenzelle
Das ist sozusagen der Inhaltsbereich der Tabelle.
Art: Blockelement
<ul> – Unordered List – Ungeordnete Liste
Eine Auflistung, deren Reihenflge mehr oder weniger egal ist. Einsatzgebiete sind natürlich normale Auflistungen, aber auch Menüs und Produktlistungen.
Art: Blockelement

Links zum Tutorial

]]> http://tuts.nicogutmann.de/2009/10/05/guten-freunde/feed/ 0