Jun 13

Seit dem Update auf die stabile Version von Safari 4, stürzt mein Apple Mail wieder laufend ab. Die Lösung aus “Apple Mail stürzt laufend ab” ist nicht mehr möglich, da es keine Deinstallationsroutine für Safari 4 gibt. Meine Recherchen ergaben, dass GrowlMail schuld an den Apple Mail abstürzen ist. Ich hätte zwar lieber auf Safari 4 verzichtet als auf GrowlMail, aber irgendwann wird es auch davon ein Update geben. Zum Deinstallieren muss man die GrowlMail-Plugin-Ordner “/Library/Mail/Bundles/GrowlMail.mailbundle” und “~/Library/Mail/Bundles/GrowlMail.mailbundle” entfernen (je nachdem GrowlMail global oder für einen Benutzer installiert wurde).

Jun 07

In den letzten Tagen ist mir Apple Mail häufig abgestürzt. Beim Herunterfahren des Systems ließ es sich nicht wie gewohnt beenden, sondern konnte nur über “Sofort beenden” gekillt werden. Das führte vermutlich zu beschädigten Konfigurationsdateien und in Folge dazu, dass Apple Mail nach jedem Start einige Sekunden später abstürzte. Die ersten Male war es ausreichend Apple Mail zu starten und umgehend (innerhalb der Zeit bis zum Absturz) die Einstellungen aufzurufen. Nun half auch das nicht mehr. Deshalb habe ich versucht wie in “Apple Mail nach Ruhezustand kaputt” beschrieben die Konfigurationsdatei von einem Backup wiederherzustellen – ebenfalls ohne Erfolg. Erst eine Deinstallation von Safari 4 Beta (seit dessen Installation trat dieses Problem auf) und das Aufrufen der Einstellungen sofort nach dem Start von Apple Mail erweckte dieses wieder zum Leben. Meine Erkenntnis daraus: Safari 4 Beta bringt Apple Mail zum Absturz.

Update:
Im Artikel “Apple Mail stürzt seit Update auf Safari 4 laufend ab”  findet ihr weitere Informationen.

Oct 21

Flash wird in letzter Zeit wieder populärer, so wird es auf beinahe jeder neugestalteten Startseite von Firmen (z.B. A1 (zeitweise auch ohne Flash), aon, Dell,…) eingesetzt um neueste Produkte zu präsentieren. Der von Flash generierte Code zur Einbindung des Films hat bis jetzt noch nie einem vom W3C verabschiedeten Standard entsprochen, seit der letzten Version von Flash wird zusätzlich auch noch JavaScript zum Einbinden verwendet – der generierte Code sieht dann in etwa wie folgt aus:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>flash</title>
<script language="javascript">AC_FL_RunContent = 0;</script>
<script src="AC_RunActiveContent.js" language="javascript"></script>
</head>
<body bgcolor="#ffffff">
<!--Im Film verwendete URLs-->
<!--Im Film verwendeter Text-->
<!-- saved from url=(0013)about:internet -->
<script language="javascript">
	if (AC_FL_RunContent == 0) {
		alert("Diese Seite erfordert die Datei \"AC_RunActiveContent.js\".");
	} else {
		AC_FL_RunContent(
			'codebase', 'http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0',
			'width', '676',
			'height', '405',
			'src', 'flash',
			'quality', 'high',
			'pluginspage', 'http://www.macromedia.com/go/getflashplayer',
			'align', 'middle',
			'play', 'true',
			'loop', 'true',
			'scale', 'showall',
			'wmode', 'window',
			'devicefont', 'false',
			'id', 'flash',
			'bgcolor', '#ffffff',
			'name', 'flash',
			'menu', 'true',
			'allowFullScreen', 'false',
			'allowScriptAccess','sameDomain',
			'movie', 'flash',
			'salign', ''
			); //end AC code
	}
</script>
<noscript>
	<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0" width="676" height="405" id="flash" align="middle">
	<param name="allowScriptAccess" value="sameDomain" />
	<param name="allowFullScreen" value="false" />
	<param name="movie" value="flash.swf" />
	<param name="quality" value="high" />
	<param name="bgcolor" value="#ffffff" />
	<embed src="flash.swf" quality="high" bgcolor="#ffffff" width="676" height="405" name="flash" align="middle" allowScriptAccess="sameDomain" allowFullScreen="false" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" />
	</object>
</noscript>
</body>
</html>
Betrachtet man ausschließlich den “noscript”-Teil (der für die Einbindung ausreichend wäre), so findet man bereits hier zwei verschiedene Ansätze der Einbindung vor. Zum einen mittels “classid” über ActiveX, zum anderen mittels “embed”-Tag. Der “embed”-Tag stellt kein valides (X)HTML dar, ActiveX ist reine Windows-Technologie und grenzt somit andere Betriebssysteme (diese greifen auf das nicht valide “embed” zurück) aus.
Mit dem MIME-Type “application/x-shockwave-flash” kann allerdings dem Browser mitgeteilt werden, dass es sich beim vorhandenen “object” um einen Flash-Film handelt. Dieser weiß anhand einer hinterlegten Tabelle, wie er mit diesem Format (z.B. auch mit “text/plain”, “image/jpeg”,…) umzugehen hat. Zufälligerweise Glücklicherweise kann dem “object”-Tag der MIME-Type mitgeteilt werden. Die valide Lösung sieht dann wie folgt aus:
<object width="676" height="405" id="flash" data="flash.swf" type="application/x-shockwave-flash">
	<param name="allowScriptAccess" value="sameDomain" />
	<param name="allowFullScreen" value="false" />
	<param name="movie" value="flash.swf" />
	<param name="quality" value="high" />
	<param name="bgcolor" value="#ffffff" />
</object>
Aus Gründen der Kompatibilität mit diversen Browsern muss der Dateiname sowohl im “object”-Tag (data) als auch mit einem “param”-Tag (movie) angegeben werden.
Jul 26

Bei der Entwicklung von Webseiten werden (logischerweise) sehr oft Änderungen an HTML, CSS, JS, etc. durchgeführt. Dabei kann es passieren, dass Änderungen nach dem erneuten Laden der Seite (Refresh/Reload) nicht angezeigt werden, da die Seite bzw. die eingebundenen Dateien aus dem Cache des Browsers und nicht wie gewünscht erneut vom Server geladen werden. D.h. es sieht so aus, als ob die durchgeführten Änderungen (auch) nicht den gewünschten Effekt hervorrufen, obwohl sie das (wenn die komplette Seite vom Server geladen werden würde) vielleicht machen.

Abhilfe schafft es, wenn man den lokalen Cache im Browser deaktiviert. Dafür kann man entweder in den Einstellungen des Browsers die gewünschte Einstellung vornehmen, was aber beim Besuch von anderen Webseiten (beim “normalen” Surfen) nicht unbedingt erwünscht ist.

Für auf der Gecko-Engine basierende Mozilla-Browser gibt es die Web Developer Toolbar von Chris Pederick. Diese erlaubt es den Cache sehr einfach zu deaktivieren bzw. auch wieder zu aktivieren:

Eine weitere und wohl die bequemste Möglichkeit ist es, die Tastenkürzel der einzelnen Browser zu verwenden, die nicht nur die Seite neu laden, sondern auch den lokalen Cache der aktuellen Seite löschen:

  • Internet Explorer: Strg + F5 (Windows)
  • Firefox: Strg + F5 oder Strg + Umschalt + R (Windows) bzw. Cmd + Umschalt + R (Mac)
  • Safari: Cmd + Umschalt + R (Mac)
Jun 11

Wenn man viel im Terminal von OS X arbeitet und unter dort genauso wie in Safari auch Tabs verwendet, wird manchmal durcheinander kommen. Schließlich sind die Tastaturkürzel für den nächsten und vorherigen Tab in Terminal und Safari genau vertauscht. In Terminal wechselt man mit alt + cmd + Ä zum nächsten Tab, in Safari mit alt + cmd + Ö. Zum vorherigen Tab gelangt man in Terminal mit alt + cmd + Ö, in Safari dagegen mit alt + cmd + Ä:

Von vielen Programmen (z.B. iTunes) ist man gewohnt, dass das nächste Objekt (z.B. Titel) mit einer auf der Tastatur weiter rechts befindlichen Taste als das vorherige Objekt zu erreichen ist. Glücklicherweise ist die Umstellung der Tastaturkürzel unter OS X kein Problem. In den Systemeinstellungen wechselt man zu Tastatur & Maus und wählt Tastaturkurzbefehle aus. Dort fügt man mit einem Klick auf “+” die neue Einstellung hinzu. Als Programm wird “Safari.app” ausgewählt, in Menü wird die Bezeichnung wie in Safari zu finden (“Vorherigen Tab auswählen” bzw. ”Nächsten Tab auswählen”) eingegeben, der Tastaturkurzbefehl wie gewünscht (alt + cmd + Ö bzw. alt + cmd + Ä) festgelegt und mittels Klick auf “Hinzufügen” festgelegt:

Nachdem beide Tastaturkurzbefehle festgelegt wurden, können die Tabs nun sowohl in Terminal, als auch in Safari auf die selbe Art und Weise umgeschaltet werden:

May 02

Im Internet Explorer wird standardmäßig eine vertikale Scrollbar angezeigt, selbst wenn der Inhalt der Webseite nicht länger als das Browserfenster ist. Das hat den Vorteil, dass eine zentrierte Webseite nicht “springt”, wenn der Inhalt je Seite länger/kürzer als die Höhe des Browserfenster ist. Manche Kunden, vor allem aber Grafiker stört das “springen” der Seite, aber es gibt einen einfache Workaround um das zu verhindern.

Lösung für den Firefox:

Hierfür fügt man im Stylesheet folgenden Code ein:

html {
  overflow: -moz-scrollbars-vertical;
}

Leider funktioniert diese Lösung nur im Firefox und wird von allen anderen Browsern ignoriert.

Die Allround-Lösung:

Im Stylesheet setzt man die Höhe von html auf 100% und fügt einen Außenabstand von 1px ein:

html {
  height: 100%;
  margin-bottom: 1px;
}

Diese Lösung funktioniert in allen gängigen Browsern, allerdings entsteht dadurch ein Scrollbereich von 1px. Auch das kann als gleich störend empfunden werden, wie das “Springen” der Seite selbst.

Die CSS3-Lösung:

Auch diese Lösung kann man als “Allround-Lösung” bezeichnen. Obwohl die overflow-y-Eigenschaft erst in CSS3 enthalten sein wird, wird sie von den gängigsten Browsern (Firefox 1.5+, Safari 1.0+, Konqueror 3.3+,…) bereits unterstützt:

html {
  overflow-y: scroll;
}

In diesem Fall wird die Scrollleiste deaktiviert dargestellt, wenn der Inhalt der Seite kürzer als die Höhe des Browserfenster ist, andernfalls wie gewohnt eine Scrollleiste dargestellt.

Opera interpretiert diese Eigenschaft leider (noch) nicht, weshalb man in diesem Fall die “Allround-Lösung” als Workaround für Opera in die Seite integrieren muss. Hierfür fügt man diesen in opera.css ein und integriert ihn wie folgt in die Seite:

<link rel="stylesheet" href="opera.css" type="text/x-opera-css" />
Mar 06

Wie berichtet besteht nun auch der Internet Explorer in der Version 8 als letzter der weitverbreiteten Browser den Acid2 Browser-Test. Deshalb war es an der Zeit einen neuen Test zu entwerfen, um die Fähigkeiten der Browser zu überprüfen. Acid3 möchte nun mehr als nur ein per CSS erzeugtes Lächeln von den Browsern sehen. Weiterlesen »

Jan 20

Die sich noch in der Entwicklung befindlichen Browser Internet Explorer 8 und Firefox 3 bestehen den Acid2 Browser-Test. Bei diesem Test geht es darum CSS 2.1 korrekt zu interpretieren und ein Smiley samt Text, wie im nachstehenden Bild gezeigt, korrekt darzustellen. Weiterlesen »