Downloaded 84 times
Uploaded byChristian Heilmann
Understanding progressive enhancement - yuiconf2010
The document discusses the principles of progressive enhancement and provides examples of how to implement it. Progressive enhancement involves building web applications that provide basic functionality to all users and then enhance the experience for those with newer browsers and capabilities. It emphasizes testing for support before applying enhancements and avoiding the need to degrade functionality. This approach allows web applications to work for all users while taking advantage of newer features where available.
More Related Content
Similar to Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
- 1. Write less -achieve more Understanding progressive enhancement with YUI
- 2. Progressive enhancement gets a badrep these days.
- 3. The reason isnot that it is a bad idea.
- 4. The reason isthat it is misunderstood.
- 5.
- 6. A Chrome extension willnever have to work in IE6 - there is no point in that.
- 7. iPad/iPhone/Air apps are much easierthan building a web app.
- 8.
- 9.
- 11.
- 12. Technology annoyances are as muchannoyances as physical ones.
- 14. HTML5 does not meanbuilding apps for iPad, iPhone and Android.
- 15. It is veryeasy to fall in this trap as developers.
- 16. Everybody has JavaScriptthese days “ “
- 17. I don’t reallycare about the numbers.
- 18. To me, itis about celebrating the power of the web and software.
- 19. The physical world canbe a real pain.
- 22. The most powerful toolof code is the if(){} statement.
- 23. Take that “if”and make it part of your approach to development...
- 24.
- 25. Add after you testedfor it.
- 26. That way younever have the need to degrade gracefully.
- 27. Building for theweb means open development.
- 29. The web isa scary place.
- 30. But it isso worth it!
- 31.
- 32. You can leavenow - I don’t need you any longer to watch my videos! “ “
- 33.
- 34.
- 35. Complex software willalways have vulnerabilities and motivated adversaries will always work to discover and take advantage of them. There is no evidence that upgrading away from the latest fully patched versions of Internet Explorer to other browsers will make users more secure.
- 36. It is notstraightforward for HMG departments to upgrade IE versions on their systems. Upgrading these systems to IE8 can be a very large operation, taking weeks to test and roll out to all users.
- 37. To test allthe web applications currently used by HMG departments can take months at significant potential cost to the taxpayer. It is therefore more cost effective in many cases to continue to use IE6 and rely on other measures, such as firewalls and malware scanning software, to further protect public sector internet users.
- 39. And this iswhy we need progressive enhancement.
- 40. Which is not “makingit work for IE6”.
- 41. Instead it is“test for support before you apply” http://www.modernizr.com/ http://github.com/phiggins42/has.js
- 42. Let’s go througha few examples of how progressive enhancement works.
- 43.
- 44.
- 48.
- 49. ★ There isno real navigation happening here. ★ Everything is dependent on JS. ★ This is what buttons are for. ★ And they are keyboard accessible.
- 50. Speeding up the processfor the next visit.
- 52. Leaving fairyland and movingto the web...
- 53. A very common approachto PE...
- 54. Progressive enhancement by using asingle page as the data container.
- 55.
- 57. Pro: Always works -it is an HTML document Con: Can result in huge sites (but gzip helps)
- 58. Another approach: Using thebackend as a simple API.
- 59.
- 60.
- 61. Write the appas a simple form submit in PHP...
- 63. Then return chunks ofHTML according to the parameters that came in.
- 66. Override the requests withAjax calls.
- 68. You maintain your wholeapp on the server and can monitor and cache like heck.
- 69. And you stilluse the goodness that is JavaScript on top of that.
- 70. Pro: Re-use of serverincludes as APIs possible. Least amount of JS and HTML generation in JS. Con: Needs server component knowledge
- 71. Every app worksas a server-client connection in some way.
- 72. The data hasto come from some place.
- 73. The myth ofclient- side security.
- 74. Every JS developer sooneror later writes a form validator.
- 75. This is alwaysthe killer argument of enemies of progressive enhancement.
- 76. I spend alot of time doing form validation in JavaScript - why should I repeat the same on the server side? “ “
- 77. Because there isno security in JavaScript!
- 78. If all youdo is validate in JS, attackers will have a field day with your server.
- 79. Besides, there isno need to repeat validation rules.
- 82. That way you validateon the server and you can use the same rules for your JS...
- 84.
- 85. You need toaccess the right parts, read and write from the DOM, change styles and and and...
- 86. You can leaveit all to the server and still save your users a full page reload.
- 87. Request type switching isthe answer.
- 88. JavaScript libraries add aspecial footprint to the server request when calling content via Ajax.
- 90. You can usethis to send content to Ajax requests and other content to normal requests.
- 92. You can usethis to render a form completely server side and just send a string back for each request. http://github.com/codepo8/validationdemo
- 94. Filter inputs for nastiesand include the rules.
- 95. If the formhas not been submitted, include the form code.
- 96. Otherwise loop throughthe rules and check the data that was sent against them. this is like /pattern/.test($(name).value)
- 97. If there wasan error - show the form again. Otherwise say thanks.
- 98. The form itselfis a simple HTML form doing all the dynamic rendering with PHP...
- 100. Check for theerror array and if there is an error, show it. Otherwise show a * to indicate required field.
- 101. Check if theform was sent via Ajax - if not, render the form element.
- 102. If there wasan error, say so. At the field show the error or the * SPAN.
- 103. And all youthen need to do in JavaScript is to override the form submission.
- 104. And instead replace theinnerHTML of the form on every submit.
- 105.
- 106. Load the IOand Node module. Define the configuration for the Ajax call. On submission of the form load the validate.php file with the config and don’t send off the form.
- 107. If the Ajaxcall was a success, replace the innerHTML of the form with the HTML returned from validate.php
- 108. In addition tothat, focus on the first element with an error message - this helps with assistive technology.
- 109. If the Ajaxcall failed, send the form.
- 110. Subscribe to theAjax events.
- 111. Build what works foreverybody and then enhance.
- 112.
- 113.
- 114. For a lotof new developers, this looks like extra effort.
- 115. Instead we producelow quality fallbacks.
- 116. This is notthe web I want people to get!
- 117.
- 118. Progressive Enhancement is a hugepart of the YUI philosophy.
- 120.
- 121. Today’s widgets are alreadytomorrow’s native controls.
- 122.
- 123.
- 124.
- 126.
- 127. The future ofweb apps is being forged right now.
- 128.
- 130. Be part ofthe movement for a better web for all.
- 131. HTML5 means moving fromhacks to web applications.
- 132. So let’s builda working web for all.
- 133. Come and talkto us, to Google, to Apple, to Mozilla, to Opera, to Microsoft... Your input matters!
- 134.