• Resilient Web Design

    temps de lecture - 1 heure

    The World Wide Web has been around for long enough now that we can begin to evaluate the twists and turns of its evolution. I wrote this book to highlight some of the approaches to web design that have proven to be resilient. I didn’t do this purely out of historical interest (although I am fascinated by the already rich history of our young industry). In learning from the past, I believe we can better prepare for the future.

    You won’t find any code in here to help you build better websites. But you will find ideas and approaches. Ideas are more resilient than code. I’ve tried to combine the most resilient ideas from the history of web design into an approach for building the websites of the future.


    Java is to JavaScript as ham is to hamster.

    C’est marrant. Mais il y a des informations sérieuses aussi.

    The rise of JavaScript was boosted in 2005 with the publication of an article entitled Ajax: A New Approach to Web Applications by Jesse James Garrett. The article put a name to a technique that was gaining popularity. Using a specific subset of JavaScript, it was possible for a web browser to send and receive data from a web server without refreshing the whole page. The result was a smoother user experience.

    The term Ajax was coined at the same time that another neologism was in the ascendent. Tim O’Reilly used the phrase Web 2.0 to describe a new wave of web products and services. Unlike Ajax, it was difficult to pin down a definition of Web 2.0. For business people, it meant new business models. For graphic designers, it meant rounded corners and gradients. For developers, it meant JavaScript and Ajax.

    ... puis ...

    Stuart Langridge put together a list of all the potential points of failure under the title Everyone has JavaScript, right?
    This doesn’t mean that web designers shouldn’t use JavaScript. But it does mean that web designers shouldn’t rely on JavaScript when a simpler solution exists.
    ...A platform provides a controlled runtime environment for software. As long as the user has that runtime environment, you can be confident that they will get exactly what you’ve designed. If you build an iOS app and someone has an iOS device, you know that they will get 100% of your software. But if you build an iOS app and someone has an Android device, they will get 0% of your software. You can’t install an iOS app on an Android device. It’s all or nothing.

    The web isn’t as binary as that. If you build something using web technologies, and someone visits with a web browser, you can’t be sure how many of the web technologies will be supported. It probably won’t be 100%. But it’s also unlikely to be 0%. Some people will visit with iOS devices. Others will visit with Android devices. Some people will get 80% or 90% of what you’ve designed. Others will get just 20%, 30%, or 50%. The web isn’t a platform. It’s a continuum.


    To paraphrase Karl Marx, progressive enhancement allows designers to ask from each browser according to its ability, and to deliver to each device according to its needs.


    Feature detection, cutting the mustard, whatever you want to call it, is a fairly straightforward technique. Let’s say you want to traverse the DOM using querySelector and attach events to some nodes in the document using addEventListener. Your mustard‐cutting logic might look something like this:

    if (document.querySelector && window.addEventListener) {
    // Enhance!
    There are two points to note here:

    This is feature detection, not browser detection. Instead of asking “which browser are you?” and trying to infer feature support from the answer, it is safer to simply ask “do you support this feature?”
    There is no else statement.


    As Brad Frost puts it:
    “There is a difference between support and optimization.”
    Support every browser ...but optimise for none.


    “Always design a thing by considering it in its next larger context”
    Here’s a three‐step approach I take to web design:

    – Identify core functionality.
    – Make that functionality available using the simplest possible technology.
    – Enhance!


    Building resilient websites is challenging. It takes time to apply functionality and features in a considered layered way. The payoff is a website that can better react to unexpected circumstances—unusual browsers, flaky network connections, outdated devices. Nonetheless, for many web designers, the cost in time seems to be too high.


    Behaviour change is hard. Even if you are convinced of the benefits of a resilient approach to web design, you may find yourself struggling to convince your colleagues, your boss, or your clients. It was ever thus. Take comfort from the history of web standards and responsive design. Those approaches were eventually adopted by people who were initially resistant.

    Demonstrating the benefits of progressive enhancement can be tricky. Because the payoff happens in unexpected circumstances, the layered approach is hard to sell. Most people will never even know whether or not a site has been built in a resilient way. It’s a hidden mark of quality that will go unnoticed by people with modern browsers on new devices with fast network connections.

    For that same reason, you can start to implement this layered approach without having to convince your colleagues, your boss, or your clients. If they don’t care, then they also won’t notice. As Grace Hopper also said, “it’s easier to ask forgiveness than it is to get permission.”


    Realising that it was impossible to be future‐proof, we instead resolved to be future-friendly:

    Acknowledge and embrace unpredictability.
    Think and behave in a future-friendly way.
    Help others do the same.
    That first step is the most important: acknowledging and embracing unpredictability. That is the driving force behind resilient web design. The best way to be future-friendly is to be backwards‐compatible.


    The future, like the web, is unknown.

    The future, like the web, will be written by you.

    #internet #www

  • Why I won’t be using Fetch API in my apps

    “this is not a rant against fetch! I don’t think that the points presented are design flaws, all of them make perfect sense for a low level API. I’m just saying that I wouldn’t recommend to use low level API’s such as this directly in your application”


  • thematic mapping blog: Showing geotagged photos on a #leaflet #map

    I’ve create a new #plugin, Leaflet.Photo, that allows you to add geotagged photos to your map, from any source. The plugin plays well with the great Leaflet.markercluster plugin, showing your photos in clusters. To make the plugin more versatile, it doesn’t deal with AJAX loading or image presentation except the thumbnails on the map. Use your AJAX loader of choice, and simply pass on an array of #photo objects to the plugin.

    The photo objects can include the properties you like, but the following are required:

    lat: latitude of photo

    lng: longitude og photo

    thumbnail: url to thumbnail photo



    • Perso coté client, je penser continuer d’utiliser jQuery ; généralement je m’en sers pour manipuler le DOM, avec le chargement de données n’étant qu’une partie anecdotique (et généralement utilisable à mon goût). Charger une lib de plus ne me paraît pas utile.

      Je pensais surtout à remplacer request. C’est une librairie Node qui fait la même chose mais est pleine de problèmes.

  • : This site aims to provide the simplest possible examples of HTML, CSS and #JavaScript.

    Ajax (aka XMLHttpRequest)
    Array methods: some, every, filter, forEach, map
    Audio Data
    Battery API
    CSS filters
    CSS negative selector
    CSS text-indent
    CSS transition
    Device Orientation
    Fieldset (localStorage example)
    FileSystem using Blob
    getUserMedia() with constraints
    History pushState() and popState()
    Hyphenation (soft hyphen)
    Image: a big one (20MB)
    Input types: email, tel, url, date, time, colour
    Media Capture (using <input>)
    Navigation Timing (window.performance)
    Page Visibility API
    querySelector() and querySelectorAll()
    <track> with <video>
    <track> with <audio>
    <video> (with autoplay)
    <video> (with scripted playback)
    long video (~380MB)
    video with src media query
    video with <div> overlay
    Web Audio
    Web Fonts
    Web Intents
    Web Workers
    XMLHttpRequest (aka Ajax)

  • ACE - Cloud9 Editor

    Ace is a standalone code editor written in JavaScript. Our goal is to create a web based code editor that matches and extends the features, usability and performance of existing native editors such as TextMate, Vim or Eclipse. It can be easily embedded in any web page and JavaScript application. Ace is developed as the primary editor for Cloud9 IDE and the successor of the Mozilla Skywriter (Bespin) Project.

    #JavaScript #code_editor #webdev #geektools

  • Just One Of Those Things You Need To Understand About JavaScript | CSS-Tricks

    While this is “just how JavaScript works” it’s a known pain in the butt. Since jQuery is a library that exists to ease pains like this, of course it has a better way. That way is the .delegate() function, where instead of binding events to the individual elements, you bind an event to an element higher up the DOM tree, which isn’t likely to be replaced via Ajax, which watches for those clicks.

    This relies on something called event bubbling, which a neat and important concept in JavaScript. If you click on a thumbnail, it will trigger a click event on that element, then a click event on it’s parent element, and a click event on it’s parent’s parent element, all the way up to the root element. Because of this, we can watch for clicks on deeper-down elements from higher-up elements.

    Je trouve que ça n’explique pas vraiment la différence entre .delegate() et .live(), la doc officielle de #jQuery n’est pas non plus super-claire.

    Si quelqu’un a de la doc sur les spécificités de .delegate(), ça me branche.

  • TouchScroll, a scrolling layer for WebKit mobile [update] « – the Ajax and JavaScript Experts

    While Safari Mobile features native scrolling, there are two reasons to re-implement scrolling with JavaScript: The original scrolling behavior is rather slow – we were looking for a solution that feels more fluid. And the viewport behavior of Mobile Safari and other mobile browsers using WebKit doesn’t allow for fixed positioned elements. It is optimized for document reading, not for building interfaces.

    Our goal is to be able to deploy application interfaces to browsers of handheld devices that feel as familiar as possible for the user. TouchScroll enables developers to use fixed interface elements like headers and toolbars.

    #HTML5 #scroll

  • Create web applications stored in an Apache CouchDB database | Martin Brown;ct=dwnew&cr=dwnen&ccy=zz&csr=05


    Apache #CouchDB is an open source document-oriented #database management system that allows you to create full database-driven applications using nothing but HTML, CSS and JavaScript. In this tutorial, you will learn how to create your own #CouchApp that will perform database operations using #Ajax powered by the #jQuery framework. The application you will build is a contact manager that allows you to view, create, edit, and delete your contacts.