1. And the lesson of the day is: bean.fire(el, 'click') doesn’t work in Firefox Nightly, but turns out it’s unnecessary, because HTMLElement.click() does exactly the same thing and already works cross-browser. Always use the browser-native APIs if you can.

  2. My take on generic prev/next controls on keyup, using only bean for events, based on previous work by Aaron Parecki and Tantek Çelik:

    
    // Generic prev/next navigation on arrow key press
    bean.on(document.body, 'keyup', function (e) {
      var prevEl, nextEl;
      
      if (document.activeElement !== document.body) return;
      if (e.metaKey || e.ctrlKey || e.altKey || e.shiftKey) return;
      
      if (e.keyCode === 37) {
        prevEl = document.querySelector('[rel~=previous]');
        if (prevEl) bean.fire(prevEl, 'click');
      } else if (e.keyCode === 39) {
        nextEl = document.querySelector('[rel~=next]');
        if (nextEl) bean.fire(nextEl, 'click');
      }
    }); 
    
  3. Need to use require.js to load a bunch of scripts compiled via assetic into a PHP file, annoyed by auto-append of .js, don’t want to set up irritating routing? Add a ? to the URL, require.js will add a .js to the query string, loading the file correctly.

  4. Kyle Weems: I dislike having to deal with kludgy browsers too. But I also know my clients aren't interested in turning away many of their customers.

    cssquirrel Zepto is nice for browser extensions, where the browser will always be modern and capable

  5. Kyle Weems: function awesomeWorkday(tasks){if (tasks instanceof coolJsonStuff || tasks instanceof coolApiStuff) { return true; } else { return false;}}

    cssquirrel even the if/else is redundant ;)

    
    function awesomeWorkday(tasks) {
      return (tasks instanceof coolJsonStuff || tasks instanceof coolApiStuff) ? true : false;
    }
    

  6. Cross-browser selection UI injection flow:

    1. Listen for mouseup on body
    2. When triggered, let s be window.getSelection()
    3. If s.isCollapsed === false, return
    4. Else, let r be s.getRangeAt(0)
    5. Create a new element e
    6. Call r.surroundContents(e)
    7. e.innerHTML and e.textContent now return useful values, and e’s coordinates can be used to inject UI into the page

    To resolve: what element should e be? Or more accurately, what display property should it have? Possibly inline-block (inline mucks up if selection is across block elements, block mucks up selections within text nodes)

    Turns out there are problems with r.surroundContent, namely that it does not handle partial element selections. See MDNs explanation and solution.
  7. Pushed lots of note UI updates to today, including porting almost all the to Backbone. Still :

    • Improving location UI: improve cancelled state text, fix located state
    • Make a view for note lists, inc. event handling like add new note to the list when it’s posted from the dialog. This will also minimise the number of requests.
    • Make the backend auto-add hashtags to the note tags property. It should have been this way all along.
  8. Just pushed a plugin which auto–populates the <ins> and <del> elements with their little–known datetime and cite attributes. Hopefully, coupled with my article update histories and a bit of , this’ll allow for some native-HTML version control type stuff.