1. John Nye: @BarnabyWalters last time I used mozilla it was poor experience (2011), but validation of extensions was a manual process by someone.

    .@john_nye all the stores I’ve submitted extensions to do manual reviews. Mozilla:

    • gives two review options (fast and slow),
    • runs loads of automated tests in a web interface to suggest things to fix,
    • gives you the choice of which review to use, and creates a public URL from which the extension can be installed while the review’s in process

    Safari and Opera have fairly basic, boring forms for uploading stuff, and are extremely picky and unclear about exact image sizes for screenshots and icons. There’s also no “review in progress” page, but otherwise acceptable.

    Obviously I’ve not been able to actually submit an extension to the Chrome store, but I’d hope that it’s a damned good experience for $5. If they are doing automatic reviews, then the price becomes even more counter-intuitve. If they’ve automated it, surely it’s cheaper and quicker for them?

  2. Jack Way: @BarnabyWalters I think it's to authenticate devs and reduce spam.

    .Jack Way no other extension store (mozilla, apple, opera) demands payment, or requires it for verification. Also, Mozilla offers a far superior extension upload experience. Google has no excuse :)

  3. From now on I am framing all web standards-type discussions with the question “what is it reasonable to demand that authors do”

    For example, it’s not reasonable to demand authors publish content in more than one format. It’s not reasonable to demand that authors learn how RDF works. It is reasonable to require authors to publish HTML. It is reasonable to require authors to add some simple microformats like rel-author, h-entry or h-card.

  4. myOpenID.com is dead. OpenID is dead. Long live Web Sign-In.

    I got an email saying the service will end on 2014-02-01, but the site appears to be down already. janrain.com, the company who apparently ran myOpenID, is also down, so I can’t find a “goodbye” post. Here’s the notification email:

    I wanted to reach out personally to let you know that we have made the decision to end of life the myOpenID service. myOpenID will be turned off on February 1, 2014.

    In 2006 Janrain created myOpenID to fulfill our vision to make registration and login easier on the web for people. Since that time, social networks and email providers such as Facebook, Google, Twitter, LinkedIn and Yahoo! have embraced open identity standards. And now, billions of people who have created accounts with these services can use their identities to easily register and login to sites across the web in the way myOpenID was intended.

    By 2009 it had become obvious that the vast majority of consumers would prefer to utilize an existing identity from a recognized provider rather than create their own myOpenID account. As a result, our business focus changed to address this desire, and we introduced social login technology. While the technology is slightly different from where we were in 2006, I’m confident that we are still delivering on our initial promise – that people should take control of their online identity and are empowered to carry those identities with them as they navigate the web.

    For those of you who still actively use myOpenID, I can understand your disappointment to hear this news and apologize if this causes you any inconvenience. To reduce this inconvenience, we are delaying the end of life of the service until February 1, 2014 to give you time to begin using other identities on those sites where you use myOpenID today.

    Speaking on behalf of Janrain, I truly appreciate your past support of myOpenID.

  5. 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.

  6. 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.