InternetSyndicate content

Living with Opera 10 alpha, leaving Opera 10 alpha

by Adrian 17th Jun, 2009 @ 22:54
In “Why in the world would one not use Opera 10?” Joe Clark lists three reasons why he won’t be using it, and I can’t resist adding some of my own.I’ve tried so hard to like Opera over the years: I spent time tweaking the UI so I could avoid tabs on top[1] and I’ve tried out several Opera themes in the hope they’d make it less ugly.Recently despite being disappointed by Jon Hicks ‘lipstick on a pig’ redesign of the Opera UI[2] but prompted by Opera 10 alpha’s speed, I tried it as my main browser for a week. It’s fast – but speed alone is not enough.My main frustrations derive from the lack of a plug-in/add-on feature, I’ve grown used to easy login via 1Password, tidy downloads via Speed Download and easy access to delicious for bookmarks. These all work in the other browsers I use on OSX, but not Opera, because it has no support for third party integration at all.Opera is in something of a tricky position, it has a core of users it doesn’t want to annoy by say, completely redesigning the UI, but it can’t attract large numbers of new users without doing so. It also seems somewhat distracted as a company, apparently prioritizing projects like Opera Unite over a plugin system for the browser.There’s hope yet. Opera 10 alpha’s ‘presto’ rendering engine is fast and has good support for web standards. If they can do better with the UI[3] and add support for 3rd party plugins they might just make me an Opera user yet. In the mean time Opera has once again been removed from my dock and put in the ‘open only for site testing’ folder.Opera 10 alpha: great rendering engine, poor browser.
  1. Though since using Google Chrome I’ve grown to like tabs on top, done right.
  2. It is much better, but it needs a complete reworking, not incremental improvements.
  3. Surely they’re not going to limit Jon Hicks to polishing? It’s like hiring Michelangelo and asking “just give it a lick of paint would you? Nothing fancy, maybe white or magnolia.”

Typekit: another half-arsed attempt at getting a wide range of fonts on the web?

by Adrian 29th May, 2009 @ 10:34
Web design guru Jeffrey Veen has just announced Typekit, a Javascript based technique for embedding fonts in web pages backed up with a licensing and hosting platform that will apparently keep type foundries happy. Judging from the comments a lot of designers are pretty damn excited, drowning out the few dissenters questioning the technical approach.Typekit remains vapourware for the moment, but the fact that it’s based on Javascript is not a good omen. Systems like sIFR and Cufon can cause problems for screen readers and even break basic copy/paste of text. It’s hard to see Typekit doing much better – at the very least Typekit will fail for users with Javascript turned off, and will likely suffer occasional namespace issues with other scripts embedded in a page with the result of much cursing and hair pulling by web developers.All of these technical approaches to embedding fonts – sIFR, Cufon, Typekit – are very clever but complicated and inelegant. And inelegant solutions frequently break. We already have a simple and solid solution to font embedding for the web: @font-face property of CSS2. What’s been lacking is browser support, however sometime this year Safari, Firefox, Opera and Chrome will all have support for @font-face leaving the usual laggard, Internet Explorer, as the only exception. When Microsoft manage to add @font-face to IE the technical side is solved.But Typekit isn’t about the mere embedding of a font in a web page, it’s about licensing. The type industry lags even the music industry in its adaption to a world where the internet exists. Despite the huge demand from web developer/designers only a few foundries have taken the plunge (listed on the webfonts wiki) and developed a proper font license for the web. The rest steadfastly refuse to enter this market, instead they seem intent on yet more complicated technical solutions (see “Real fonts on the web” at ALA including discussion of permissions tables and new font formats) that amount to DRM for fonts.Such technical solutions will of course be circumvented and those that steal fonts will continue to find it just as easy as they do now (google for “fonts torrent” to see just how easy). It’s hard to see how @font-face will increase the problem of font piracy even a little. The major type foundries need to get there collective control freak knickers untwisted and realize that:
  1. @font-face embedding isn’t going to increase font piracy by any significant amount.
  2. Complicated technical DRM solutions will cause problems for web developers and be rapidly circumvented anyway.
  3. There is a huge pent up demand for proper licensing of fonts for the web which they are failing to make money on now.
Web developers and designers want to see two things happening right now, firstly Microsoft needs to announce that @font-face will be supported in IE sooner rather than later, and secondly all major type foundries need to draw up proper licenses for the web. It’s that simple.I suspect Typkit will be moderately successful in the short term but wither when a large font foundry finally realizes it can make more money licensing the fonts for web use properly. It will be sad if Typekit delays the inevitable day when font foundries wake up to the fact that they have everything to gain and nothing to lose by supporting @font-face.