1. Aral Balkan: @aaronpk Both. I believe part of the problem is that the rel link didn’t work for Twitter (t.co?) when I tried it first (seems to be now).

    Aral Balkan sounds like your old links from when twitter’s t.co broke everything (now fixed) were cached the first time you tried — I think Aaron Parecki is adding “last fetched” indicator to make such bugs easier to detect and get round. Also your email address has relme, so you should be able to log in using Persona — yay multiple providers.

  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. Hugo Roy: @BarnabyWalters OK. BTW Taproot looks amazing, well done! but what's the indieauth for? I can auth but then, what can i do?

    @hugoroyd thanks! Currently indieauth login is just for me to post stuff, in the future I’ll use it to implement private content e.g. private notes, enhanced checkin resolution, maybe even spelling corrections :) Comments only accepted via indieweb commenting

  4. Hugo Roy: @BarnabyWalters @ar i'm curious how you get suggestions from ddg.gg (just testing the comments and indieauth)

    @hugoroyd I don’t actually get suggestions from DDG, the suggestions are from Google, but my search goes through DDG. Thinking about it, this probably actually negates many privacy benefits and I should turn it off.

  5. Yesterday we at Vísar tested the neat SVG image element hack on all the devices and browsers we had at hand to see how it performed and whether or not it was viable to use in production.

    Given this markup:

        <image xlink:href="http://example.com/the-image.svg" src="http://example.com/the-image.png" width="100" height="100" />

    Here’s a table of what each browser+device downloaded:

    Browser Format Requested
    Mob. Safari iOS 4.2.1 PNG
    Mob. Safari iOS 6.1.3 SVG
    Chrome 28 Mac SVG
    Safari 5.1.9 Mac SVG
    Safari 6.0.5 Mac SVG
    Firefox 26 Mac SVG
    Firefox 22 Mac SVG
    IE 8.0.6 PNG
    IE 10 SVG+PNG
    Kindle (3rd gen) PNG

    Note that the Kindle downloaded the PNG despite having pretty good SVG support. Tests carried out locally by watching the Django request logs.

    At first, this looked perfect — browsers which supported SVG only downloaded the SVG (apart from IE 10), and other browsers just got the PNG. However, it seems that SVG image elements can’t be sized with percentages, meaning our flexible layouts were never going to work. I tried to fix it using the dreaded viewBox and user units (as I have previously to compensate for percentage-based units not being allowed in SVG paths), but that just led to everything being completely the wrong size.

    So, (unless someone can show me how to fix this), whilst we think this is a great hack, it’s not going to work out for our product due to the weirdness of SVG sizing limitations.