Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Gaining Control in the Great Unknown - MobileTe...

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.

Stefan Baumgartner

March 20, 2014
Tweet

More Decks by Stefan Baumgartner

Other Decks in Technology

Transcript

  1. Top 5 browser families 1. Safari 2. Chrome 3. Firefox

    4. Android Stock Browser 5. Internet Explorer
  2. 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
  3. 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
  4. The bad: We assumed iScroll will fix all our problems

    iScroll assumed hardware acceleration is a good idea overall
  5. 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
  6. 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
  7. 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
  8. 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
  9. Browsers other than Chrome don't priorize JS over IMG assets

    They take everything in order, to ensure nothing is missing on execution
  10. A though one ... but rule of thumb is to

    reduce requests Load content that is necessary for the first impression
  11. 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!
  12. Solutions Features: Progressive Enhancement Implementation quality: Progressive Enhancement Browser Speed:

    Progressive Enhancement Memory: Progressive Enhancement Resolution: Progressive Enhancement Connection speed: Progressive Enhancement
  13. 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