Pro Yearly is on sale from $80 to $50! »

Gaining Control in the Great Unknown - MobileTechCon, March 2014

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.

187d92c9284160ad908885ab096f5209?s=128

Stefan Baumgartner

March 20, 2014
Tweet

Transcript

  1. GAINING CONTROL IN THE GREAT UNKNOWN MobileTechCon Munich - March

    2014
  2. Servus

  3. @ddprrt

  4. Netural

  5. None
  6. None
  7. Lafers grill recipes The need precise control I need to

    put meat on fire
  8. Weber-Kit

  9. Controlled Environments

  10. Controllable Environments

  11. None
  12. Uncontrollable Environments

  13. None
  14. None
  15. None
  16. None
  17. None
  18. None
  19. None
  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

  25. None
  26. None
  27. None
  28. None
  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?

  39. None
  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

  47. None
  48. None
  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

  56. None
  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'); }

  59. None
  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

  66. None
  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; }

  72. None
  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

  91. None
  92. None
  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

  98. None
  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); }); }

  104. None
  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

  108. None
  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

  116. None
  117. None