Ich weiß noch, so Anfang diesen Jahrtausends, 2000/2001 ca. da wusste ich noch nicht sonderlich viel von PHP und selbst damals war PHP ja auch keine Selbstverständlichkeit auf dem heimischen Webspace.

Nun bietet PHP da eine praktische Funktion von der wir wohl auch immernoch oft gebrauch machen. include() kann externe Dateien nach belieben an der verankerten Stelle in die Datei einfügen und ausführen.

Das war damals schon praktisch wenn man z.B. einheitliche Kopf und Fußbereiche einer simplen Seite einbinden wollte um diese bei einer möglichen Änderung nicht für jede angelegte Seite erneut ändern zu müssen.

Jedenfalls gab es damals eine tolle Alternative zu include, und die nannte sich kurz SSI, Server Side Includes. Damit war es möglich (sofern im Apache das Modul mod_ssi aktiviert war, war es allerdings fast immer) solche statischen Bereiche einer Seite einheitlich in externe Dateien zu verschieben.

Das sah dann z.B. so aus:

<!--#include file="header.shtml" -->

Das war damals jedoch auch irgendwie alles wofür wir SSI benutzt haben. Heute arbeitet ich mal wieder auf dem Webspace eines Kunden der noch einen steinzeitlichen Vertrag bei 1&1 hat den ich aus unerfindlichen Gründen niemals auf ein PHP-fähiges-Level upgraden konnte.

Da kamen mir spontan wieder die Server Side Includes in den Sinn. Immerhin besser als alles 10x zu schreiben. Als ich den dazu passenden Wikipedia-Artikel aufrief sah ich aber, das SSI noch mehr bietet als das simple einbinden weiterer HTML-Schnipsel. Ja! In SSI gibt es sogar Variablen, Systemvariablen und if/else Abschnitte, selbst reguläre Ausdrücke werden verstanden. Wer mehr wissen möchte sollte sich mal die weiterführenden Links auf Wikipedia ansehen.

Nicht das wir jetzt aufhören sollten unsere CMSe zu nutzen oder so, ich wollte nur mal meine Verwunderung ausdrücken. Was hätte mir das doch nur damals bei meinen Frickelprojekten für arbeit erspart, wenn man z.B. den <title> mit einer Variable betanken hätte können.

War jedenfalls mal wieder schön eine kleine Exkursion in alten Codegefilde zu machen, allerdings ist man doch auch irgendwann wieder froh im jetzt und heute zu sein.


Die meisten von uns haben ja sicherlich bereits von Listen in HTML-Dokumenten gehört, die gibt es als <ol>, <ul> oder auch <dl> (wozu es übrigens erst kürzlich einen tollen Artikel gab). Oftmals verwenden wir dabei Symbole zum verdeutlichen von Funktionalitäten, wie wir es etwa im Beispiel-Screenshot sehen können. Wir schalten die Listenpunkte durch list-style: none; im CSS einfach ab und verpassen den jeweiligen Punkten ein Symbol wie z.B. ein kleines Häuschen als Symbol für die Startseite.

Zur Realisierung solch grafischer Listenpunkte gibt es im Prinzip 3 Herangehensweisen die ich erst einmal kurz vorstellen möchte:

Kompletten Artikel lesen...


Internet Explorer 8 Beta 1

Nun geht ja wirklich alles Schlag auf Schlag. Erst ging es zum Thema Standardrendering des Internet Explorer 8 hin und her und dann wurde heute auch schon die Seite zum Internet Explorer 8 Readiness Toolkit gestartet. Erst waren die Links zu den Betaversionen noch Blindgänger, doch seit ein paar Minuten hat man endlich Zugriff auf die Betas für Windows XP SP2 und Windows Vista.

Überraschend schnell wie ich finde, wo man doch sonst Jahre auf eine erste Vorabversion warten musste.

Ich freue mich das Microsoft scheinbar mit dem Internet Explorer 8 begriffen zu haben scheint, das Webstandards nichts schlechtes sind. Also lasst uns dieses Stück Software nun kollektiv auf Herz und Nieren prüfen…


Wer ist für Überstunden, Haarausfall, Ratlosigkeit und Unproduktivität in unserer Branche verantwortlich? Richtig: Der Internet Explorer.

Nun ist bei David eine kleine Diskussion entbrannt, die sich darum dreht, in wie weit man heute bei der Umsetzung von Webseiten den Internet Explorer unter Version 7 unterstützen sollte.

Meine Meinung: Für Webseiten mit geschäftlichem Hintergrund, bei der es auf jeden Besucher ankommt, ist eine Optimierung für den Internet Explorer ohne zweifel notwendig, bei meiner Arbeit sogar teilweise noch für den IE5… je nach Zielgruppe.

Auf der anderen Seite sehe ich jedoch, das es wohl keinen anderen Weg mehr gibt die Nutzer zumindest zu einem Update auf den Internet Explorer 7 zu bewegen, als diese ganz einfach zu zwingen. Was helfen kleine Hinweise wie “Sie setzen einen veralteten Webbrowser ein, bitte aktualisieren Sie auf eine aktuelle Version”, wenn der Nutzer am anderen Ende eh alles auf der Seite ansehen kann? User sind Faul und niemanden interessiert solch ein Hinweis, solange nicht drastische Nachteile für Ihn dadurch entstehen.

Kompletten Artikel lesen...


DebugBar Screenshot

Meine Gebete wurden erhört, nur leider habe ich das wohl zu spät mitbekommen.

Gerade eben habe ich die DebugBar für den Internet Explorer entdeckt. Das ist für mich schon fast eine kleine Sensation! Die DebugBar sieht auf den ersten Blick so aus wie der kleine Bruder von Firebug, einer Extension die wohl kein Webentwickler mehr missen möchte.

DebugBar bildet nun die annähernd gleichen Funktionalität auch für den Internet Explorer ab. Man kann die einzelnen DOM-Elemente per Drag & Drop aktivieren oder durchklicken, sich deren (vom IE “interpretierten”) CSS-Eigenschaften ansehen, einzelne Elemente wie Bilder, Formulare und Links auflisten lassen, AJAX-Calls verfolgen, JavaScript-Funktionen einsehen und selbst das (X)HTML lässt sich on-the-fly validieren. Ein ebenfalls nettes Feature ist die grafische Darstellung des (meist kaputten) Boxmodels, also der width/height, padding, border und margins.

Ich denke das kann doch ein großer Schritt in Sachen Bug-Bekämpfung des IE sein. Zwar werden wir in einigen Fällen wohl um unsere Hacks nicht herum kommen, doch das “WARUM, WARUM VERDAMMT!!!” klärt sich vielleicht doch etwas schneller als bisher.

Mir ist zudem aufgefallen das sich die Toolbar wunderbar mit MultipleIE zu verstehen scheint, man kann sie also beim Debuggen auf einem System sowohl im IE6 als auch IE7 zeitgleich verwenden.

Doch aufgepasst, solltet ihr DebugBar für kommerzielle Projekte benutzen wollen, so wird eine Gebühr von 59$ für eine Single-User-License fällig. Für private Geschichten ist die nutzung der Software jedoch kostenlos.


Heute mal ein kurzer aber ich denke doch sehr durchdachter Trick:

Viele von uns kennen ja das umstrittene nofollow-Attribut. Nofollow wurde ins Leben gerufen, um in erster Linie Kommentarspam vermeiden zu können. In vielen Weblogs werden daher Links in Kommentaren standardmäßig in etwas so ausgegeben:

<a href="http://www.deinedomain.de" rel="nofollow">Dein Name</a>

Dieser Link kann alles was ein “normaler” Link auch kann, hat aber die Eigenschaft von Suchmaschinen nicht gewertet zu werden. Über den Sinn dahinter ist man geteilter Meinung, ich für meinen Teil habe mich aber bewusst gegen nofollow in meinen Kommentaren entschieden.

Nun gut werdet ihr sagen, kennen wir schon. Stimmt! Doch was viele nicht bedenken ist, das man dieses Attribut ebenso für interne Links verwenden kann.

Nehmen wir uns als Beispiel einmal einen üblichen Webshop welchen wir optimal für Suchmaschinen ausliefern wollen. Google spidert also den Shop und findet diverse Links in den HTML-Dokumenten, darunter z.B. auch Verweise auf:

All diese Seiten sind für ein gutes Ranking in den Suchmaschinen nicht wirklich relevant, im Gegenteil, sie könnten unter Umständen sogar Teile von Douplicate Content beinhalten. Ein wichtigerer Faktor ist jedoch das jede Seite im Shop auf diese “unwichtigen” Seiten verlinkt und damit immer auch ein wenig Authority abgibt. Versehen wir diese Links nun also mit einem rel="nofollow" haben diese keinerlei Einfluss auf das Ranking mehr und es bleibt mehr Saft für die restlichen Links über.

Sicherlich nur eine Kleinigkeit, doch gerade bei Seiten mit vielen Footerlinks könnte das doch einiges bewegen. Die Anregung dafür entsprang übrigens aus dem (sehr zu empfehlenden) Sistrix-Blog.



Ältere Einträge

Blogsuche

RSS-Feeds

Plaste & Plastik

plasteundplastik.de - Das Geocaching-Weblog

Die Kategorien


Netz-Fundstücke


Meta / Propaganda