Tag Archives: chrome

Detecting advanced CSS features

I decided to do some fancy typography in my résumé, but I wanted to have a sane fallback for browsers that don’t support the latest features. I have my name rotated 90 degrees using CSS3 transforms, but simply applying the transform: rotate(-90deg) CSS property isn’t enough to get the effect I want. To make it look right I also need to measure the text (since its dimensions will change depending on the viewer’s fonts) and absolutely position it based on that. Standard CSS fallback (where unrecognized rules are ignored) doesn’t give a good result. At all.

After a bunch of fiddling and cross-browser testing I found that testing the existence (!==undefined) of properties on element.style worked well. So I put all of my rotation rules in a CSS class that’s applied only if the style properties exist.

<style type="text/css">
  h1.rotated {
    -webkit-transform-origin: left bottom;
    -moz-transform-origin: left bottom;
    -o-transform-origin: left bottom;
    transform-origin: left bottom;

    -webkit-transform: rotate(-90deg);
    -moz-transform: rotate(-90deg);
    -o-transform: rotate(-90deg);
    transform: rotate(-90deg);

    position: absolute;
    left: 0px;
    top: 0px;
    margin-top: 16px;
<script type="text/javascript">
    // rotate the title, if that's even possible
    var h1 = document.getElementsByTagName('h1')[0];
    var s = document.body.style;

    // test for the presence of CSS3 transform properties
    if (s.transform !== undefined ||
        s.WebkitTransform !== undefined ||
        s.MozTransform !== undefined ||
        s.OTransform !== undefined) {
      // move
          'top:' + ( h1.offsetWidth - h1.offsetHeight) + 'px');
      // and rotate
      h1.setAttribute('class', 'rotated');

Of course, if I could just check for transform: support rather than -webkit-transform:, -moz-transform: and -o-transform: but we’re not there yet. Anyway, based on browsershots.org it seems to do the right thing on every known browser. It shows rotated text in very recent Webkit and Gecko browsers, and in Opera nightlies, and unrotated, correctly text everywhere else.

A brighter future for mobile applications?

Since the Chrome OS announcement the other day I’ve been thinking more about what a world with rich enough web APIs to support all general purpose applications might look like. I’m not sure that it’ll happen, but it sounds like Google is putting their weight behind it and they’ve been successful in the past at moving our industry in new directions (remember the world before GMail and Google Maps?).

A richer set of standard web APIs might form the basis for a cross-manufacturer mobile platform. The Palm WebOS stack already kind of looks like Chrome OS (though with local HTML+JS apps rather than remote ones) and the original iPhone application model was exactly what Chrome OS proposes. The limitations that forced Apple to create a native developer platform are exactly the ones that Chrome OS plans to address.

Of course Google’s own mobile platform is decidedly non-web and Apple’s much larger volume of applications discourage it from supporting standard APIs. The handset manufacturers, OS developers and carriers are all making a ton of money selling applications in a model that’s reminiscent of pre-web software models. The only real winners from a move to a web model for mobile applications would be the users.

Google Chrome OS

If I was building an OS today I’d be building what Google just announced.

Like most heavy technology users I’ve been moving heavily toward hosted web applications over the past few years. I don’t use Evolution or mutt anymore, I use GMail. I don’t organize my photos on my laptop and use my own hosted Gallery, I use Flickr. I’ve never been a big office application user, but when I’m forced to open a Powerpoint deck, edit an Excel file or print out a Word document, I do it using Google docs.

I’ve also spent the past four or five or so years working on blurring the line between what’s on your desktop and what’s online. At Flock I worked to synchronize your bookmarks to online services and between machines, to integrate personalized web search into your desktop workflow and to make publishing media from your devices as easy as publishing text from your keyboard. At Songbird we developed APIs to allow web apps to interact with your desktop media player and APIs to let your desktop media player access content from the web. At Rdio I worked on similar things, from a slightly different approach, I don’t think I can talk about them yet.

I’m really excited that Google has the balls (and the skills) to go all out. To commit to offering enough APIs to web applications to allow them to provide the same functionality and user experience as desktop applications would. This isn’t the first time that this has been attempted, but I think this time it just might work. Just a couple of years ago when the iPhone launched and Apple announced that the only way to write applications was to write web applications users and developers rebelled. The iPhone browser wasn’t capable enough. Google have taken the right approach by committing to improving the web platform to support whatever APIs are needed before shipping the product.

I’ll never be running Chrome OS. I rely on too many specialized applications, but I am looking forward to when Flickr can pull photos right off my camera and GMail’s offline features are widely tested enough to actually work right. Much of the innovation in Chrome OS will benefit us all.