For those of you who haven't entirely abandoned Facebook for the uprising Google+, you'll likely have noticed that Facebook has once again made a significant change to the Profile page. The Facebook Timeline is the product of Facebook's new focus on UI design. Love it or hate it, it's here to stay.
One of the most beloved changes has been the addition of a large "cover" photo to the profile page. Facebook tells us to: "Fill this wide, open space with a unique image that represents you best. It's the first thing people see when they visit your timeline." Indeed, the cover photo and the profile picture provide a great opportunity for one to show off their creativity. See "Facebook Timeline Cover: 40 creative examples" for some interesting cover hacks.
A simple Facebook cover photo hack is to use the profile picture as a transparent window into the cover photo. LifeHacker recently posted an article describing how to do exactly this with Photoshop or Gimp. Inspired by this post, I decided to make a simple HTML page to preview this kind of cover photo. Below you will find the source code to this test page:
To test out your cover photo, you would modify the img tag (.background img) to point to your large cover photo. The cover photo is 850x315px, but you'll need a larger image than that to show through to the profile picture. Using the Chrome Dev Tools, Firebug, or a similar CSS/DOM debugger you can adjust the dimensions and position of the cover image to your desired position.
Now you still would need to fire up your image editor to crop out your profile picture, which needs to be 180x180, and your cover photo which should be 850x315px. This will require keeping track of the offsets and the dimensions you've been testing with. It makes for a simple tool for seeing what kind of cool cover/profile combinations you can come up with. You can test out your profile picture by enabling the commented out profile img tag and seeing if it worked out the way you desired.
You could now, in theory, do some simple crops with your default system image editor and avoid using the heavyweight Gimp or Photoshop. However, I've found it to be tricky to get Facebook to do exactly what you'd expect with your uploaded photos. I had to do a few uploads of profile pictures before I got the satisfactory alignment which completed my Facebook cover photo hack.
It all began with a bug report complaining about the then dry and unvarnished FTP and file directory listing pages in Chrome [1]. The bug compared Chromium's vanilla listing pages to Firefox's respective pages; clearly Mozilla had put more effort into prettying up these pages.
One of the most significant shortcomings of this page was the lack of icons for files and folders. In fact, folders in Chromium's listing pages were only distinguishable from files by their trailing slash.
I decided to tackle this bug as I really like Firefox's presentation of these pages. Out of curiosity I took a look at the source code for Firefox's listing page and found out that they are using a custom URI scheme moz-icon to specify the icon images in the listing page HTML.
/**
* nsIIconURI
*
* This interface derives from nsIURI, to provide additional information
* about moz-icon URIs.
*
* What *is* a moz-icon URI you ask? Well, it has the following syntax:
*
* moz-icon://[ | | ]? ['?'[]]
*
* is a legal file: URI spec. You only need to specify a file: URI inside the icon
* if the file you want the icon for actually exists.
*
* is any filename with an extension, e.g. "dummy.html".
* If the file you want an icon for isn't known to exist, you can omit the file URI, and just
* place a dummy file name with the extension or content type you want: moz-icon://dummy.html.
*
* is of the format: stock/
*
* is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'.
* XXXcaa Should these considered platform dependent or can we share and document them?
*
* Legal parameter value pairs are listed below:
*
* Parameter: size
* Values: [ | button | toolbar | toolbarsmall | menu | dialog]
* Description: If integer, this is the desired size in square pixels of the icon
* Else, use the OS default for the specified keyword context.
*
* Parameter: state
* Values: [normal | disabled]
* Description: The state of the icon.
*
* Parameter: contentType
* Values:
* Description: The mime type we want an icon for. This is ignored by stock images.
*/
Interestingly enough, this scheme is web accessible --meaning that any web developer can use this scheme as the src for their Image objects in their HTML and JavaScript code. What's great about this scheme is that it allows developers to present platform specific icons to users. For example, <img src="moz-icon://.zip?size=16" /> would resolve the icon used by the operating system for the zip filetype.
Chromium also has a similar URI scheme for retrieving platform icons. If you look at the downloads DOM UI page, Chromium uses chrome://fileicon with a file path query to retrieve the icons for respective downloaded items. This scheme is not web accessible. The chrome:// URLs have special security privileges in Chromium that would prevent us from exposing the chrome://fileicon scheme in the manner of moz-icon. We could, of course, create a new similar scheme that would be web accessible for the use of developers and file listing pages alike.
Discussions in the Chromium-dev mailing list led to a suggestion that this "icon" URI scheme should become an open standard that every browser could implement. So I decided I would give this standardization business a shot.
The process for registering a URI scheme works as such:
Propose the scheme to the Public Webapps W3 mailing list [2] for feedback
Write a URI scheme registration template (usually contained in an Internet Draft) describing how the new scheme works. Internet Drafts must conform to the Guidelines for the Authors of Internet Drafts [3]. The registration template must conform to the Guidelines and Registration Procedures for New URI Schemes [4]
Send a copy of the template (or containing document) to the URI review mailing list [5] as well as any other relevant mailing list requesting a review
Once any review issues have been addressed, submit the document to IANA [6] specifying whether provisional or permanent registration is required.
If all goes well the URI will get registered and appear on the IANA registered URI schemes page [7]
Profit!
The entire process is structured and very iterative. Peer reviews are required to assure that the new scheme will be useful, that it is well specified and that all security risks are considered.
After this long and arduous process, I managed to get provisional registration for the Icon URI scheme [8]. W00t! You'll find it listed on the IANA URI Scheme page at least until December when it expires.
Well it's nice to have an Internet Draft for the Icon URI scheme but it would be nicer if we had an implementation of the scheme running in a modern browser.
So I wrote a prototype implementation [9] in Chromium to help move the scheme forward. Unfortunately, there were concerns that added potential security risks of this scheme outweigh the benefits. Security concerns were addressed in the draft, however it would be tricky to assure that this scheme could not be used to determine what applications a user has installed by some sort of user interaction attack. With Chromium being a security first type of browser, it would seem that the shiny new web accessible Icon URI scheme may not be the best fit. Sigh.
Well that was a whole lot of yak shaving! Didn't this start with a simple bug request for icons in file listing pages?
I plan to let the Icon URI scheme expire at the end of the year in light of Chromium not using it. It would have been a nice feature, but it was hardly a necessity. The original use case bug for this scheme can be resolved in other ways. I wrote a patch that adds icons to the Chromium file and FTP directory listing pages. There are 3 types of icons: file, folder and parent folder. The icons are hard coded as data URI into the HTML.
Figure 3: Current state of Chrome file listing page
So the Icon URI scheme was dead on arrival. The moral of this story is DON'T SHAVE YAKS!
