Erinnert ihr auch noch an die ersten Generationen der Mobiltelefone? Damals, als das Telefonbuch wahlweise auf der SIM oder auf dem Telefon gespeichert werden konnte. Und egal, welcher Ansatz gewählt wurde: wenn die Kontakte überführt werden sollten, ging es selten verlustfrei über die Bühne.

Und dann kam Google mit den Android-Systemen (ja, und auch Apple – die spielen hier keine Rolle) und bieten dir die Synchronisation an. Der Deal ist einfach: du bezahlst einfach mit den Daten, die du eben darüber zur Verfügung stellst (und neben Kontakten auch Termine, Aufgabe und Dateien). Ich wollte nie diesen Preis wirklich zahlen – doch dann ist man wieder bei Schmerz. Und genau dem wollte ich mich entziehen. Daher dieser Eintrag.

Ziel war also die Synchronisation zu einem Ort, den ich selbst steuern kann. In dem Fall konkret meine eigene NextCloud-Instanz. Und dann nicht nur mit dem Telefon, sondern auch gleich mit dem Laptop (und auch der Option weiterer Geräte).

Im Beitrag erkläre ich die Syncronisationsschritte.

Zum vollständigen Text

Wer sich bei apple an den Support wenden möchte, muss sein Problem in kompakte 140 Zeichen beschreiben. Aber nicht jedes Problem lässt sich in 140 Zeichen verpacken. Schon gar nicht Computerprobleme ;-) Hier ein kleins Tutorial, wie es doch geht!

Da der Hersteller die Textlänge nicht auf dem Server prüft, können mir wenigen Handgriffen auch längere Texte abesendet werden.

Zum vollständigen Text

Zugegebenermaßen: das www am Anfang der Internetadressen ist mittlerweile aus der Mode. Auch um unnötig doppelten Inhalt zu vermeiden, sollten die Seiten mit www beginnend auf die jeweiligen Hauptadressen verweisen. Das habe ich nun auf dieser Seite umgesetzt.

Die Lösung ist recht einfach, wenn der Zugriff auf die .htaccess-Datei erlaubt ist und mod_rewrite als Modul zur Verfügung steht. Wichtig ist in dem Zusammenhang, dass eine Bedingung gesetzt wird, andernfalls besteht das Risiko vor Endlosschleifen.

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.domain\.de$ [NC]
RewriteRule ^(.*) http://domain.de/$1 [L,R=301]

Anmerkung: Vielleicht kann man diese Weiterleitung bei anderen Providern konfigurieren. Bei Hosteurope sind zwingend beide Domains auf den selben Pfad eingestellt.

Im PHP-Code meiner Seite suchte ich eben nach der Ursache für ein eigenartiges Verhalten. Kurz zusammengefaßt und als Rätsel verpackt:

In der Ausgabe lieferte allerdings nicht »,«, sondern »,1«. Warum?

Heute ist die Programmiersprache, mit der auch diese Seite entwickelt worden ist, 15 Jahre alt geworden. Ich gratuliere!

Gemäß der (X)HTML-Spezifikation muß jedes Dokument einen Seitentitel haben, so bisher mein Glaube. Aber es ist ja auch sinnvoll. Trotzdem akzeptiert der offizielle w3c-Validator folgenden Code:

<title />

Auch wenn es nach XML-Schema korrekt und vermutlich syntaktisch korrekt ist, semantisch ist es jedenfalls falsch. Aufgefallen war dieses Phänomen durch Opera. Er erkennt den schließenden Tag für den Seitentitel nicht und zeigt das komplette danach folgend Dokument in der Titelzeile des Browsers an (bzw. schneidet irgendwann ab), die Seite blieb weiß.

Eine kurze Vorstellung und Bewertung über die neuen Formularfelder in HTML5.

Zum Bild

Zum vollständigen Text

Eben habe ich mir mal das Kapitel der neuen attributbedingten Selektoren unter CSS 3.0 angeschaut und bin durchaus begeistert. In der Version 2.0 hatte man damit zwar begonnen, aber das Ergebnis war nicht wirklich praxistauglich gewesen. Und so war es vor Jahren noch eine friemelige Angelegenheit, die Adressen von Links im PHP nach möglichen Endungen zu untersuchen (z.B. erscheint bei einem Link auf eine mp3-Datei ein Notensymbol) bzw. interne Links von externen Links zu unterscheiden (bei externen Links erscheint ein kleiner Pfeil). Am Ende wurde diese »Erkenntnis« in Form einer Klasse an den Link drangehangen und im CSS formatiert.

Zu Unterscheidung interner (= keine absoluten Adressen) und externer Links würde nun das reichen:

Die mp3-Datei läßt sich nun so kennzeichnen:

Funktioniert unter Opera 9 und Firefox 3.

Gestern ist der erste Entwurfsstand für HTML5 veröffentlicht worden. Eine kleine Übersicht mit Kommentaren über die Änderungen:

Zum vollständigen Text

Die Bedeutung von AJAX im (Be-)Reich der Webentwicklung ist in den letzten Jahr spürbar gestiegen. Insbesondere löst AJAX das Problem, daß innerhalb einer HTML-Seite weitere Anfragen an den Server möglich sind, ohne die komplette Seite erneut laden zu müssen. AJAX baut auf dem DocumentObjectModel auf und benutzt JavaScript-Routinen zur dynamischen Darstellung und Manipulation des Inhalts sowie zum Nachladen von Seitenteilen den XMLHttpRequest.

Auch wenn die Vorteile von AJAX durch viele Beispielanwendungen wie Google Earth schnell sichtbar werden, gibt es auch viele Nachteile, vor allen durch die Tatsache, daß kein Weg an JavaScript vorbeiführt:

• AJAX-basierte Seiten erfüllen nicht die Anforderungen an die Barrierefreiheit (will man diese, ist eine alternative Seite erforderlich).
• AJAX-basierte Seiten sind nicht zum anonymen Betrachten (z.B. mit Tor) geeignet.
• Sicherheitsrisiken (vgl. Ajax wird zum Einfallstor für Hacker)
• Der Browser verwaltet nicht die Aufrufe und Ergebnisse der JavaScript-Routinen, wodurch bestimmte Grundfunktionalitäten wie Vor/Zurück, Lesezeichen oder Quelltextanzeige nicht mehr so funktionieren, wie man es bei normalen Seitenaufrufen erwartet.

Das Problem an der Popularität von AJAX ist jedoch, daß es im Moment keine wirkliche Alternative gibt — zumindest eine, die diese Probleme nicht hat. Aber einen Lichtblick gibt es schon am Ende des Horizonts: XForms in Kombination mit XHTML 2.0. Nur das wird noch ein paar Jahre dauern. Zwar wurde XForms schon vor vier Jahren zum w3c-Standard, die Einbettung in HTML 2.0 läßt noch auf sich warten. Und dann müssen es erst einmal auch alle Browser können... Ich warte!