Gaining Control in the Great Unknown - MobileTechCon, March 2014

Stellt sich die Gerätefragmentierung von Android-Devices als der schlimmste Feind des mobilen Entwicklers heraus, ist die Browserfragmentierung nicht nur potenziell größer, sondern für Webentwickler auch mit der ständigen Angst vor dem Unbekannten gezeichnet: Welche mobilen Browser übersieht man, welche Browser werden in Zukunft noch kommen, und wie kann man sich als Entwickler vor dem großen Unbekannten schützen? In dieser Session lernen wir nicht nur die skurrilsten Bugs im Browserverhalten kennen, sondern entdecken auch das Prinzip von Progressive Enhancement für uns neu.

Transcript

1. GAINING CONTROL IN THE GREAT UNKNOWN MobileTechCon Munich - March 2014
2. Servus
3. @ddprrt
4. Netural
7. Lafers grill recipes The need precise control I need to put meat on fire
8. Weber-Kit
9. Controlled Environments
10. Controllable Environments
12. Uncontrollable Environments
20. UC Browser
21. UC Browser 400 million users 32% market-share in China
22. ... to be honest ... only few of them come with their own engine
23. Under the top-most used browsers on iOS and Android
24. Fragmentation
29. iOS screen fragmentation
30. Android screen fragmentation
31. Holy fragmentation, Batman This is friggin' scary
32. And that is just Android ...
33. What are people really using?
34. Holiday season in Austria pseudonymized target audience of a B2C website male or female age 0 to 99
35. The stats different device types: 723 different browser families: 68
36. Top 5 browser families 1. Safari 2. Chrome 3. Firefox 4. Android Stock Browser 5. Internet Explorer
37. Viewport is one thing... Features? Implementation quality? Memory? Resolution? Browser Speed? Connection speed?
38. Parallax Scrolling?
40. moto.oakley.com 1. 85.4 MB page weight 2. 471 HTTP Requests 3. 2 minutes 45 seconds until loading screen replaced with content 4. 4 minutes 10 seconds to wait for onLoad event
41. There sure is a mobile version? ... oh yeah, there is...
42. 85.9 MB
43. Costs Roaming in Switzerland for EU clients is 1€ per MB
44. Costs vodafone UK charges 1£ per 25 MB
45. Assumptions Features: Scrolling Implementation quality: Tried, trusted and Robust Memory: A shitload Resolution: Of course Retina! Browser Speed: iPad-near JS execution time Connection speed: Harddrive
46. Features
49. overflow: scroll
50. -webkit-overflow-scrolling: touch
51. Feature detection Test for overflow-scrolling, otherwise use iScroll
52. var has3d = 'WebKitCSSMatrix' in window && 'm11' in new WebKitCSSMatrix()
53. The good: We did feature detects, and polyfilled in case
54. The bad: We assumed iScroll will fix all our problems iScroll assumed hardware acceleration is a good idea overall
55. The ugly: We broke IE10 on Windows Phone 8
57. When using skrollr on mobile you don't actually scroll. When detecting a mobile browser skrollr disables native scrolling and instead listens for touch events and moves the content
58. A classic $('a').on('click', function()) { window.location.href = $(this).attr('href'); }
60. Don't recreate browser features
61. You can't control everything
62. You can't control anything
63. Brings Parallax back to its roots
64. body { perspective: 1px; transform-style: preserve-3d; } .slide:before { position: absolute; top: 0; left: 0; right: 0; bottom: 0; background-image: url("..."); transform: translateZ(-1px) scale(2); z-index:-1; } http://codepen.io/keithclark/pen/JycFw
65. Implementation quality
67. meta-Viewport <meta name="viewport" content="width=device-width, initial- scale=1.0">
68. meta-Viewport
69. <meta name="viewport" content="width=device-width, initial- scale=1.0, maximum-scale=1.0"> ... not that it does anything ...
70. @media(max-width: 320px) { @ms-viewport { width: 320px } }
71. @-ms-viewport { width: device-width; }
73. -webkit-text-stroke: 4px;
74. -webkit-text-stroke: 4px;
75. This is madness!
76. -webkit-something: something
77. For what it's worth, the current trend inside Mozilla is exactly what you say: avoiding vendor prefixes by either turning things off before shipping or shipping them unprefixed if they're stable enough. W3C List http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0731.html
78. In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback [...] Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels. Blink Developer FAQ http://www.chromium.org/blink/developer-faq
79. Vendor prefixes for experimental features experimental means: not stable, not final not stable: not ready for production
80. noPrefixes in v3.0
81. ModernizrProto._config.usePrefixes
82. "options": [ "setClasses", "addTest", "html5printshiv", "load", "testProp", "fnBind", "prefixedCSS" "noPrefixes" ],
83. Browser Speed Lightspeed
84. Truth is ... JavaScript takes long to execute
85. $('.item.' + filterCriteria).each(function() { $(this).hide(); });
86. $('.filterArea').addClass('.filterCritera'); .filterCritera .hasCritera { display: none; }
87. Where is JavaScript necessary?
88. Lanyrd
89. Lanyrd User Agent Detection ... done right! Got a slow JS engine? Don't get any JS.
90. Instagram on iOS5 2/13 - 7/13 and since 12/13
93. Browsers other than Chrome don't priorize JS over IMG assets They take everything in order, to ensure nothing is missing on execution
94. Use JavaScript to load content that's only available with JavaScript
95. 13s > 1.4s
96. sighjavascript.tumblr.com
97. Connection speed
99. A though one ... but rule of thumb is to reduce requests Load content that is necessary for the first impression
100. Reduce everything!
101. What does not kill me makes me smaller
102. RESS Responsive & Server-Side
103. if ($(document).width() > 640) { $.get('path/to/html', function(data){ $('[role="complementary"]').append(data); }); }
105. Solutions Features: Use, when certain that it's there! Implementation quality: Modern features should be an add-on Browser Speed: Less JavaScript dependent content Memory: Optimize Images, reduce Image Footprint Resolution: See above, use SVG, use Responsive Images! Connection speed: Fear for worst, reduce requests!
106. Solutions Features: Progressive Enhancement Implementation quality: Progressive Enhancement Browser Speed: Progressive Enhancement Memory: Progressive Enhancement Resolution: Progressive Enhancement Connection speed: Progressive Enhancement
107. Progressive Enhancement
109. Progressive Enhancement Provide a solid (HTML) base, something you trust and know Enhance your presentation by applying new styles Enhance further by applying behaviour with JavaScript
110. Why Progressive Enhancement
111. Not only for the old things we know
112. But also for the uncertainty of the future!
113. workingdraft.de/135
114. workingdraft.de/137
115. workingdraft.de/144