Ruby lässt einem alle Möglichkeiten offen, das zu tun, was man möchte (oder muss). Es ist durchaus möglich, jede andere Klasse gründlich zu untersuchen und zu verändern. Ich meine nicht, dass man sich den Quellcode anschaut. Das ist natürlich auch möglich, aber offensichtlich kein Sprachfeature. Vielmehr kann man zur Laufzeit eine beliebige Klasse nach den vorhandenen Methoden fragen und diese sogar ändern. Meist braucht man das nicht, aber das man so weit gehen kann, führt dazu, dass insbesondere einfachere Dinge ebenfalls möglich sind.

Wenn ich eine Sekundenzahl in eine Zeichenkette der Form HH:MM:SS bringen will, kann ich entweder eine Hilfsfunktion schreiben, der ich die Sekunden übergebe und die mir dann die formatierte Zeit zurückgibt. Oder ich erweitere die Klasse Integer, in der die Sekunden gespeichert werden, so, dass diese Klasse eine entsprechende Methode dafür anbietet. Ich will nicht darüber diskutieren, welcher Weg besser ist (oder ob man es so machen muss, dass man dafür extra eine Subklasse von Integer definiert). Alleine, dass man die Wahl hat, finde ich gut.

Interessant wird es jetzt genau ab dem Punkt, an dem man diese Wahl trifft. In vielen anderen Sprachen gibt es einen „richtigen“ Weg, diese Entscheidung zu treffen. In Ruby treffe ich sie alleine anhand der tatsächlichen Anwendung. Und aufgrund der tatsächlichen Erfahrung ändere ich sie vielleicht wieder. Die Programmiersprache steht mir dabei aber nie im Weg.

Versionskontrolle hat nämlich mehrere nützliche Aspekte. Eine Versionsverwaltung wie Subversion ermöglicht es,

* von mehreren Standorten (oder Rechnern) aus und
* mit mehreren Personen an den gleichen Dateien zu arbeiten.

Dabei greifen alle auf das gleiche „Archiv“ zu. Jede Veränderung wird als eine neue Version (oder auch Revision) gespeichert, meist zusammen mit Informationen darüber, wer was wann gemacht hat.

Programmieren möchte ich so ein System nicht, aber es zu verwenden ist wirklich leicht und hat mir seither einige Kopfschmerzen erspart. Ich mache mir jetzt weniger Sorgen, wenn ich etwas verändere, denn die alte Version ist ja noch sicher gespeichert. Außerdem kann ich so recht einfach von mehreren Standorten meine Veränderungen abrufen und speichern.

Es lohnt sich also auch für den „Einzelkämpfer“, sich damit auseinanderzusetzen. Und damit meine ich durchaus auch reine XHTML/CSS-Webdesigner, die wenig bis gar nicht programmieren. Versionskontrolle verwaltet grundsätzlich alle Arten von Dateien. Besonders effizient und speicherschonend arbeitet es allerdings mit Textdateien.

In den nächsten paar Beiträgen erzähle ich ein wenig von der Installation, ersten „Inbetriebnahme“ und der täglichen Arbeit mit Subversion.
Wer sich vorab selbst informieren möchte, sei auf das (englisch-sprachige) „Handbuch zu Subversion“:http://svnbook.red-bean.com verwiesen. Das Handbuch selbst wird übrigens auch mithilfe Subversion „versionsverwaltet“.

Bleibt nur noch die Frage, wie man „Subversion“ „ausspricht“:http://svn.collab.net/repos/svn-committers/trunk/sounds/pronunciation/index.html…

Meine letzte Anschaffung war ein Buch über Ausdrücke. Damit, dachte ich mir so, beeindrucke ich dann meinen Rechner und beleidige ein paar Passanten. Dummerweise habe ich mir das Buch in der Computerabteilung der Buchhandlung ausgesucht. Abgesehen davon, dass die EDV-Abteilung zu klein war (ist sie irgendwie immer…) hatte das den Nebeneffekt, dass ich jetzt nicht fluchen, sondern Zeichenketten beschreiben kann.

h3. Probleme und Lösungen

Man sagt über reguläre Ausdrücke (regex), dass sie einem auf den ersten Blick wie die optimale Lösung erscheinen, später aber leicht zu einem eigenständigen Problem heranwachsen können.

Nachdem ich mir die Kurzreferenz durchgelesen habe, habe ich den gleichen Eindruck. Gerade fortgeschrittene Beispiele sind so komplex, dass man schnell den Überblick verliert.

Dabei ist es anfangs ganz leicht: Bei der Überprüfung von Formulareingaben weiß ich, dass die Eingaben einem bestimmten Muster folgen sollten. Telefonnummern sehen doch immer gleich aus, oder? Also versucht man, mithilfe einer regex Telefonnummern zu beschreiben. Wenig später ist man dann soweit, einfach alle Zahlen und einige Sonderzeichen zuzulassen und gibt weitere Strukturmaßnahmen auf. Benutzereingaben können enfach sehr unterschiedlich sein.
Das ist dann der Punkt, an dem man sich wieder auf konventionelle Ausdrücke zurückzieht.

Anders ist es, wenn man z. B. eine e-mail-Adresse auf Gültigkeit prüfen möchte. Da die mail-Adresse von vorneherein einem festen Schema folgt, kann man dieses auch recht genau prüfen. Man muss einfach nur die Regeln, die gelten, als regex ausdrücken und darauf prüfen.
Anfangs habe ich nur auf das vorhandensein von @ geprüft, später kamen dann noch Beschreibungen für die Zeichen davor und danach usw usf. Irgendwann habe ich dann im Internet nach anderen regexen für diesen Zweck gesucht und mein Suchergebnis dann noch ein wenig angepasst.

Das eingangs erwähnte Buch bietet zwar nur eine Syntaxreferenz, was aber für die praktische Arbeit durchaus ausreichen kann. Wenn man weiß, was man erreichen möchte (z. B. eine mail-Adresse überprüfen), dann ist „Reguläre Ausdrücke – kurz & gut“ aus dem O’Reilly-Verlag eine gute Wahl.
Mit ein wenig Vorwissen, das man zum Beispiel durch die Anwendung von „mod_rewrite“:http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html sammeln kann, ist es eine angenehme Hilfestellung.

Nur fluchen lernt man durch das Buch nicht. Verdammt.

h3. Codebeispiele

Nur Ziffern und einige Sonderzeichen, die in Telefonnummern üblicherweise zu finden sind, alles in beliebiger Anzahl.

$regex = '{[- 0-9()/+\.]*}';

Beispiel-Regex für eine e-mail-Adresse.

$regex = '/^';
$regex .= '([A-Za-z0-9](([\w.-][^._-]*){0,61})[A-Za-z0-9])@([A-Za-z0-9]([A-Za-z0-9-]{0,61})?[A-Za-z0-9]\.)+([A-Za-z]{2,6})$/';

[edit – 20051231-1502] e-mail-regex angepasst (mein Textile-Plugin hat sie zerstört). Bitte auch Kommentare beachten.

In PHP ist u. a. die Funktion „@preg_match@“:http://www.php.net/preg_match für einfach Vergleiche zuständig. In JavaScript haben String-Objekte @search@- und @replace@-Methoden, die mit regex arbeiten.

Diese PHP-Codebeispiele können gerne weiterverwendet werden, natürlich ohne Garantie auf Erfolg oder Gewährleistung.

Mein derzeitiger Ansatz, mein CMS umzusetzen ist daher erstmal recht angenehm. Grundsätzlich kann das CMS zwar ein paar Sachen, nur eben mit Inhalten umgehen kann es nicht. Es besteht aus ein paar Klassen, die mir solche Basisfunktionalitäten wie Analyse der URL, Datenzugriff, Darstellung der Daten usw. ermöglichen.

Die tatsächlichen Strukturen sind dabei noch gar nicht festgelegt. Bislang ist es nur ein objektorientierte Rahmen, der auf dem MVC-Designprinzip basiert. Alle konkreten Funktionen werden in diesen Rahmen eingebunden.

Inspiriert wurde mein Vorgehen vom Erfolg, den „RubyOnRails“:http://www.rubyonrails.com/ derzeit feiert. Dabei habe ich mich kurz umgeschaut und dann meine Verzeichnisstruktur nach der von RoR ausgelegt. Prinzipiell mag das in Ordnung sein, tatsächlich dann aber eben doch nicht. Jedes Modul besteht aus einer Controllerklasse, einer Modelklasse und ein paar View-Dateien.

h3. Struktur

Ich habe die Begriffe anfangs nur übernommen ohne sie zu verstehen. Meine jetzige Aufteilung auf die entsprechenden Klassen ist für mich logisch, kann jedoch vom ursprünglichen Konzept abweichen.

Der Controller enthält größtenteils Steuerinformationen, gegliedert nach Aktionen wie view, edit und delete. Die model-Klasse ist für mich ein Container für die Templatetags wie get_title, get_content usw.

Da nun jedes Modul auf jeden Fall genau einen Controller und ein Model beinhaltet ist es jedoch eher kontraproduktiv, ein Modul auf

* drei Verzeichnisse und
* zwei Steuerdateien

zu verteilen.

Je ein Verzeichnis enthielt die Controller- und die Model-Dateien. Das dritte Verzeichnis enthält die View-Dateien, aus denen dann die tastächliche HTML-Seite zusammengesetzt wird. Konkret habe ich ein oder zwei Haupttemplates und mehrere Untertemplates, für jede Aktion eines.

h3. Optimierung

Bei Seitenraufrufen sucht das PHP-Skript immer nach verfügbaren Modulen und bindet die entsprechenden Dateien per „require_once“:http://php.net/require_once ein.

bq. Jeder @include@ kostet Zeit…

Naja, hier kann man dann Zeit und Ressourcen sparen. Durch eine Zusammenfassung aller Klassen eines Moduls in einer Datei wird eine von zwei Schleifen überflüssig. Zwei Schleifen? Ja, ich habe einmal nach Controllern und einmal nach Model-Klassen gesucht. Danach habe ich jede gefundene Datei eingebunden.

Eine der beiden Schleifen ist jetzt wegfallen. Das Datenvolumen wird in etwa gleich bleiben, aber die Dateisystemzugriffe gehen ziemlich zurück. Der beste Weg eine Schleife zu optimieren ist wohl immer noch, sie einfach überflüssig zu machen und zu löschen.

Den Umfang, den die Vorabplanung einnimmt, kann man schlecht vorhersagen. Ich konnte mir bisher nur sicher sein, dass so oder so zu wenig vorab geklärt wird. Größtenteils dürfte es an der Unerfahrenheit der Beteiligten liegen.

Jede Veränderung nach der Vorplanung resultiert in zigtausend kleinen Patches, die erstmal das Problem lösen aber dadurch das nächste Problem sind. Meine Antwort auf dieses Problem, dass Projekte komischerweise während der Enwicklung weiterwachsen, war bisher, regelmäßig Pausen für die komplette Neuformulierung und Neustrukturierung des Codes einzuplanen.

Dieser Ansatz ist natürlich anstrengend und in höchstem Maße ineffizient.
Also anders. Besser.

h3. geplante Programmierung

Ich gebe zu, dass ich bis vor kurzem noch nicht mit dem Konzept der Objektorientierung im Webbereich klar kam. OOP schien die Lösung für 80% meiner Probleme zu sein, aber ich konnte mir das Konzept nur im Desktopbereich sinnvoll vorstellen. Dass es anders möglich ist, beweist die Realität, in der es WebApps gibt, die objektorientiert funktionieren.

(Wem OOP nichts sagt, sei an die Wikipedia verwiesen: „Objektorientiere Programmierung“:http://de.wikipedia.org/wiki/Objektorientierte_Programmierung)

Kern der Objektorientierung ist aus meiner Sicht, dass ich eine Klasse von Objekten einmal definiere, mit Variablen (genannt Eigenschaften) versehe und die entsprechen Funktionalitäten als Methoden einbaue (wenn wir Vererbung hier erstmal außen vor lassen). Alle neue Objekte sind dann nur Instanzen dieser Klasse. Der Geschwindigkeitsvorteil, der daraus entsteht, dass eine bereits definierte Klasse mehrfach aufzurufen ist, ist in Skriptsprachen besonders wichtig.
In Desktopprogrammen ist es auch garnicht so schwer, da alle Daten bereits beim Programmstart in die entsprechenden Objekte gegossen werden können. Da erstelle ich einfach so viele Objekte wie nötig. Da die zugrundeliegenden Klassen bereits im Speicher vorliegen geht es recht schnell. Es entsteht so gut wie kein Overhead, nur der Datenzugriff kostet ein wenig Zeit.

In einer PHP-Umgebung lade ich allerdings niemals alle Daten bei einem Seitenbesuch. Das wäre Wahnsinn, da PHP-Skripte bei *jedem Seitenaufruf* komplett neu durchlaufen werden. Caching ist ja, da Zend Technologies das kommerziell vertreibt, erstmal nicht vorhanden (Anm.: Das ist „nicht die ganze Wahrheit“:http://www.php.net/manual/en/ref.apc.php). Sessions, die beispielsweise Variablen halten können, weichen dies ein wenig auf, verändern am Prinzip der Einmaligkeit der Ausgaben aber nichts.

Trotzdem bietet OOP auch für den Webbereich etwas. Auf den ersten Blick sind PHP-Klassen nämlich einfache und übersichtliche Funktionssammlungen und alleine dadurch schon sehr praktisch. Die daraus resultierende Wiederverwendbarkeit zeigt sich zwar erst mit der Menge der Projekte, aber das wird jeder selbst erfahren. Mein Tipp: *Versucht Abläufe so abstrakt und parametisierbar wie möglich zu coden*. (Da das für jeden Programmierer selbstverständlich sein sollte, ist das mehr ein Erinnerungszettel für mich.)

Vererbung, eine weitere wesentlichen Eigenheit von Klassen, ist da schon ein wenig mächtiger. Ich weiß, ein paar Absätze weiter oben wollte ich das noch nicht beachten. Aber wie das so ist… Für PHP-Hacker lautet das Stichwort „extends“:http://www.php.net/extends. Unterteilt man die Methoden (Funktionen) einer Klasse intelligent oder wenigstens pragmatisch auf mehrere Klassen, die hierarchisch voneinander abhängig sind, sind Erweiterungen auf verschiedenen Ebenen der Verzweigung einfach möglich. Das vereinfacht dann wiederum die Wiederverwendbarkeit und hilft, die Programmabläufe weiter zu abstrahieren.

Zu theoretisch? Naja, dann eben…

h3. praktisch formuliert

Wenn man beispielsweise ein CMS schreibt, dass an verschiedenen Stellen Templatetags verwendet, könnte man einerseits diese Templatetags als Methoden zu der entsprechenden Klasse hinzufügen und weiterhin die gemeinsamen, allgemeineren Methoden in eine extra Klasse schreiben, die dann

* zentral dokumentiert wird,
* zentral erweitert werden kann,
* zentral als Datei gespeichert wird.

Diese zentral definierten (und natürlich sauber dokumentierten) Methoden stehen dann allen daraus abgeleiteten Klassen zur Verfügung. OOP kann also, durch Vererbung, zu folgenden Effekten führen:

* konsistente Dokumentation
* einfache Erweiterungen
* Speicherplatz wird effizient genutzt

Dass man außerdem Fehler (z.B. Ausgabefehler, die aus Templatetags resultieren) theoretisch nur noch an einer Stelle ausbessern muss, ist ein kleiner, aber wesentlicher Punkt. Schön ist auch, dass man die gleichen Templatetags, wenn wir das Beispiel weiterführen wollen, in einem anderen Projekt leicht weiterverwenden können. Vielleicht benötigen wird dafür auch die gleiche Datenzugriffsklasse und ggf. weitere vorhergehende Klassen, aber grundsätzlich ist die Klasse weiterverwendbar. Inklusive der Dokumentation und Fehlerbehandlung.

Ich denke aber, dass er auch für Webdesigner eine interessante Hilfestellung sein kann.

Letztlich zeigt uns Acid2 doch die Fehler auf, die Browser derzeit haben. Ich habe mir einige Fehler einmal angesehen und ein darüber nachgedacht, wie ich die Fehler umgehen würde.

Viele Fehler entstehen durch die fehlende Unterstützung für DataURLs. Meine Gedanken dazu kommen in einen gesonderten Eintrag.
Obwohl ich persönlich „Opera“:http://opera.com bevorzuge, habe ich das hier mit Firefox 1.0.3 entwickelt. Wenn es die Möglichkeit, CSS live zu bearbeiten, auch direkt in Opera gäbe, hätte ich mich vermutlich anders entschieden. Außerdem scheint Opera ein größeres Problem mit DataURLs als Firefox zu haben.

h3. Zeile 2: Attribute und Positionierung

In Zeile 2 werden absolute Positionierung und floats über recht komplexe Selektoren getestet.

Dass der IE das nicht kann, ist eine Sache. Diese Attributsselektoren sind dadurch aber in der Praxis noch nicht so verbreitet, wie ich mir das manchmal wünschen würde. Gerade bei Formularelementen wie input, die sich ja nur durch das type-Attribut ausreichend definieren, fehlt diese Unterstützung. Dem begegne ich derzeit mit einer zusätzlichen CSS-Klasse, was zwar in keiner weise elegant, aber eben pragmatisch ist.

Das andere Problem, das diese Zeile zerbrechen lässt, ist, dass die gesamte Zeile absolut positioniert ist. Das funktioniert noch recht gut. In dieser Zeile ist aber noch ein Element enthalten, dass mit der float-Eigenschaft nach rechts geschoben wird. Da die Zeile ohne genau Breitenangabe ausgestattet ist, sollte sie sich eigentlich so klein wie möglich machen.

Macht sie aber nicht. Sie wird so breit wie nötig. Da der float nach ganz rechts will, geht auch die Zeile bis ganz nach rechts, bis an den Bildschirmrand. Eine Lösung dafür, die wieder einmal jeglicher Eleganz entbehrt, ist, eine genau Breite anzugeben.

Im konkreten Falle von Acid2 (line 2) wären das 4em.


[class~=one].first.one { width:4em; }


Voilà! Es wird richtig angezeigt.
Das der Browser sich vorher nicht standardkonform verhalten hat, wird dadurch weder geändert noch besser. Aber es ist immerhin eine Lösung für die Praxis.

Die dritte Betaversion von Opera8 hat diesen Fehler übrigens bereits behoben.

h3. Zeilen 10 – 11: Absolute Postionierung rechts

Ähnliches wie in der zweiten Zeile wird auch hier zum Verhängnis. Im Original wird einem Element die Breite „auto“ zugewiesen. Im Gegensatz zum vorhergehenden erscheint es so, als würde sich das Element so klein wie möglich machen. An sich ist das auch das richtige und erwünschte Verhalten. Es wird nur ein float unrichtig behandelt. Dadurch hat das Grinsen zwar die richtige Breite, diese nimmt aber keinen Platz im darübergelegenen div ein.

Die Lösung, die eigentlich keine ist, sondern nur ein Umgehen von Browserfehlern, sieht wie folgt aus: wir geben dem absolut positionierten Element die richtigen Breite von insgesamt 8em.


.smile div div { position: absolute; top: 0; right: 1em; width: 8em; }


Voilà! Es wird richtig angezeigt. Trotzdem der Disclaimer:
Das der Browser sich vorher nicht standardkonform verhalten hat, wird dadurch weder geändert noch besser.

Das Lachen ist auch noch eine Zeile zu hoch. Dies liegt an einer fehlerhaften Umsetzung der zusammenfallenden Außenabstände. Eine kleine Korrektur der Zahlen führt zur richtigen Darstellung in Firefox. Glücklicherweise würde man solch komplexe Kontrukte in der Webworkpraxis vermeiden. Komplexität führt meist nur zu Problemen. (Au weia, hört sich so richtig nach „Onkel kronn erklärt die Welt“ an… ist nicht so gemeint.)

h3. Weitere Kleinigkeiten

In der abschließenden Zeile wird die display-Eigenschaft getestet, indem aus einer Liste eine Tabelle gemacht wird. Firefox kann dies – wie auch Opera – im Prinzip, hat aber – wie auch Opera – anscheinend ein Problem mit den sog. „anonymen Tabellenzellen“:http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes die laut Spezifikation erstellt werden müssen. Dadurch wird die Zeile doppelt so groß und die korrekt dargestellten Tabellenzellen bedecken nicht das gesamte rot. Mögliche Lösungen sind, diese unvollständige Umsetzung einfach zu umgehen, oder display:table zu display:table-cell zu machen. Ich weiß, ist keine echte Lösung…

Firefox hat weiterhin Probleme mit über object-Tags eingebungende DataURLs. Man könnte das für ein akademisches Problem halten, aber da er prinzipiell mit DataURLs klarkommt (im Gegensatz zu Opera), vermute ich eine unvollständige Implementierung des object-Elements. Mit ein wenig Tricksen ist es aber denoch möglich, das Referenzbild nachzustellen. Leider ist es nur mit BruteForce möglich: Man entfernt die CSS-Deklarationen, die rote Rahmen oder rote Hintergründe darstellen und fügt an passender Stelle die DataURL ein, die für die Augen zuständig ist. Das Hintergrundbild muss dann nurnoch richtig positioniert werden und „fertig ist das Referenzbild“:http://kronn.de/img/acid2-changed-for-firefox.jpg (jpg, 116 KB, 1024×768 -dpi-).

h3. Sinn und Zweck

Die Methoden, die in Acid2 verwendet werden, stoßen absichtlich an Grenzen. Mir ging es nur darum zu zeigen, dass wir bereits recht weit gehen können. Schöner wäre natürlich, für Browser zu coden, die wirklich elegante Lösungen erlauben. Aber mit ein wenig Glück hilft ja Acid2 dabei.

Die Faux Columns-Technik dient dazu, Hintergrundfarben und -muster und Rahmen für Spalten unabhängig von deren Höhe zu definieren. So weit, so schlicht.

h3. Die Technik

Das große Problem, wenn man Inhalte nicht nur in Spalten positionieren möchte, sondern diese Spalten auch noch farblich hervorgehoben darstellen möchte, ist, dass normale CSS-Hintergründe und Rahmenlinien (background-color, border)immer nur die jeweiligen Box betreffen. Wenn der Inhalt einer Spalte also recht kurz ist, wird der darauf definierte Hintergrund nicht weiter als bis zum Ende des Inhalts gehen. Die beabsichtigte Spalte wäre zwar sichtbar hervorgehoben, hätte aber ein recht abruptes und vor allem zu frühes Ende.

Deshalb definiert man auf den body ein Hintergrundbild, zentriert es und lässt es in y-Richtung wiederholen. Über dieses Hintergrundbild positioniert man dann die Inhalte.

Was sich jetzt erstmal recht schlicht anhört, hat aber einige kleine Besonderheiten, die man nicht vergessen sollte. Wer die Technik jetzt nochmal im englischsprachigen Original lesen möchte, kann das gerne tun. Ich warte so lange…

Link zum Artikel: „Faux Columns“:http://alistapart.com/articles/fauxcolumns/

Wieder da? Gut. Also, es gibt da einige Besonderheiten zu beachten.

h3. Hinweise und Besonderheiten

Da das Hintergrundbild mittels { background-position: 50% 50%; } zentriert wird, sind wir auf de Fähigkeiten des Browsers angewiesen, die richtige Position zu finden. Und wie jedesmal, wenn man mehrere fragt, bekommt man auch hier schnell verschiedene Ergebnisse von den Browsern geliefert.
Deshalb sollte man seine Vorlagen auf jeden Fall genau zerschneiden. Ein Pixel mehr oder weniger kann echte Kopfschmerzen bereiten (bis man auf die Idee kommt, einfach nochmal neu und sehr genau zu slicen).

Eine weitere Kleinigkeit erwächst daraus, dass man nicht immer die Möglichkeit hat, den body als umgebende Box zu wählen. Das ursprüngliche Problem taucht wieder auf: Die umgebende Box kann zu kurz sein.
Deshalb sollte man entweder den Inhalt so wählen, dass der container weit genug (über das Browserfenster hinaus) gedehnt wird oder aber an ein abschließendes Fußelement denken.

Haarig kann es auch werden, wenn man die Inhalte einer Seitenleite per {position:absolute; left:0; top:0; } positioniert. Absolut positionierte Elemente werden aus dem normalen Dokumentenfluß herausgenommen und nehmen darin keinen Platz mehr ein. Da sie keinen Platz mehr einnehmen, können sie eine umgebende Box auch nicht ausdehnen. So kann es leicht passieren, dass ein Teil des Inhaltes aus dem Container herausragt und dementsprechend auch keinen Hintergrund mehr hat.
Deshalb sollte man vorher überlegen, wie lang eine Spalte sein kann und ob nicht vielleicht floats (die eine umgebende Box unter gewissen Umständen ausdehnen können) im Einzelfall besser geeignet sind.

Diese Kleinigkeiten haben mir letztens doch einiges an Kopfzerbrechen bereitet, eben weil ich nicht darauf geachtet habe.

Praktisch kann ich jetzt also den Quellcode meiner reset.css einfach und schön hier darbieten, zusammen mit einem Downloadlink.

[The requested file http://kronn.de/code/css/reset.css could not be found]

Ich habe den „ursprünglichen Beitrag“:http://kronn.de/weblog/2004/10/30/css-reset/ leicht angepasst, da ich das CSS selbst in ein extra Verzeichnis kopiert habe.

[Update – 13.03.2005] Danke an „Gerrit“:http://praegnanz.de, der auf zwei weitere Eigenschaften „hingewiesen hat“:http://praegnanz.de/weblog/564/css-tabellen-resetten.