Mittwoch, August 31

 

Warum XHTML doch (noch) nicht XML ist

Deine Seite ist wunderbares valides XHTML? Vermutlich interessiert das den Browser aber überhaupt nicht. Er wird den HTML Parser hervorkramen und die Seite als HTML verarbeiten. Eigentlich wäre ein XML Parser effizienter, aber solange der Webserver als Content-Type: text/html angibt, wird kein Browser es als XML behandeln.

Versteh mich nicht falsch! Es ist nicht falsch XHTML als text/html auszuliefern. Der Validator bestätigt das. Um mal den Wortlaut der RFCs zu übersetzen:
Statt application/xhtml+xml ist auch application/xml oder text/xml möglich.

Das Problem bisher ist, dass die Browser es noch nicht so ganz ordentlich unterstützen. Auch sollte man bedenken, dass bei einem XML Fehler (Tag nicht geschlossen etc) der Browser normalerweise komplett abbricht und eine Fehlermeldung anzeigt, statt den Fehler zu korrigieren. Wer Lust hat, kann seinen Browser ja mal testen.

Dienstag, August 30

 

Wie wird man Webdesigner?

Was tun in diesem Fall? Nun, es gibt einiges zu Lernen, mein junger Padawan. Ich werde dir drei Links geben. Dazu noch üben, üben und üben. Und schon bist du ein Webdesigner.

Wer gerade mal weiß, dass es HTML ist, was er schreiben will. Der sollte sich erstmal mit SelfHTML beschäftigen. Alle Grundlagen stehen dort drin und es bleibt auch eine gute Referenz. Ich benutze SelfHTML immer noch. Es ist eigentlich das Nachschlagewerk Nummer eins in deutsch.

Nachdem man nun schon die ersten Seiten gebastelt hat, sollte man sich Dr Web mal ansehen. Während SelfHTML sich auf das Handwerkliche konzentriert kann Dr Web auch viel zu Themen wie Usability bieten. Das Weblog ist auch sehr interessant und bietet immer wieder gute Ideen.

Den dritten Link habe ich selbst erst vor kurzer Zeit entdeckt. Auf jeden Fall empfehle ich für die echten Profis A List Apart. Hier wird schon philosphisch und nachdenklich. Die Herausgeber haben sich die Vorgabe gesetzt, Nichts zu veröffentlichen, was es schon irgendwo anders gibt, also sind alle CSS Tricks dort auch wirklich neu. Leider gibt es in diesen Sphären nichts Deutsches mehr. Ein Hoffnung bieten da vielleicht die kürzlich ins Leben gerufenen Webkrauts, aber wer vorne dran sein will, wird ohne Englisch nicht auskommen.

Natürlich ist das Lesen alleine nicht der Trick. Anwenden, Ausprobieren, Herumspielen, Kreativ sein! Das ist wichtiger. Auch hilft es sehr, wenn man andere Leute kennt, die das Gleiche machen.

Montag, August 29

 

Wieviele Farben sollte eine Website haben?

2 vielleicht auch 3. Das ist die schnelle Antwort.

Das hört sich nach ziemlich wenig an, aber man muss diese Aussage etwas relativieren. Schwarz und Weiß zählen nicht als Farben. Sie sind unbunt. Auch verschiedene Helligkeitsabstufungen gelten jetzt mal als die selbe Farbe, auch wenn das für einen Computer nicht so ist. Der Hintergrund des Titelbilds ist in diesem Sinne einfach nur blau.

Es geht hier auch nicht darum, alle anderen Farben auszublenden. Sobald ein Foto auf einer Seite ist, hat man sowieso fast alle Farben. Es geht darum ein Farbschema zu entwickeln. das die Seite dominiert. Dadurch bekommt eine Seite Charakter und es gibt einen Wiedererkennungseffekt.

Webdesign in kleinen Happen benutzt zum Beispiel die beiden Farben Blau und Rot-Orange (genauer dodgerblue und redorange). Web.de benutzt Blau und Gelb.

Diese Farben sollten subversiv eine Bedeutung haben. Hier sind Titel blau und Links orange. Deswegen ist auch das Titellogo blau und die Links in der Navigation werden ebenfalls blau, wenn man mit der Maus drüber fährt.

Diese Regel mit den 2 oder 3 Farben kann man relativ problemlos brechen. Zum Beispiel ist es recht beliebt Unterkategorien einer Seite mit verschiedenen Farbtönen zu kennzeichnen. Der Spiegel macht das zum Beispiel. Politik ist rot, Wirtschaft blau und Sport grün. Oder man setzt voll auf bunt, so wie eine gewisse Suchmaschine. Trotzdem heißt die eiserne Regel für Designer, dass man nur Regeln brechen sollte, die man beherrscht. Also lieber erstmal bei 2 oder 3 Farben bleiben, auch damit kann man coole Seiten bauen. Selbst eine Farbe reicht eigentlich.

Das Titellogo bricht die Regel, da es ja auch Grün und Gelb beinhaltet. Das ist ok, weil dieser "Happen" mit Traube und Käse (Na wer hats erkannt?), als Bild zählen kann. Außerdem wollte ich, dass die Seite bunt und nach designerischer Vielfalt aussieht, nicht einfarbig, stromlinienförmig im Business-style.

Sonntag, August 28

 

Welche Vorteile hat XHTML?

Warum sollte man XHTML schreiben, statt das gute alte HTML? Es funktioniert doch. Und warum muss es validieren? Wenn mein Browser es richtig anzeigt, ist das doch ok. Nein, ist es nicht und hier die zwei Argumente:
Das erste Argument ist wohl recht einleuchtend, aber kein guter Grund. Das Zweite will ich noch etwas erklären. XML bedeutet eXtensible Markup Language und aus irgendeinem Grund muss es heutzutage überall drin sein. Ich finde nicht, dass XML so toll ist, aber es ist für das Web nicht so schlecht wie z.B. SGML. XML wird in vielen Anderen Dingen verwendet: RSS/Atom Feeds, Word und OpenOffice.org Dokumente, RPCs, Jabber IM, ...

Welche Vorteil hat nun XML? Zum einen ist es ineinander einbaubar. Man kann problemlos XHTML in einen Atom Feed einbauen, wenn man den entsprechenden type und namespace angibt. Wenn man das mit HTML versucht, kann das zu einem Fehler führen.

Ein XML Parser ist einfacher zu programmieren als ein HTML Parser. Das bringt einem Webdesigner nichts, aber es erleichtert den Browser Programmierern die Arbeit und das wiederum bedeutet eine zuverlässigere Darstellung. Für Fortgeschrittene: HTML ist SGML und das lässt sich nicht in einer EBNF darstellen, weil es nicht "kontextfrei" ist. (Was das bedeutet, lernt man zum Beispiel im ersten Semester Informatik)

Was bedeutet nun "validieren"? Ein XML Dokument das valide ist, ist syntaktisch fehlerfrei. Wenn ein XHTML Dokument nicht validiert, bedeutet es, der Browser muss eine Fehlerkorrektur durchführen. Das kann bei unterschiedlichen Browsern zu unterschiedlichen Ergebnissen führen. Ein Validator hilft einem also Fehler zu finden die woanders zu Anzeigefehlern oder gar Abstürzen führen könnten. Deswegen ist es keine Schikane, einen XHTML Validator zu benutzen, sondern eine Hilfe. Außerdem bin ich cooler, wenn meine Seite validiert und deine nicht.

Falls einem das nach viel Arbeit aussieht - das ist es nicht. Man gewöhnt sich daran und das XHTML, das ich schreibe ist meistens auf Anhieb valide. Man vergisst vielleicht mal das abschliessende "/" in einem img Tag, aber das ist schnell korrigiert.

Falls du das ganze technische Gebrabbel nicht verstanden hast, reicht es diese einfache Regel zu befolgen: Schreib ordentliches XHTML! Ob es ordentlich ist, sagt dir ein Validator.

Samstag, August 27

 

ASCII Art für Überschriften

Ein Freund wollte coole Überschriften, die so aussehen:
--//Überschrift//---->>
Nun ist es aber blöde, sowas Jedesmal in den h3 Tag mit reinzuschreiben und auch irgendwie "unsemantisch". Eigentlich ist das ja Layout, also wie macht man sowas denn mit CSS?

Erste Idee für Überschriften ist immer ein Hintergrundbild (background: url(...);) für das h3 Tag. In diesem Fall funktioniert das aber nicht, denn das Bild kann sich nicht an verschieden lange Überschriften anpassen.

Die Lösung sind zwei CSS Pseudo-elements: h3:before und h3:after, denen man mit der Eigenschaft content den gewünschen ASCII Code eingibt. Im CSS sieht das dann so aus:
h3:before {
content: "--//";
}
h3:after {
content: "//---->>";
}
Bewundern kann man das in seinem Blog d135-1r43.
 

width ist im Internet Explorer anders

Eine der nervigen Angewohnheiten des Internet Explorers* ist es, die Breite von Boxen (div und Co) falsch zu berechnen. Nehmen wir an wir haben eine div-Box mit einem Innenabstand (padding) und einem Rand (border) von 5 Pixeln. Das sind ingesamt 20 Pixel die in der Breite dazu kommen. (jeweils links und rechts 10 Pixel).

Wenn wir dieser Box nun die Breite (width) 100 Pixel geben. Sind das nach Standard 120 Pixel Breite. Der Internet Explorer* wird die Box allerdings 100 Pixel breit machen und den Inhalt um 20 Pixel zusammenstauchen.

Dies ist einer der häufigsten Gründe warum man sein CSS mit unschönen Hacks verunstalten muss. Die Lösung für diesen Box Model Bug ist als Boxmodel Hack von Tantek Çelik bekannt.

Man schreibt die width für den Internet Explorer. Dann baut man seltsames CSS Zeug ein, was den Internet Explorer* verwirrt, so dass er alles was danach kommt zu ignorieren. Nun kommt die echte width, die dann den alten Wert überschreibt. Jetzt gibt es aber noch Browser (Opera 7+), die ebenfalls verwirrt werden. Für diese muss man nochmal extra CSS Code einfügen der ebenfalls vom Internet Explorer (ohne Sternchen!) ignoriert wird.

div.content {
width:440px; /* für den Internet Explorer */
padding:10px;
border:solid 10px #009; /* 40 Pixel Unterschied wären das nun */
voice-family: "\"}\""; /* Internet Explorer* verwirren */
voice-family:inherit; /* ordentlichen Wert für voice-family setzen */
width:400px; /* echter Wert */
}
html>body .content { /* Das versteht der Internet Explorer nicht */
width:400px;
}
So sieht dass dann aus. Ist es da nicht verständlich, wenn man als Webdesigner den Internet Explorer hasst? Es wären 5 statt 11 Zeilen CSS Code.

* bedeutet der Internet Explorer unter Windows außer Internet Explorer 6.0 im Standard Mode
 

Welches CMS ist das Beste?

Die Diskussion ist hitzig. "Typo3 ist auf Industrieniveau", "Mambo ist viel leichter zu lernen", "ezPublish ist wirklich cool". Die wirklich Antwort ist natürlich, dass man für jedes Projekt jeweils das passende CMS auswählt. Und da gibt es im Internet einige Hilfen dazu.

Ich nehme mal an, zu Beginn eines Projekts erstellt man eine Liste mit allen Features, die die neue Seite haben soll. Davon interessieren uns erstmal nur die technischen Details für die Wahl des CMS. Die Liste könnte so aussehen:
  1. WYSIWYG Editor
  2. Kalender
  3. Caching
  4. Bildergalerie
  5. News mit RSS Feed
Erste Frage: Ist das Alles oder könnte da leicht in noch ein oder zwei Features dazukommen in der nächsten Zeit? Man sollte sich klar machen, ob man Wachstumspotential mit einkalkuliert oder nicht.

Jetzt geht auf cmsmatrix.org zur Suche und klickt einfach alle gewünschten Features an. Mit der Liste oben gibt es zuviele Ergebnisse, deswegen wünschen wir uns einfach noch ein paar Kleinigkeiten dazu: friendly-urls, Developer Community, XHTML compliant, GPL licence, ...

So kann man die Suche normalerweise ganz gut auf 3-5 potentielle Systeme eingrenzen. Jetzt gehts zu opensourcecms.com, um diese paar CMS auszuprobieren. Die Seite bietet frische Installationen von praktisch allen Open Source CMS an, die alle 2 Stunden gelöscht und neu installiert werden. Man hat vollen Zugriff auf alle Administratorfunktionen und kann ungeniert ausprobieren.

Vielleicht auch noch eine gute Idee ist, auf Technorati danach zu suchen. So findet man ein paar persönliche Meinungen über die verschiedenen System. Mein Geheimtip ist bei dieser Gelegenheit Website Baker 2.

Freitag, August 26

 

name, class, id? Was denn nu?

Es gibt drei Attribute mit denen man Namen in Elemente vergeben kann. Aber wann benutzt man nun id und wann class? Und wann gar name?

In Kurzform:
  1. id für einmalige CSS Definitionen
  2. class für Gruppen von CSS Definitionen
  3. name für Javascript DOM
Wenn man es bildlich ausdrücken will, gibt es da ein img-tag. Die Polizei kann es "eindeutig" an der id identifizieren und es kann außerdem zu einer ganze class von img-tags gehören.

Um ein paar Beispiele zu machen. Die grundlegende Seitenstruktur kann man mit ids auszeichnen. Also so ein <div id="navigation">. Im Inhalt verwendet man meistens nur class, also zum Beispiel ein <div class="blogpost">.

Im CSS benutzt man dann "#" für ids und "." für classes
#navigation {border: 4px solid orange}
div.blogpost {background-color: #ccc;}


In dem ein oder anderen Browser kann man im Javascript auch die id verwenden. Verlassen würd ich nicht darauf. Das hier war wirklich kompletter Blödsinn. getElementById ist die richtige Methode. Peinlich peinlich. Danke Dunkelstern für den Hinweis...

Donnerstag, August 25

 

HTML Grundlage

Für eine neue Seite fange ich normalerweise bei Null an. Also mit einer leeren HTML Seite. Der Grundlegende Aufbau ist immer derselbe. Dieses Problem der grundlegenden Struktur einer Website kann man einmal und für immer lösen.

Eine Seite besteht grundlegend aus vier Elementen.
  1. Header
  2. Content
  3. Navigation
  4. Footer
Und zwar in dieser Reihenfolge! Meistens will man die Navigation über oder links vom Inhalt haben, aber das ist Layout nicht Inhalt. Für Blinde oder Textbrowser ist es sehr viel angenehmer, wenn erstmal der Inhalt kommt. Per CSS kann man die Navigation dann immer noch positionieren, wo wann man will. Aus demselben Grund sollte man auch den Header so schlank wie möglich halten. Titel und Untertitel sollten meistens reichen.

Deswegen besteht die Grundseite aus vier div-Containern:
<body>

<div class="header">
beza1e1 on line
</div>

<div class="content">
blablabla
</div>

<div class="navigation">
<ul>
<li><a href="start">Startseite</a></li>
<li><a href="blog">Blog</a></li>
</ul>
</div>

<div class="footer">
by beza1e1
</div>

</body>
Layout wird mit CSS realisiert. Unser HTML soll semantisch sein. Das bedeutet: Wir schreiben es entsprechend der Bedeutung, nicht nach dem Aussehens.

Nun kann man mit etwas CSS das ganze ins klassische Layout bringen, mit der Navigation auf der linken Seite.
#content { margin-left: 200px }
#navigation {width: 190px; position: absolute; top: 20px; left: 5px; }
Warum die Navigation als Liste markiert ist? Naja, es ist eine Liste von Links, oder? Per CSS kann man die bullets verschwinden lassen, dann merkt's keiner. Ein weiterer Vorteil zeigt sich, wenn man ganze Hierarchien von Links anzeigt. Eine Liste in einer Liste wird ordentlich eingerückt. Das ist allerdings vor allem für CMS interessant und nicht für kleine Websites.

Header und Footer sind natürlich mehr oder weniger optional. Aber bisher habe ich eigentlich auf jeder Website beide gebraucht.

Ich habe auf anderen Seiten auch von Dingen wie subnavigation und subcontent gehört, aber bisher habe ich das nicht gebraucht. Elemente wie ein Suchfeld, Blogroll, Shoutbox und Ähnliches sollte man in einen der vier Container packen. Das macht für die Positionierung am meisten Sinn.
 

Webdesign in kleinen Happen

In diesem Blog will ich mal so mit der Zeit sammeln, was ich vom Webdesign verstehe. Immer in kleinen, leicht verdaubaren Häppchen, so dass ein kleine Sammlung von netten HowTos entsteht.

Thematisch solls um Webdesign in allen Facetten gehen. Vor allem ums Layout, also zum Beispiel CSS, Wahrnehmungspsychologie, AJAX oder Farben. Aber ich werde mir wohl kaum den ein oder anderen Ausflug ins Technische nehmen lassen. Ein paar Tritte gegen den IE und ein paar Kommentar zu verschiedenen CMS.

Was ich versuchen will hier raus zu halten sind Programmiersprachen (Python, Lisp, Ruby) oder Open Source Ideologie. Aber das wird wohl nicht so einfach ... wir werden sehen.