Erstellt mit Notizen von Tom
Slides: Mark Howells-Mead
Die Inhalte des Vortrags sind gut über die Slides nachzuvollziehen. Hier einige ergänzende Anmerkungen:
Gute Tool um zu prüfen, was in welchen Browser funktioniert: caniuse.com
Ein Breakpoint markiert die Bildschirmbreit, wenn eine andere Darstellung verwendet werden soll (responsive Sprung).
In der Regel müssen 5 verschiedene Bildschirmgrössen beachtet werden: Smartphone hoch/quer,Tablet hoch/quer, Desktop. Es gibt aber unendliche Varianten (siehe Foto auf Folie 2). Und dann noch «Retina».
Mark empfiehlt im Code den Breakpoint nicht pixel, sondern in rem zu definieren. Dabei ist 1 rem = 16px (standard). Dies spielt z.b. eine Rolle, wenn jemand Schriftgrösse im Browser auf 130% einstellt. Dann wird die Schrift nicht unnatürlich vergrößert.
960, 1024 usw, ist immer durch 16 teilbar.
960/16=reine Zahl
Unter dem Gesichtspunkt Performance gilt: Mobile first!
Die Darstellung im Handy sollte darum so light wie möglich, nur was nötig ist, damit es möglichst wenig zu laden hat. Je größer der Bildschirm, desto mehr Möglichkeiten hat man mehr Informationen in die Darstellung zu packen.
Je mehr «retina», desto feiner kann auch die Schrift sein, auch Grautöne. (= je älter, desto gröber).
Es gibt verschiedene Emulatoren (z.B. Browserstack (kostenpflichtig) Quirktools, responsivetest.net oder auch Erweiterungen für Chrom und FireFox) für die responsive Darstellung, aber manchmal kann diese vom Original abweichen. Deshalb auch immer Tests mit einem Original-Gerät. Hoch- und Querformat testen!
Ist ein Theme responsive, lädt es auf Desktop, iPad oder Smartphones unterschiedliche Inhalte. Je kleiner der Bildschirm, desto weniger wird dargestellt (Folien 6-9).
Bilder werden dabei ganz normal in WordPress eingebunden. Dabei wird jedes Bild standardmäßig in drei verschiedenen Größen gespeichert und je nach Bildschirmgröße dargestellt. Je nach Theme wird ein Bild auch in mehr Größen von WordPress gespeichert.
(Zukunft: Javascript «Service Worker». Mehr als Cache, etwas das quasi eine App in einem Browser nachbaut. Mit RestAPI, superlight, superfast, z.B. bei offline browsing, eine ganze Site durchklicken, alles bleibt danach im Browser. Verbessert die Performance!)
Die Auflösung muss keine direkte Relation haben, ob es mobile ist oder nicht!
iPad Pro hat mehr Pixel als viele Desktops. Xperia 3800px, bei 806 ppi, «Super-Retina». Oder dann hats vielleicht einen Kongressaal-Monitor.
Wenn Möglich SCG-Images verwenden. Geht nicht für Fotos.
Beispiel: sbbrcs.ch
Das Trapez links passt sich der Auflösung des Bildschirms an.
Check, ob ein Theme gut responsive ist:
* Gibt es aktuelle Updates?
* Hat die Demosite eine gute Performance (Google Page Speed Insights, GTMetrix, pingdom etc.)
[x] disable cache = es kommt immer ohne caching, pure speed getestet
* Ist es SVG-ready? (nice to have)
* Unterstützt es Responsive Images?
* Anzeige mit verschiedenen Bildschirmen und Auflösungen testen. Das Browserfenster kleiner schieben reicht dabei nicht aus! In Chrome z.B. mit Entwicklertools testen oder Emulatoren nutzen (siehe oben).
google map auf mobile, fenster muss klein genug sein besonders auf Mobile, damit finger-browserscrollen ≠ mapdragging