Tag Archives: webkit

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;
  }
</style>
<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
      h1.setAttribute('style',
          'top:' + ( h1.offsetWidth - h1.offsetHeight) + 'px');
      // and rotate
      h1.setAttribute('class', 'rotated');
    }
</script>

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.

Mozilla and WebKit, browser platform wars.

This post began as a comment on Matthew Gertner’s blog post The Browser Platform Wars. It’s a rant not an article, don’t take it personally.

In my experience (8 years building Mozilla based products and playing with WebKit since it was first released as WebCore in 2003) there are a few clear technical and social differences that can make WebKit a more attractive platform for developers than Mozilla. There are plenty of reasons that Firefox is a better product than Safari (I definitely prefer Firefox over Safari on my Mac), but that’s a different story.

The scale and complexity of the Mozilla codebase is daunting. Mozilla advocates will say that that’s because Mozilla provides more functionality, but the reality is that even if you don’t want all that functionality you still have to dig through and around it to get your work done. Much of the Mozilla platform is poorly documented, poorly understood and incomplete (the C++/JS binding security stuff was the most recent example I’ve looked at) while WebKit is smaller, simpler and newer. They use common c++ idioms instead of proprietary systems like XPCOM.

The scale of the Mozilla organization is also daunting. Mozilla’s web presence is vast and is filled with inaccurate, outdated content. Their goals are vague and mostly irrelevant to developers. By contrast WebKit’s web site is simple and straight-forward. Its audience is developers, it sets out goals that matter and make sense to developers, it explains clearly the process for participating and contributing in the project.

WebKit is designed for embedding. Within Apple there are several customers for the WebKit library – Desktop Safari, iPhone Safari, Dashboard, AppKit and more. Since WebKit already serves a variety of purposes it’s likely to work for other applications which third party developers will want to build. By comparison the Mozilla platform really only has one first-class customer – Firefox.

The WebKit community has welcomed non-employee contributors. They’ve even welcomed contributors who work for Apple’s competitors. There are WebKit reviewers from Google, Nokia and the open source community. By comparison, Songbird and Flock don’t have any Mozilla committers or reviewers who weren’t previously Mozilla Corporation employees even though they are two of the largest non-MoCo platform customers.

Perhaps I’m short-sighted, but I don’t see a clear path forward for Mozilla in competing with WebKit as a platform for web content display. The long history of Mozilla have left them with a large, complicated codebase that’s not getting smaller. The rapid growth and defensive attitude of the organization (probably brought on by the Netscape / IE wars) has left it without a culture that welcomes friendly competition. I think that Mozilla’s focus on the product above the platform is the right decision for them. I’m just glad we have an alternative web content platform.