Auch auf die Gefahr hin, dass es schon bekannt ist, aber seit einiger Zeit gibt es das Buch “Professionelle Softwareentwicklung mit PHP 5” als kostenlose HTML-Version. Beachtenswert finde ich, dass es in dem Buch ein Kapitel über Creole und Propel gibt. Viele Aspekte dieser Skripte sind zwar etwas oberflächlich behandelt, aber ja nur als Einführung gedacht (“So etwas gibt es und man arbeitet damit ungefähr so.”).

Gerade bin ich auf eine sehr interessante und extrem elegante Lösung des position:fixed-Problems des Internet Explorers gestoßen. Einfach dem IE

html { overflow-x:auto; overflow-y:hidden; }
body { height:100%; overflow-y:auto; }

unterschieben (z.B. mit Conditional Comments) und er interpretiert sämtliche relativ oder absolut positionierten Elemente (position:absolute oder position:relative) als fix. Natürlich kann man dann auf dem Rest der Seite keine positionierten Elemente einsetzen - float funktioniert aber vollkommen problemlos.

1. getElementsBySelector(selector): Wie viel einfacher wäre es doch, wenn es eine solche Funktion geben würde. Einfach den CSS-Selektor angeben und eine HTMLCollection mit allen zutreffenden Elementen zurückbekommen. Allerdings gibt es von Dean Edwards eine Funktion, die sie größtenteils simuliert: cssQuery. Der Nachteil dieses Workarounds ist die Größe: 16 KB unkomprimiert und 6 KB komprimiert - gerade noch vertretbar.

2. firstElement, nextElement, usw.: Ein gewisser Vorteil einerseits aber oft ein gewaltiger Nachteil ist, dass das DOM alles als Knoten betrachtet. Auch ein Leerzeichen zwischen zwei Elementen generiert einen neuen Knoten, genauso wie ein Kommentar. Wenn man nun das erste Element/Tag innerhalb eines anderen Elements zu bekommen, stößt man auf ein Problem: firstChild liefert möglicherweise einen Textknoten (mit Leerzeichen) und nicht das erste Element zurück.

3. Die Möglichkeit mit einer for...in-Schleife die Elemente einer HTMLCollection zu durchlaufen: Wenn man das probiert, erhält man nicht jedes Element sondern die Indizes des HTMLCollection-Objekts. Das lässt sich teilweise durch Wrapper-Funktionen, die das ganze in ein Array umpackt, ersetzen.

4. Ein Klassenmanagement-System: Man muss sich immer erst selbst Funktionen schreiben, die solche grundlegenden Abfragen ermöglichen. Wäre es nicht viel eleganter einfach auf element.hasClass('klasse') zu prüfen? Mit Prototypen kann man so etwas aber recht einfach realisieren. Notwendige Funktionen wären mindestens hasClass (zum Überprüfen ob das Element die Klasse besitzt), addClass (um eine Klasse hinzuzufügen) und removeClass (um eine Klasse zu entfernen). Zusätzlich wäre noch toggleClass (wenn das Element die Klasse hat, wird sie entfernt, ansonsten hinzugefügt).

Ein kleines JavaScript um die Position eines Objekts auf der Seite zu bestimmen:

function getPosition(obj) {
  var pos = { x:0, y:0 };

  do {
    pos.x += obj.offsetLeft;
    pos.y += obj.offsetTop;
  } while (obj = obj.offsetParent);

  return pos;
}

Benutzt wird das ganze mit:

var pos = getPosition(document.getElementById('objekt'));
alert(pos.x + '/' + pos.y);

Eine Frage, die mich schon seit längerer Zeit beschäftigt und auf die ich auch kürzlich wieder gestoßen bin: Die Speicherung von Boolean-Werten in einer MySQL-Tabelle. Andere RDBMS bieten dazu Datentypen wie BOOL an, aber MySQL hat nichts dergleichen im Angebot. Oder doch? Man könnte im Prinzip den ENUM-Typ dazu “missbrauchen”, einen solchen Typ zu emulieren: ENUM('0', '1') NOT NULL. Aber bringt das wirklich was? Wird eine Datenbankabfrage dadurch schneller? Und vor allem: wird sie merklich schneller, so dass eine Optimierung überhaupt lohnt?

Dagegen spricht die Tatsache dass bis zur Version 4.1 NOT NULL für ENUM-Felder nicht berücksichtigt wurde - so kann also Dateninkonsistenz entstehen. Zusätzlich kann es - laut MySQL-Manual - zu Verwirrungen kommen, da in obigem Beispiel der Wert '0' den internen Wert 1 zugewiesen bekommt. UPDATE table SET bool = 1; setzt den Wert als auf false bzw. '0'.

Und dafür? Ja dafür spricht eigentlich nur, dass mit ENUM (im Idealfall) wirklich - wie bei einem Boolean-Typ üblich - nur zwei Werte in Frage kommen. Aber da ein Vergleich in einem TINYINT-Feld (mit Zahlen bis maximal 255 UNSIGNED) nicht wirklich viel Leistung kosten dürfte, kann man einfach auf bool NOT 0 (nicht NOT NULL) oder bool > 0 prüfen - und fertig.

Es gibt Sachen, die sind begrenzt. Zum Beispiel die Buchstaben des Alphabets. Das hat 26 Stück, wenn man Buchstaben, die mit Diäresen, Striche, Tilden, Accents und sontige Verzierungen und Ligaturen weglässt. Und wenn man zwei Buchstaben hintereinander stellt, bekommt man schon 676 Möglichkeiten, bei drei werden es schon 17576. Eigentlich logisch, dass es da irgendwann zu Kollisionen kommt. Natürlich sind nicht alle Kombinationen mit drei Buchstaben belegt (Vermutung von mir, wenn das Gegenteil bewiesen wird, soll’s mir auch recht sein). Zeichenfolgen mit komischen Kombinationen will natürlich niemand haben, deswegen bleiben die frei.

Und dann gibt es auch noch die Zeichenfolgen, die jeder haben will. “CSS” ist so ein Beispiel. Das Lexikon für überflüssiges Wissen, nutzlose Fakten und Besserwisser, in der Fachsprache auch als Wikipedia bezeichnet, kennt für diese Buchstabenkombination gleich 9 verschiedene Bedeutungen. “Na gut, dann gibt’s halt 9 verschiedene Bedeutungen, aber was interessiert mich das?” Der geneigte Leser erkennt jetzt sofort, dass massive Probleme auf uns zukommen. Wenn nämlich Scripte eingesetzt werden, die automatisch Abkürzungen mit solchen lustigen kleinen Pünktchen versehen, kann es zu Kollisionen kommen.

In manchen Bereichen ist es ja noch relativ einfach. In einem Forum für Webdesigner meint “CSS” in den seltensten Fällen “Content Scrambling System” oder gar “CounterStrike: Source”. Aber wenn man andere Bereiche hernimmt, kann es hier schon zu Problemen kommen: Im Heise-Forum gibt es sowohl Trolle, die “CSS” schreiben und “Cross-Site-Scripting” meinen als auch solche, die damit “Cascading Stylesheets” meinen.

Was tun? Eine Lösung muss natürlich her. Man kann Benutzer nicht dazu zwingen, zu jeder Abkürzung, die sie benutzen, die ausgeschriebene Variante dazu anzugeben - oft wissen die Nutzer selbst nicht genau, was damit gemeint ist. Ganz auf solche Abkürzungen verzichten? Das wäre eine Möglichkeit. Dem Nutzer lieber keine Information als eine möglicherweise falsche Information geben.

Eine andere Lösung wäre aber auch, eine große Akronymdatenbank anzulegen, in die alle Informationen eingetragen werden, eventuell auch mit einer kurzen Erklärung. Wenn der Benutzer jetzt ein Akronym eingibt, erscheint eine Auswahlliste, ähnlich wie bei “Google Suggest” oder in vielen anderen Eingabefeldern aus Desktopapplikationen, in der alle Möglichen Erklärungen enthalten sind. Das Problem hierbei: Normalerweise tippt der Benutzer in eine textarea und nicht in ein normales Eingabefeld. Meines Wissens ist es nicht möglich, per JavaScript zu erkennen, wo sich genau der Cursor befindet so dass eine Liste eingeblendet werden kann, falls das Akronym mehrdeutig ist.