Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zum Archiv und den Kategorien

Codesnippets auf Smartphone präsentieren

Sonntag, 27. März 2016

Die korrekte Darstellung von Codesnippets auf dem Desktop muss einigen Forderungen gerecht werden:

  • Zur besseren Lesbarkeit des Codes sollten Einrückungen wie im Editor dargestellt werden.
  • Der Code sollte zur Darstellung nicht umgebrochen werden.
  • Aus diesen beiden Forderungen ergibt sich häufig eine Breite, die über den verfügbaren Raum hinausläuft.
  • Mögliche Lösung: Eine Box, die unabhängig vom restlichen Seiteninhalt gescrollt werden kann.

Erstaunlicherweise funktioniert so eine Lösung sogar auf dem Smartphones, wie folgender Screencast vom iPhone zeigt:

Ab 0:20 wird gezeigt, wie der Kasten mit dem Code mit dem Finger gescrollt werden kann.

Der Code:

Das Codesnippet wird in ein <code> Tag gepackt.
Dazu folgendes CSS:

code {
white-space: pre;
overflow:auto;
display:block;
border:1px dashed;
}


Das HTML5 picture Element - jetzt von allen aktuellen Browsern unterstützt

Freitag, 25. März 2016

iOS 9.3 - die beste Nachricht, und niemand berichtet darüber, niemanden scheint das zu interessieren:
iOS 9.3 unterstützt das HTML5 picture Element. :-)

Demo:

Hier der Alternativtext für Screen Reader - nur ein Alternativtext für alle Größen!
Dunst über einem stillen See
Bild: http://unsplash.com/

Damit wird das picture Element von ALLEN aktuellen Browsern unterstützt.
www.caniuse.com/#search=picture
Ein großer Schritt für RWD (Responsive Web Design).
Ich bin versucht, das ab sofort einzusetzen, und dem IE nur noch zu liefern, was ihm zusteht: ein Fallback img src in Einheitsgröße.

Wenn du oben das folgende Bild siehst, dann unterstützt dein Browser das picture Element (noch) nicht:
Fehlerbild

Hier der Quellcode zu obiger Demo:

<picture>
<source media="(max-width: 639px)" srcset="images/flashlight_240.jpg" >
<source media="(min-width: 640px)" srcset="images/flashlight_600.jpg">
<!– fallback if picture is not supported –>
<img src="images/picture_not_supported.png" alt="Hier der Alternativtext für Screen Reader - nur ein Alternativtext für alle Größen!">
</picture>

Nachtrag 26.03.2016

Das hätte ich jetzt wirklich nicht erwartet: picture kann sogar zusammen mit Fancybox verwendet werden.


Google Analytics rechtssicher einsetzen

Dienstag, 22. März 2016

Google Analytics ist seit Jahren im Visier der Datenschützer. Und gleichzeitig das beliebteste Analysetool überhaupt.
Ein aktuelles Urteil des Landgerichts Hamburg (Az. 312 O 127/16) hat wieder einmal in Erinnerung gebracht, welcher Aufwand seitens des Webseitenbetreibers erforderlich ist, um das Risiko kostspieliger Abmahnungen zu vermeiden.
Die gute Nachricht:
Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit listet klar die Anforderungen auf:

  • Webseitenbetreiber müssen den von Google vorbereiteten Vertrag zur Auftragsdatenverarbeitung schriftlich abschließen. Diesen Vertrag erhalten Sie unter http://www.google.com/analytics/terms/de.pdf.
  • Webseitenbetreiber müssen die Nutzer Ihrer Website in Ihrer Datenschutzerklärung über die Verarbeitung personenbezogener Daten im Rahmen von Google Analytics aufklären und auf die Widerspruchsmöglichkeiten gegen die Erfassung durch Google Analytics hinweisen. Hierbei sollte möglichst auf die entsprechende Seite „http://tools.google.com/dlpage/gaoptout?hl=de“ verlinkt werden.
  • Webseitenbetreiber müssen durch entsprechende Einstellungen im Google Analytics-Programmcode Google mit der Kürzung der IP-Adressen beauftragen. Dazu ist auf jeder Internetseite mit Analytics-Einbindung der Trackingcode um die Funktion „_anonymizeIp()“ zu ergänzen.

Quelle: www.delegedata.de


Endlich verschlüsselt SSL/TLS/https

Sonntag, 20. März 2016

Meine Site wird ab sofort gesichert / verschlüsselt ausgeliefert. SSL/TLS/https

Screenshot
Im Browser wird vor der Adresse ein grünes Schloss angezeigt, als Zeichen für korrekte Verschlüsselung.

Die inzwischen fast 12 Jahre alte Site ist damit zumindest "unter der Motorhaube" jetzt auf dem aktuellen Stand der Technik. (Ja, ich weiß; das Design ist alles andere als modern.)

Die "Tuningmaßnahmen" im Zeitverlauf:

  • RWD (Responsive Web Design), früher: Layout für Handys/PDAs — gibt's bei mir schon lange.
  • HTML5 seit 2014.
    In der Folge alle Multimedia-Inhalte (Audio, Video) ohne Flash.
  • UTF-8 seit April 2015
  • und jetzt SSL/TLS

Das "Tuning" gilt selbstverständlich auch für alle von mir angebotenen Tools (Chat, Suchscript usw.). Auch diese Tools können mit HTML5, UTF-8, RWD und SSL/https, sowie ohne Flash. Letzteres ist Voraussetzung für die Nutzung auf Tablets und Smartphones mit iOS oder Android.

Eine Einschränkung, die ich gerne in Kauf nehme: Mit dem IE8 unter WindowsXP ist webdesign.weisshart.de leider nicht mehr erreichbar.


Google Webfonts und SSL

Freitag, 18. März 2016

Webfonts von Google kann man ganz einfach direkt von font.googleapis.com einbinden, ohne sie auf dem eigenen Server zu installieren.

<link href='http://fonts.googleapis.com/css?family=NamedesFonts' rel='stylesheet' type='text/css'>

Heute hat mein — zugegebenermaßen sehr restriktiv konfigurierter — Firefox sich plötzlich geweigert, solcherweise eingebundene Fonts zu benutzen.

Screenshot
So sollte es aussehen: Eine mit Webfonts gestylte Überschrift.
Screenshot
Wenn der Webfont nicht verfügbar ist, wird schlimmstenfalls das Layout zerschossen. Hier durch einen unerwünschten Zeilenumbruch.

Die Lösung war dann doch relativ schnell gefunden: Einfach googleapis.com per SSL aufrufen. Also:

<link href='https://fonts.googleapis.com/css?family=NamedesFonts' rel='stylesheet' type='text/css'>

Vielleicht hilft der Hinweis dem einen oder anderen Webworker.

NB:
Ich hab' bei der Gelegenheit auch gleich andere Zugriffe auf googleapis.com auf SSL umgestellt. Z. B. jQuery


AMP Accelerated Mobile Pages Project

Donnerstag, 17. März 2016

Google startet AMP [englisch] (Accelerated Mobile Pages Project)
Die Absicht dahinter: Seiten, die schnell laden. Auch und vor allem auf mobilen Geräten. Gut.
Und wenn Google so etwas macht, dann muss man es wohl ernst nehmen.

Mein erster Eindruck: Die Seiten scheinen im iPhone wirklich schnell zu laden.

Screenshot
Die Startseite des Projekts

Bei näherem Hinschauen zeigen sich leider einige "Besonderheiten":

  • Um zu testen, ob eine Seite schlank ist, und schnell lädt, gibt es ein allgemein anerkanntes Tool. Webpagetest.org.
    Dieses Tool zeigt leider mobil 747 kB für eine Seite. Das meiste davon JavaScript. Die Seite selbst besteht nur aus Text, und einem eingebundenen YouTube Video. Dafür braucht es keine 747 kB. Das lässt sich mit max. 200 kB lösen.
    JavaScript async laden macht zwar die Seite möglicherweise schnell, belastet aber dennoch mein Volumenbudget. Aufgabe leider nicht gelöst!
  • Die mobile Seite scheint kein Navigationsmenü zu besitzen! Erst Rumprobieren führt zufällig zum Ergebnis: Man muss auf dem Smartphone nach links wischen, um das Menü zu zeigen. In meinen Augen ein Usability Gau.
  • Die Seiten sind nicht valide. Daran ändert sich auch nichts, wenn man einen speziellen Validator entwickelt. Was soll denn der Unfug? Wenn meine Seiten nicht valides HTML beinhalten, dann entwickle ich einfach ein Werkzeug, das sagt, sie seien dennoch valide.
  • Mit der Barrierefreiheit der Seiten scheint es auch nicht sehr weit her zu sein. Zumindest zeigen alle meine Testwerkzeuge mehr oder weniger Fehler. In wie weit die vielen ungültigen HTML Tags die Zugänglichkeit mit Assistiven Technologien beeinträchtigen, müsste noch speziell getestet werden.

Archiv:

Kategorien:

Creative Commons Lizenzvertrag
Alle Texte (nicht Bilder!) Creative Commons CC BY-NC-SA 3.0 DE