Monday, March 22nd, 2010

Safari self replicates itself…. for fun

Category: Apple, Fun

Inspired by the CSS Opera Logo (that works in a few browsers if you fix the -vendor-* CSS-ness) we now have Safari in Safari.


Being a web developer who works on a Mac, I’ve noticed that Apple’s implementation of CSS3 to Webkit and Safari always felt like they were extending OS X GUI elements to the web, even going so far as to make the iTunes store mostly out of Webkit. With that in mind and being inspired by David DeSandro’s Opera Logo made in CSS, I decided to take on Safari itself. I did so with the following in mind:

  • Only CSS
  • No images
  • No JavaScript
  • No Canvas

With those limits there of course were some features of Safari’s default state that didn’t make the cut for now — most obviously the tabs and various icons. I also didn’t take any steps to make this experiment work in any other browser (it does work in Chrome for Mac however). Eventually I’d like to perform the same experiment with Firefox 3.6, and perhaps others down the road if CSS3 advancements become available.

Watch on GitHub and you will see him work on Mobile Safari next :)

Posted by Dion Almaer at 8:22 am

3.2 rating from 28 votes


Comments feed TrackBack URI

Who needs television? I experimented with some of the demos in IE9 published on MIX10, and visited some other sites this weekend. The list of amazing proof of concepts made HTML 5, CSS 3 & Co. grows day by day, and you made my. Thanks for this.

Comment by springfeld — March 22, 2010

If browser makers want to prove the power of HTML5, writing their browsers using it is an excellent test!

When I tried doing this with Firefox earlier this year, I came up with the following problems:

* Cross-domain restrictions prevent the chrome from knowing about the content. For example, I couldn’t implement the Awesomebar because the chrome couldn’t keep track of the page history, or page zoom because the chrome didn’t have permissions to edit content css
* Tabs all run in the same process, creating potential security and performance issues.
* Some chrome menus e.g. network connection settings can’t be managed using javascript APIs

This leads to an interesting laundry list of potential browser enhancements (for example iFrames could be rendered in a separate process) to make all this possible.

Despite these problems I bet browsers will run this way in future. The advantages in distribution (no downloads required, just access from any machine to use your personalised layout) alone are massive, let alone possibilities opened up for collaboration.

Comment by chrisfjay — March 22, 2010

Chris, I hate to say it, but oni is right: Firefox is already there, offering all the opportunities you describe and reimplementing it seems like a waste of time for various reasons. But at the very least, you should familiarize yourself with XPCOM, because if you’re aiming to provide the same functionality as the XUL frontend via a HTML frontend (again, the value of this is questionable as XUL is mainly a different notation and a different box and alignment model, but with the same logic, namely DOM+CSS+JS) you will have to talk to the native APIs. You also need to understand Firefox security model, namely that privileged code needs chrome access.

BTW, Firefox runs everything in one process anyway.

Comment by hansschmucker — March 23, 2010

Leave a comment

You must be logged in to post a comment.