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

Embracing Progressive Enhancement

Embracing Progressive Enhancement

We are perpetually on our toes to absorb the latest technologies that power the web and make use of them in our projects. However, in doing so, we often overlook and break the principles that the web has been built on over the past two decades. Even if we choose to turn blind towards philosophies, standards or doing things the right way, we simply cannot ignore the proliferation and diversity of devices and user agents today.

These slides were used to conduct a workshop that revisited the spirit of the web — understanding what makes the web special and how to embrace the principle of progressive enhancement to build robust websites.

“The best way to be future-proof is to be backwards compatible.”

Souvik Das Gupta

February 13, 2014

More Decks by Souvik Das Gupta

Other Decks in Programming


  1. Embracing Progressive Enhancement

  2. @souvikdg

  3. None
  4. Objectives • Revisit the design of web and how it

    works • Progressive enhancement and its importance • Write code keeping progressive enhancement in mind • Peer review and learn form each other’s experience
  5. Learning syntax or making pretty interfaces is NOT an objective

    of this workshop
  6. Agenda • Zone in (25 mins) • Understand our project

    (15 mins) • Develop the project • HTML (40 mins) • CSS (20 mins) • JS (50 mins) • Zone out (15 mins) break
  7. Conduct • Ask, don’t be shy • Contribute, don’t withhold

    knowledge • Code, or at the very least assist • Give feedback, take feedback, keep it constructive • Mutual respect
  8. Q: Why do we not care about some web browsers?

  9. What’s the Web?

  10. Tim Berners-Lee, 1989

  11. Built upon amazing design principles

  12. Tim Berners-Lee Date: 1998 Status: personal view only http://www.w3.org/DesignIssues/Principles.html

  13. Simplicity “Keep it simple, stupid!”

  14. Modular Design

  15. Being part of a Modular Design

  16. Tolerance “Be liberal in what you require but conservative in

    what you do”
  17. Decentralization

  18. Test of Independent Invention “If someone else had already invented

    your system, would theirs work with yours?”
  19. Principle of Least Power

  20. An essay on W3C’s design principles • Introduction • Maintainability

    • Modularity • Minimum redundancy • Accessibility • Device-independency • Internationality • Extensibility • Learnability • Readability • E ciency • Binary or text format • Implementability • Simplicity • Longevity • Backwards compatibility • Interoperability • Repurposing of content • Timeliness • Use what is there • Design by committee • Expertise • Brevity • Stability • Robustness http://www.w3.org/People/Bos/DesignGuide/toc.html
  21. W3C Mission • Web for All • Web on Everything

    • Web for Rich Interaction • Web of Data and Services • Web of Trust http://www.w3.org/Consortium/mission.html
  22. As a result…

  23. It has been around for more than 2 decades

  24. Today, the web is turning ubiquitous

  25. Ubiquity comes with client fragmentation

  26. For a long time we’ve focussed on Graceful Degradation

  27. But now there are just too many browsers

  28. And oh! • Text mode browsers. • Screen readers. •

    Read it later services. • Flipboard • Bots, spiders. • …
  29. More variables • Devices Capabilities • Screen Dimensions • Methods

    of interaction • …
  30. “Inclusive Web Design For the Future” Steve Champeon and Nick

    Finck, 2003
  31. Progressive Enhancement

  32. Content

  33. Content HTML

  34. Content HTML CSS

  35. Content HTML CSS JS

  36. What is the Web, again?

  37. Protocol HTTP

  38. URLs for every possible resource on the web

  39. Files mostly HTML, CSS, JS and media

  40. Workshop Project

  41. HasExpenses

  42. Knowns

  43. Activity 1

  44. Identify Purpose Prioritise Goals

  45. Goals? • Consumable • Functional • Aesthetic • Fast •

    Accessible • Reachable/Locatable • …
  46. The Protocol: HTTP

  47. Methods

  48. Methods Get, Put, Post, Delete

  49. GET vs POST

  50. URLs

  51. URLs are for people

  52. “Cool URIs don’t change” http://www.w3.org/Provider/Style/URI.html

  53. Activity 2

  54. Give URL to everything

  55. Files

  56. Content

  57. Markup

  58. HTML

  59. HTML gives structure and meaning to content

  60. If a machine can understand it, the content becomes functional

    and accessible
  61. Think meaning, not looks

  62. Create Once, Publish Everywhere http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/

  63. Again, what design principles!

  64. HTML is forward compatible i.e. older systems will happily work

    with new tags and attributes
  65. On the flip side, almost any code we write will

    appear to work
  66. Tags like <i> and <b> have subtle semantics Don’t use

    them for visual styling
  67. Use the right HTTP methods

  68. Style

  69. CSS

  70. Style can assist functionality but it’s not a robust mechanism

    of delivering functionality
  71. Use colours to indicate meaning? What about folks who are

    colour blind?
  72. Use colons after field labels? That’s just a convention or

    a style
  73. Pretty robust Unknown rules are ignored

  74. Order rules carefully so that the newer rules are at

    the end
  75. Do all websites need to look exactly the same in

    every browser?
  76. http://dowebsitesneedtolook exactlythesameineverybrowser.com

  77. It’s okay if the old browsers don’t achieve style parity

  78. Media Queries • width • height • device-width • device-height

    • orientation • aspect-ratio • device-aspect-ratio • color • color-index • monochrome • resolution • scan • grid
  79. Web is responsive Just keep it that way

  80. There’s NO mobile web

  81. Behaviour

  82. Scripts

  83. Javascript

  84. “Any application that can be written in JavaScript, will eventually

    be written in JavaScript” http://www.codinghorror.com/blog/2007/07/the-principle-of-least-power.html
  85. Javascript error handling isn’t as robust as HTML and CSS

  86. Procedures perhaps cannot have a “default” logic

  87. And so, Javascript can fail

  88. Murphy’s law

  89. Dependence on Javascript is a mistake

  90. Dependence on Javascript is a mistake

  91. Dependence on Javascript is a mistake

  92. Dependence on Javascript is a mistake

  93. Which is not to say don’t use Javascript

  94. Just be prepared for failures

  95. Avoid inline styles Instead, add or remove classes

  96. Make JS unobtrusive

  97. Browser sni ng? No!

  98. Detect Features not browsers, devices, etc.

  99. Enter Modernizr

  100. It’s Javascript time Exhibit restraint, plan well

  101. Parting thoughts…

  102. Design hacks are okay as long as you are following

  103. Hatred for browser bugs is di erent than hatred for

    old (or less featured) browsers
  104. Supporting the latter does not mean that you have to

    make them look or work the same way
  105. Polyfills are often unnecessary

  106. Using front-end frameworks doesn’t really prevent progressive enhancement

  107. When you ASSUME you make an ass out of u

    and me
  108. Q: Why do we not care about some web browsers?

  109. Because we’re not as flexible as the medium demands us

    to be
  110. A Dao of Web Design http://alistapart.com/article/dao/

  111. Thanks!