Webdesign - Tips und Tricks

• Home
• Software
• Webdesign
  • Referenzen
  • HTML-Notizen
• News
• Über uns
• Impressum

Tips und Tricks rund um HTML und CSS

Hier soll im Laufe der Zeit allerlei Nützliches rund um Webdesign, HTML und CSS erscheinen. Direkte Links zu allen Artikeln finden Sie hier:

Aus dem Alltag

Quirks... aber richtig! (28. November 2008)

Microsoft ist schon wirklich putzig: Da schimpft man jahrelang auf die mangelnde Konformität zu Standards (das Box-Modell ist nur ein Beipiel), und dabei haben sie es schon längst korrigiert! Man merkt es nur nicht, denn... sie haben gleich einen neuen Fehler mit eingebaut. Wie ich neulich schon mal sagte: Sie konnten (oder wollten) nicht einfach die Fehler abstellen, denn dann wären ja Millionen von Seiten im IE falsch dargestellt worden. Der Weg, den sie sich ausdachten, war der einer Modus-Steuerung.

Der IE kennt ab Version 6 zwei Arten, HTML und CSS zu interpretieren: Zum einen den "Quirks-Mode" (Macken, Eigenheiten), der sich verhält, wie der IE sich immer verhielt - fehlerhaft. Zum anderen einen "Strict-Mode", der sich strikt an Standards halten soll. MS nennt das Standard Compliance Mode: "Hey, schaut her, ich habe ein Rechtschreibprogramm geschrieben, das sich jetzt sogar an die Rechtschreibregeln hält." Aber so weit, so gut. Bis hierhin war mir das bekannt. Da ich schließlich meine Seiten standardkonform baue, ging ich davon aus, daß er es eben einfach nicht packt, auch nicht im "Strict-Mode".

Aber der Fehlererfindungsgabe von Microsoftentwicklern sind wirklich keine Grenzen gesetzt. Was mir nämlich nicht klar war: Gerade weil ich meine Seiten standardkonform schreibe, schalteten alle IEs in den Quirks-Mode. Klingt nicht wirklich logisch? Ist es auch nicht. Was sich Microsoft ausgedacht hatte, war folgendes: Wenn der IE eine gültige DOCTYPE Definition vorfindet (es gibt bei Microsoft eine Liste, die die DTDs auflistet, die sie haben wollen), dann verhält der IE sich standardkonfrom, sonst eben "mackig". So weit, immer noch gut. Was sie aber nicht erwähnen: Der IE erwartet die DTD-Deklaration in der ersten Zeile der Seite. Und das ist eben leider ganz und gar nicht standardmäßig in XHTML, denn dort soll eine XML-Stylesheet Deklaration stehen, und keine HTML-Deklaration (der Standard ist hier nachzulesen).

Wirklich toll: Weil meine Seiten sich an den Standard hielten, hielt sich der IE nicht daran. Auf die Idee konnte wirklich nur Microsoft kommen. Wohlgemerkt: das ist zumindest für den IE6 gültig, beim IE7 bin ich mir nicht sicher. Da sollte ihnen die Spezifikation von XHTML 1 eigentlich schon geläufig gewesen sein. Aber was tun? Da oben in den Kopf kann man ja keine IE-Abfrage hineinschreiben. Ich habe die XML-Deklarationen versuchsweise entfernt, und sofort verhielt sich der IE standardkonform (d.h., daß zum Beispiel meine Menüs zu breit waren :-), sogar der IE6 kann nun z.B. mit "Position: fixed" umgehen. Und was sagt das W3C dazu? Ich habe zwar noch keine Aussage gefunden (wird nachgereicht, wenn ich was finde), aber der Validator meckert immerhin nicht. Aber das könnte natürlich auch einfach heißen, das dort etwas "softer" Druck ausgeübt wurde... Keine Ahnung. Jetzt, wo ich auf das Problem gestoßen bin, finde ich plötzlich immer mehr Dokumente dazu. Ich werde die Liste unten entsprechend ergänzen.

p.s.: Hmm, daß sogar der IE6 schon "fixed" versteht, bringt mich doch gleich auf neue Ideen... :-)

Best Viewed with Any Browser (26. November 2008)

Die schönste Variante des Slogans ist: "Best viewed with a brain!". Oder: "Best viewed with eyes!" Aber das würden viele Menschen sicher nicht verstehen. "Best viewed with any browser" drückt am verständlichsten die Grundabsicht des barrièrefreien Webdesigns aus, daß jeder Browser benutzbar sein soll. Dazu gehören schließlich nicht nur der von uns so geschätzte Lynx, sondern auch Leseprogramme und Braillezeilen. Das darf man nicht vergessen.

"Best viewed with any browser" soll also einfach die Bemühung ausdrücken, eine Website so "accessible", so barrièrefrei wie möglich gebaut zu haben. Bei uns hier gehört dazu mindestens immer der Test mit Lynx, dem Textbrowser. Wenn eine Site damit sch... "schön ist anders" aussieht, muß sie dringend überarbeitet werden. Hier geht's zur Kampagne "Viewable with any Browser". Empfehlenswert ist der "Design Guide".

Ich selber kann jedem, gleich, ob er sich als Web Designer oder als HTML Autor versteht, nur dringend an's Herz legen, zumindest hin und wieder mal Lynx zu benutzen - man bekommt ihn hier. Und dann natürlich sich damit die eigenen Webseiten anzusehen. Wenn der Autor keinen Herzinfarkt bekommt, hat er seine Sache gut gemacht!.

HTML verbessert (22. November 2008)

Ich habe nie verstanden, warum in HTML einige ganz einfache und in den meisten Programmiersprachen vorhandene Features fehlen. Der Dateiimport zum Beispiel. Und außerdem die Möglichkeit, Variablen oder Makros zu definieren. Damit wäre das Leben des Webseitenbauers schon um ein gut Stück leichter. Dann dachte ich mir lange: Gut, wozu gibt es Werkzeuge wie AWK oder Perl, sowas mußt Du Dir eben selber schreiben, als Präprozessor - also ein Programm, das eine Eingabedatei nach bestimmten Regeln bearbeitet und daraus, in diesem Fall, eine HTML Datei erzeugt.

Aber da es nun einmal Blödsinn ist, das Rad erneut zu erfinden, habe ich mich mal auf die Suche begeben, und bin auch reichlich fündig geworden. Ich habe mich schließlich für GTML entschieden, vor allem, weil es einfach ein Perl-Script ist, das ich bei Bedarf anpassen kann - und werde. Es entbindet einen nicht davon, ordentliches HTML selber zu schreiben, aber es ergänzt genau die Möglichkeiten, die ich oben als fehlend moniert habe.

Die aktuelle Seite stellt sich beispielsweise folgendermaßen dar:

				
## GTML ######################################################
#define DOCTYPE strict
#define PAGE DE_WEBDESIGN_TIPSNTRICKS
#define WINDOWTITLE PSK Berlin: Webdesign - Tips und Tricks
#define PAGETITLE Webdesign - Tips und Tricks
#define AUTHOR Stefan Knoche
#define PAGELANG de
#define KEYWORDS Stefan Knoche [...]
#define PAGE_AD YES
#define PAGECONTENT "content/de-webdesign-tipsntricks-content"
#define PAGE_EN en-webdesign-tipsntricks.html
#define PAGE_DE de-webdesign-tipsntricks.html
#define PAGE_TIME <<MTIMESTAMP>>
	
#include "general.itml"
#include "head-doctype.itml"
#include "head-head.itml"
#include "body-header.itml"
#include "body-menu.itml"
	
## CONTENT ###################################################
<div id="Content">
#include <<PAGECONTENT>>
</div>
## CONTENT ###################################################
#include "body-footer.itml"
## END #######################################################
				
			

Hier werden verschiedene Variable (Verzeihung: Makros :-) definiert, die in importierten Dateien verwendet werden, sodann diese Dateien importiert, die ihrerseits die allgemeinen Bestandteile einer Seite darstellen - der komplizierteste Teil hier ist das Menü, für das ich noch eine eigene Funktion entwickeln werde - und schließlich eine Datei, in der der eigentliche Inhalt der Seite steht ("Content"). Und das war's. Wenn das ganze System erst einmal aufgesetzt ist (und das muß man selber machen, das nimmt einem kein Wizard ab!), kann man die Content-Seiten jederzeit bearbeiten und ganz schnell eine aktuelle Version der Seite zusammenbauen und hochladen.

Zusammenbauen wie? Na, die Antwort ist dieselbe seit 14/18: Make! Man schreibt ein Makefile, das alle Abhängigkkeiten zwischen GTML-File, Include-Files (ich nenne sie ITML), und Contentfiles beschreibt, die notwendigen Schritte, um daraus HTML-Files zu erzeugen, sowie entsprechende Befehle, die fertigen Dateien auf lokale oder öffentliche Webserver hochzuladen... und das war's. Inhalt ändern, auf der Konsole "make upload" eingeben, fertig!

Der Befehlsvorrat ist nicht groß, aber so ziemlich genau das, was HTML fehlt. Sicher, ich könnte mir das eine oder andere denken, das auch noch nützlich oder nett wäre

(wird fortgesetzt...)

Schelten, wem Schelte gebührt! (21. November 2008)

Obwohl Firefox mein Leib- und Magenbrowser ist, muß ich doch auch mal meinen Ärger über übereifrige Entwickler Luft machen. Manchmal ist weniger einfach mehr!

Sicher kennen viele auch diese Situation: Man arbeitet regelmäßig an verschiedenen Standorten, die zwar im selben Netzwerk sind, aber wegen der Bandbreite der Verbindung lokale Profile (ja, ja, unter Windows :-) verwenden. Das heißt natürlich, daß alle Programme, die ihre Konfiguration und anderes im Profil ablegen, an den verschiedenen Standorten notorisch unterschiedlich konfiguriert sind. Oder: Man arbeitet mit verschiedenen Betriebssystemen, möchte aber dieselbe Konfiguration benutzen. Oder: Viele Benutzer sollen stets auf ein und dieselbe Konfiguration zurückgreifen.

Am wenigsten Probleme hat man mit Programmen, die völlig altmodisch Konfigurationsdateien verwenden. Man stellt sie einfach so ein, daß sie auf eine ".ini" oder "....rc" oder ".conf" zum Beispiel im eigenen Homedirectory zugreifen: Fertig der Film! INI-Dateien in all ihren Ausprägungen sind mir vor allem deshalb bei weitem meine Favoriten; ganz besonders schlimm ist es mit Windows-Programmen, die jeden Müll in die Registry schreiben wollen. Nicht nur, weil das bei weitem die unflexibelste Lösung ist (gut, daß hier niemand Kommentare abgeben kann :-), sondern auch, weil man den Kram nie wieder vollständig rausbekommt.

Mit dem Stichwort "Favoriten" war ich schon fast beim Grund meines Ärgers, war nur nochmal kurz abgeschweift. Es geht nämlich um die Bookmarks bei Firefox. Seit Urzeiten legen alle Mozilla-Browser ihre Bookmarks in "bookmarks.html" ab. Bei den neuesten Mitgliedern der Gattung steht die zwar defaultmäßig irgendwo unter "Documents and Setting/User/Application Data", aber man kann den Platz ja ebensolange frei ändern - im Firefox zwar nur noch über "about:config", aber immerhin. Wen's interessiert: "browser.bookmarks.file" einfach auf einen genehmen Ort setzen, z.B. "H:\.firefox\bookmarks.html". Damit hatte ich den Platz sehr bequem auf eine Datei in meinem Homedirectory geändert und lebte glücklig und zufrieden.

Bis die Version 3.0 herauskam. Da glaubten die Entwickler, man müsse Windows alles nachmachen und Konfigurationen in Datenbanken speichern (deren Inhalte man dann natürlich, getreu dem Vorbild, alle naselang verliert). Also benutzen sie jetzt eine Datenbankengine namens SQLite (soweit ich mich erinnere - denn als ich das genauer recherchierte, konnte ich schon keine Bookmarks mehr benutzen, so daß ich mir die Fundstellen nicht gemerkt habe). Diese Engine speichert alle Verlaufsinformationen in einer tollen Datenbank - natürlich im Profile-Folder!!! Die Argumente der Entwickler sind, daß das neue System "performanter" sein; als ob Performance ein Kriterium wäre, wenn alle fünf Minuten mal eine Bookmark geschrieben oder gelesen werden muß!

Ich bin ja nicht der einzige, den dieser Schwachsinn stört: Hier gibt es einen Einstieg in die Diskussionen (ich nehme an, Google hilft noch weiter). So weit ich das bisher sehe, ist der einzige Vorteil dieser "Erungenschaft", daß ich jetzt, wenn ich mich dazu entschließe, die Bookmarks wieder zu verwenden, immer morgens und abends die Bookmarks importieren und exportieren darf - von Hand, versteht sich. Super! Das nenne ich Fortschritt!

Was lernen wir daraus? Nicht alles, was jemand als "Fortschritt" bezeichnet, sollte ernst genommen werden. Hat jetzt jemand "Web 2.0" gerufen???

Ein Gottesgeschenk für Webentwickler (6. November 2008)

Nein, ich meine jetzt nicht das Wahlergebnis von gestern! Ja, ich freue mich ja auch darüber, vor allem für meine amerikanischen Freunde und Verwandten. Aber wir sollten nicht sämtliche Heilserwartungen in den armen Mann projizieren, die sich in den letzten 2000 Jahren angesammelt haben. Am Ende des Tages ist auch er vor allem eines: Präsident der USA, und als solcher Beschützer ihrer Interessen, nicht unserer!

Okay, das war nicht das Thema. Es geht um ein Gottesgeschenk für Webentwickler! Ich vermute, jeder, der Webseiten schreibt (wie auch immer), weiß, daß Firefox wesentlich standardkonformer ist als Microsofts Internet Explorer und ihn deswegen häufiger oder sogar ausschließlich benutzt (sollte man nicht machen, denn die Benutzergemeinde des IE ist immer noch größer, wenn auch stark rückläufig).

Ich selber benutze hauptsächlich Firefox, obwohl ich natürlich auch den IE noch installiert habe, um die Darstellung von Webseiten überprüfen zu können. Aber was Firefox für Webentwickler wirklich unübertrefflich macht, ist ein Add-In namens Firebug.

Firebug ist ein Werkzeug zur Quelltextanalyse, macht aber viel mehr als "View Source Code". Er öffnet in der unteren Bildschirmhälfte ein geteiltes Fenster, in dem sowohl HTML als auch das dazugehörige CSS begutachtet werden können. Wer jemals wissen wollte, warum - Gottverdammmich - dieser Absatz völlig falsche Ränder hatte: Hier wirst Du geholfen! Für mich inzwischen unverzichtbar, vor allem zum Debugging eigener Seiten, aber auch zum Stillen der Neugier: "Wie hat der hier die Menüs gemacht?" Wen auch die Neugier überkommt: Unten auf der Seite ist der Link.

Neues und nicht so Neues (4. November 2008)

Lange hat sich hier nichts getan, weil ich mit einigen anderes Dingen beschäftigt war. Aber jetzt war es an der Zeit, einige Fehler und "loose ends" auf dieser Site zu berichtigen. Kein "Re-Launch", nur Fehlerkorrektur. Das alte Design war mir ein wenig zu unaufgeräumt und, um der Wahrheit die Ehre zu geben, die Site hat auch eine ganze Weile ziemlich unbeachtet zugebracht.

Nun, dem sollte abgeholfen werden. Ich habe inzwischen eine andere Site entworfen, deren Menügestaltung mir gefiel, und die wollte ich für meine adaptieren. Das Problem, das natürlich erneut sein widerliches Haupt erhob, war das Box-Modell. Ich habe mich inzwischen überzeugen lassen, daß das W3C die Box definiert als "Margin+Border+Padding+Width". Das erschien mir zwar immer unlogisch (weil "Padding/Ausfütterung" schließlich INNEN ist), aber bitte, wenn's denn der Definition entspricht und der Wahrheitsfindung dient...

In diesem Fall liegt dann Microsoft mit seiner Interpretation (in Stein gehauen im Internet Explorer) wohl wirklich schief. Aber ich kann ihr Dilemma verstehen: Wenn sie jetzt den Fehler korrigieren, dann werden Millionen von Webseiten im IE falsch dargestellt, weil alle Welt inzwischen über Browserweichen diesen Fehler berücksichtigt hat.

Also habe ich in den saueren Apfel gebissen und ein eigenes Stylesheet für den IE angelegt, in dem diese Fehlinterpretationen korrigiert werden. Immerhin bietet der IE dafür ein insofern standardkonformes Instrument, als daß er die "IE-Abfrage" in einem Kommentar erwartet, also

	
	<!--[if IE]>
		<style
			type="text/css"
			media="all"
			id="SiteStyle-IE">
			@import "styles-2.1-ie.css";
		</style>
	<![endif]-->
	
	

Standardkonform? Nun ja, das ist zwar eine IE-Erfindung, aber sie steht in einem Kommentar, wird also von nix und niemandem sonst interpretiert. Und ich kann mich darauf verlassen, daß der IE sie interpretiert. Wenn ich sie dann auch nur für den IE benutze... nun ja, nicht Standard, aber mit allen anderen kompatibel.

Dort werden dann all die Angaben für den IE aufbereitet, in denen sowohl (z.B.) "width" als auch "padding" verwendet werden. Aber auch nur die!

Wie gesagt, ich verstehe schon das Dilemma, in dem Microsoft steckt. Ihre einzige Möglichkeit wäre es, den IE irgendwann komplett standardkonform zu machen (bzw. seine Interpretation denen der anderen anzupassen) und dann die Auswertung dieser Anweisung wegzulassen. Aber das ist wohl nicht zu hoffen. Wie ich gehört habe, haben sie schon wieder neue Eigenschaften eingeführt, die sonst kein Browser kennt (rund Ecken von Boxen z.B.). Also weiter wie gehabt.

To fix or not to fix (3. August 2007)

Ich war zwar immer ein Freund von Frames, weil sie es einfach machten, z.B. ein Menü oder einen Seitenkopf an der gleichen Stelle zu haben, aber ich habe mich überzeugen lassen, daß man aus Gründen der Darstellung und des Bookmarkens (schönes Wort, gell?) darauf verzichten sollte.

Nun gibt es ja inzwischen für Blockelemente das Attribut "Position" mit den möglichen Eigenschaften: "Static", "Relative", "Absolute" und "Fixed". "Fixed" meint: auf der Seite an einer Stelle fixiert. Nun erinnerte ich mich, daß der IE6 das noch nicht interpretierte, aber ich wollte es noch einmal ausprobieren, denn das ist schließlich genau das richtige für feststehende Navigationselemente.

Gesagt, getan: Firefox interpretiert es richtig, wunderschön. Und IE6? Er interpretiert es garnicht, sondern nimmt stattdessen "Static", den Default, schließt also einfach an das vorhergehende Element an. Was also tun?

Zwei Möglichkeiten: Entweder weist man dem übergeordneten Element die Eigenschaft "Absolute" zu, oder man deklariert für die Menübox selber hintereinander zweimal das Attribut "Position", einmal "absolut", danach "fixed". Natürlich in der Hoffnung, daß der IE, wenn er "fixed" nicht kennt, auf die vorher deklarierte Eigenschaft zurückfällt.

Ich habe beides versucht, ohne Erfolg. Weitere Ideen, dem IE wenigstens die gewünschte absolute Position zuzuweisen, wenn er schon "Fixed" nicht interpretiert, habe ich nicht. Ich habe es mit IE7 noch nicht probiert, soll angeblich gehen, aber der IE6 ist noch zu verbreitet, um ihn auszuschließen. Daraus ergibt sich leider, für den Moment:

Don't fix it!

Zum Anfang (23. Juli 2007)

Hier sollen nach und nach Probleme und Lösungen aus dem Alltag (und für den Alltag) eines Webautor erscheinen. Die Form soll die eines Weblogs (vulgo: Blog) sein, und zwar in seiner inzwischen fast vergessenen Urform: Einer schreibt, die anderen lesen, aber müssen die Klappe halten, weil es keine Möglichkeit gibt, Kommentare zu hinterlassen. Also in reiner Textformn - was momentan auch juristisch betrachtet in Deutschland sicherer zu sein scheint.

Nun werden die meisten Dinge, die mir hier einfallen, sicher keine großen Neuigkeiten für die Gemeinde eingefleischter Webautoren sein - vielleicht nicht einmal für mich - aber wenn der eine oder andere Tip nur ein oder zwei Leuten weiterhilft, dann ist das doch schon was, oder?

Links zu HTML und CSS

Hier ist ein schönes Beispiel von "Work in progress": Eine völlig chaotische unfertige Tabelle. Ich stelle eigentlich wieder mal fest, daß sich der Aufwand einer Tabelle nur selten lohnt; eine UL ist allemal simpler, und schließlich soll das Verfassen des Inhaltes der eigentliche Zweck einer Website sein. Man vergleiche nur den Aufwand für die Tabelle unten mit der Liste im Kopf der Seite, die hierherführt! Aber bestimmt fällt mir bald was Nettes ein.

  Copyright © 2006-2007 Stefan Knoche - Kontakt / Impressum

Anzeigen