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. Reminder: If it’s not hypertext, doesn’t have a URL, has no hyperlinks, isn’t navigable in a web browser: it’s not the web.

  3. 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:

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

    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.

  4. Pondering the utility of a “draft blog post titles” listing on my homepage, partly as a teaser, partly as a reminder to myself