Lange war es ruhig seit dem letzten Post zu diesem Thema, doch hoffe ich, ihr konntet die Zeit gut nutzen, um euch etwas in git einzuarbeiten.

In diesem letzten Teil der Serie “Website Management mit Git” komme ich zum eigentlichen Kernpunkt: wie kann man die eigene Website mit git administrieren. Wenn ihr bis jetzt meinen Ausführungen gefolgt sein, sollte dieser letzte Schritt nur noch ein Klacks sein und ich denke, der Beitrag wird auch eher kurz. Also, starten wir.

Grundlegender Ablauf und Idee

Als Webentwickler hat man meist eine lokale Version der Webseite, an welcher man arbeitet. Sobald die Seite ausgehend getestet ist, werden dann die Änderungen (meist per FTP) auf den Server geladen. Mit git gestaltet sich dieser ganze Prozess noch viel schneller und einfacher. Sobald die Webseite in Ordnung ist, reicht es 1 Befehl einzutippen und alle Änderungen werden auf den Server übertragen. Da git die Dateien komprimiert und auch nur die Änderungen hochlädt, ist die Aktualisierung auch um einiges schneller. Dies sind die Schritte im Überblick:

1. Webseite für die Arbeit mit git lokal vorbereiten

2. Webserver vorbereiten

3. Lokale Webseite mit dem Webserver verbinden

Weiter lesen

Man ist sich als Webdesigner schon einiges vom InternetExplorer gewöhnt, doch das Problem, mit welchem ich letzthin zu Kämpfen hatte, war mir neu. Ich entwickelte für RapidWeaver eine Erweiterung, welche die Google Suche in eine Webseite einbaut. Bei meinen Tests funktionierte dies in allen Browsern problemlos. Die einzige Ausnahme war der InternetExplorer 8 (frühere Versionen habe ich gar nicht getestet). Ich durchsuchte mein Script auf alle mögliche Fehler, bis ich durch den Debugger der Developer Toolbar des IE8 auf etwas gestossen bin:

In meinem Skript verwendete ich eine Variable “wrapper”. IE8 meldete mir stets, dass dieses Objekt keine Zuweisung eines DOM-Elements gestattet. Kurzerhand habe ich die Variable in “theWrapper” umgetauft und siehe da: jetzt funktioniert das Script auch problemlos im IE8. Es scheint so, als benutzt der Explorer die Variable “wrapper” intern für irgendwas.

Was ich dabei gelernt habe: ich werde ab jetzt meine Variablen immer mit “the” beginnen, also z.B. “theContainer” oder “theElement”.

Eines der tollsten Neuigkeiten von CSS3 ist die Möglichkeit, RGBA Farbwerte zu bentuzen. RGBA steht für RGB mit Alpha-Kanal. So ist es möglich, direkt einer Schrift oder einem Hintergrund eine halb-transparente Farbe zuzuordnen. Wir kennen schon schöne solcher Effekte von PNG-24 Bildern: Webseiten erhielten dadurch auf einfache Weise Tiefenwirkung. Auch die CSS-Regel “opacity” wurde für genau diese Zwecke eingeführt, doch ist RGBA der opacity-Regel meist vorzuziehen, denn opacity bezieht sich immer auf das ganze Objekt. Das heisst, auch die Schriften, welche im Block enthalten sind, werden transparent und somit schlechter leserlich. Mit RGBA ist es möglich, nur einem Hintergrund eine Transparenz zuzuweisen, ohne die Inhalte selber zu ändern. Wow!

Hier ein Beispiel, bei welchem RGBA-Werte für Textschatten eingesetzt werden:

Solche Dinge sind mit “opacity” kaum machbar.

Aber kommen wir zum eigentlichen Problem: Browsersupport bzw. der Internet Explorer. Firefox kann damit seit Version 3 und Safari seit Version 3.2.1 umgehen. Doch erst der IE9 kennt RGBA und viele Besucher benutzen noch eine ältere IE-Version.

Nun kann man entweder sagen “Selber Schuld” oder aber einen Weg suchen, RGBA auch in älteren Browsern zu unterstützen. Dazu gibt es einige Möglichkeiten, wobei insbesondere das Projekt CSS3 Pie zu erwähnen ist.

Doch leider klappte das bei einem meiner Projekte nicht. Das liegt wahrscheinlich daran, dass Inhalte per AJAX nachgeladen werden und so bestimmte Skripte nicht ausgeführt wurden. So machte ich mich daran, und erstellte von Grund auf eine eigene Lösung des Problems.

Weiter lesen

Es ist ja ein leidiges Thema, doch kommt kaum ein Webdesigner darum herum, die erstellten Seiten auch unter dem Internet Explorer für Windows zu testen. Dazu gibt es verschiedene Ansätze:

- Internetdienste wie browsershots.org oder Adobe Browserlab

- Software, die Windows emulieren bzw. virtualisieren

- Eine Testmaschine benutzen, auf welcher Windows installiert ist

Auch wenn die Internetdienste für den ersten Eindruck meist genügen, zeigt sich, dass die Funktionalität bzw. Dinge, welche per Javascript geändert werden, nicht zu 100% funktionieren. Daher ist es ein Muss, Windows auf irgend eine Art verfügbar zu haben.

Doch fangen da die Probleme erst an, denn in der Regel kann man nur 1 Version des Explorers installiert haben. Früher konnte man noch das Tool “MultipleIE” verwenden, um die Webseite gleichzeitig unter verschiedenen Versionen zu überprüfen. Doch leider scheint es seit IE8 nicht mehr möglich zu sein, mehrere IE-Installationen mit diesem Tool zu verwenden. Eine Lösung wäre die IE Collection, welche alle Versionen von 1-8 bietet. Doch gibt es, soweit es mir bekannt ist, noch keine Lösung, den IE9 da einzubauen. Somit braucht man momentan mindestens 2 Lösungen (IE9, IE8 und kleiner).

Seit Jahren verwende ich nun schon das Produkt “Parallels” von der gleichnamigen Firma, um meine Webseiten zu testen. Seit dem IE8 musste ich jedoch separate “Virtuelle Maschinen” für jede IE Version erstellen. Das ist nicht nur ein enormer Festplattenspeicherfresser, sondern macht das Arbeiten auch wenig intuitiv, da das Programm doch ziemlich leistungshungrig ist und der Betrieb mehrere virtuellen Umgebungen meinen Mac deutlich ausbremst. So musste ich immer erst eine Umgebung pausieren, zur anderen Wechseln und diese starten.

Dabei geht es auch einfacher durch die Benutzung von “Snapshots”. Dieses Feature habe ich erst gestern das erste Mal eingesetzt und frage mich, wieso ich nicht schon früher darauf gekommen bin. Mit diesen Snapshots kann man einen Zustand des Systems quasi “Abknipsen” und speichern. So ist es möglich, in relativ kurzer Zeit zwischen zwei (oder noch mehr) Zuständen zu wechseln. Ich habe nun einen Zustand “IE8″ und einen für “IE9″ in Gebrauch und muss sagen, das Testing macht so deutlich mehr Freude, sofern einem diese Arbeit wirklich Freude bereiten kann.

Endlich: so wie es momentan aussieht, unterstützt Mobile Safari unter iOS 5 die CSS Regeln “position: fixed” und “overflow: auto” bzw. “scroll”. Container, die mehr Inhalte boten, als dargestellt werden konnten, konnte bis und mit iOS 4 nur mit einem Scrollen mit zwei Fingern gescrollt werden. Wieso dies Apple so gehandhabt hat, ist mir immer noch schleierhaft. Ich habe auch schon sehr viele Supportanfragen diesbezüglich erhalten und bis anhin musste ich den Leuten erklären, sie müssten zwei Finger verwenden. Nun scheint Apple sich dies überlegt zu haben und externe Tools wie “iScroll” sollten nicht mehr notwendig sein. Natürlich ist es noch offen, ob diese Neuerungen auch im endgültigen Release vorhanden sein werden, doch gehe ich davon momentan aus, da diese Neuerungen schon in mehreren Beta Versionen vorhanden waren. Hoffen wir, dass es sich Apple nicht noch anders überlegt.

Auch die Eigenschaft “position: fixed” bringt viele neue Möglichkeiten für das Design. Insbesondere sollten dann wahrscheinlich alle Lightboxes zuverlässiger funktionieren.

Halleluja!