Take a look at some of the older user interfaces to get a sense for how del.icio.us has evolved until now. Aside from the new look there are new features as well. The delicious dev team has supposedly completely rewritten the code base, to allow for a more scalable and spry tool.

New features:

Navigation: New simple CSS tabs with onclick drop down menus make is simple to find your tasty bookmarks. The navigation structures seems to borrow from Flickr. Search also comes with a simple drop down option list to find stuff in your bookmarks, network or everyone.

Bookmarks: You have Title view, regular view and Full View options here. View your popular bookmarks to filter the good stuff and filter down more by choosing fresh only.

Sidebar: is updated to show a relative set of tags related to your left content pane.

Action Box: This light blue box in the sidebar shows the common tasks for the given page.

Search URL: This is a reverse search for bookmarks and pulls in the ones with the given URL along with tags used for that URL by each user, broken down in chronological order. You can also view the notes added by each user to the given URL.

Settings: The settings page is laid out with all the actions listed on one page, similar to a sitemap.

Forums: There is a support forum that looks more like a categorized list of links than a forum. I like the non-cluttered design. Reminds me of Drupal.

As in the past their API is still available for developer consumption.

margin-top | margin-bottom: max( marginbox 1 ... marginbox n)

When it comes to the real world there are 3 major categories of margin collapsing. So let’s figure out how these 3 types of collapsing work and how to tame them.

1) Adjoining boxes of sibling elements:

The bottom margin of an in-flow block-level element is always adjoining to the top margin of its next in-flow block-level sibling, unless that sibling has clearance.

 <div>
  <div>content</div>
  <div>content</div>
 </div>

While margin collapsing is great for written text such as paragraphs and headings etc., it can get somewhat tricky if you’re trying to get pixel perfect spacing between your boxes, so there might come a time when you want to disable margin collapsing. Take a look at these examples that suggest ways of uncollapsing your margins.

So it seems the only way to break out of collapsing that works in both IE and FF is our second example by using floats and clear combined. You might have noticed the above 4 boxes themselves also have 20px margins which have collapsed to form 20px margins within our 3 adjoining sections in the middle.

2) Adjoining boxes of ancestor elements:

The top or bottom margins of contained elements will always collapse together to form one margin. If the element’s margins are collapsed with its parent’s top margin, the top border edge of the box is defined to be the same as the parent’s. Below is the sample HTML and diagram and explanation of how to avoid this.

 <div>
  <div>content</div>
 </div>

Remember that collapsing only happens if the margins actually touch one another. In this case the inner box’s margin ends where the outer box’s margin starts, therefore they are touching. One easy way to avoid this type of margin collapsing is to add either vertical borders or vertical padding to the parent box. Take a look at these examples:

3) Self collapsing boxes:

Empty block level elements result in a special case of margin collapsing. Their top and bottom margins actually touch each other and they basically self destruct based on the rules of margin collapsing. According to the W3C: An element’s own margins are adjoining if the ‘min-height’ property is zero, and it has neither top or bottom borders nor top or bottom padding, and it has a ‘height’ of either 0 or ‘auto’, and it does not contain a line box, and all of its in-flow children’s margins (if any) are adjoining.

 <div>
  <div>content</div>
  <div></div>
  <div>content</div>
 </div>

Another obvious way to break out of collapsing is changing the display to absolute. Finally, note that the margins of the root element box in any document never collapse. There are a few rules for negative margins when it comes to collapsing. I will try to write another post on this later.

I’ve created a demo page here with the above examples.

References and Acknowledgments

W3C Box Model Collapsing Margins,
Andy Budd No margin for error,
Research Kitchen CSS Autoheight and Margin Collapsing,
Complex Spiral Uncollapsing-margins,
La Chatte Noire tests: block formatting context, display:inline-block and margin collapsing

Web Inspector Overview

To get started open Web Inspector by going to Safari 3.1/Develop/Show Web Inspector and you will see the new window open up. The initial window is split up into a top row with navigation buttons and search box. The navigation buttons take you the the next and last actions you make within Web Inspector and come in handy when debugging. The left navigation lets you view and inspect the loaded web resources including Documents, StyleSheets, Images, Scripts, WebFonts, Databases and Other files, as well as buttons to load the Console and Network details. Ajax request and responses show up under the Other file category. If any errors are found, the number of errors are placed on the file name in the navigator. For example here, Safari has found 1 bug in the file diggthis.js The main content area shows you the web source details for viewing. JavaScript errors are marked with an orange pop, while HTML and CSS errors have a red color. If you want to attach Web Inspector to the bottom of your Safari Window click the small box on the bottom left corner of the window. I found this this to be a more usable placement.

DOM Editing

Clicking on any HTML Document on the left loads the source on the right. Documents can also be viewed as a DOM resrouce by clicking ont he DOM button on the top nav. (Note you have flip between DOM and Source view for HTML files.)

Searching supports DOM and CSS elements and you can nest your DOM element searches to filter out exactly what you’re looking for. For example #page a returns all anchor tags in the div with the page id. The corresponding display element in Safari is highlighted as you select DOM elements.

The right pane displays Styles, Metrics and Properties for seleted DOM elements. Styles show you both the computed style as well as all the defined style rules for that object. Like FireBug you can edit your CSS rules in real time in the Styles boxes for each CSS rule. To edit any CSS property double click the name or value and an edit box opens allowing you to type in your changes. This is great for testing out new ideas on the fly.

The metrics pane shows you the layout rules including offset, margin, border, padding, width and height for the element. Finally the Properties pane lists all of the DOM object properties that apply to the selected element.

Downloadable Web Fonts

If you are using downloadable web fonts the Fonts file group shows you a rendering of all the fonts that are loaded into the user’s browser.

Client Side Databases

Also if you are using the client side database features of HTML5, the Databases category will let your explore the databases loaded in the client along with the all the tables and rows in each client side database. From here you can also execute SQL queries against the databases.

The Console

The console feature lets you type in JavaScript commands and view JavaScript errors, along with HTML and CSS rule errors. Clicking on any error jumps to the file, but unfortunately doesn’t go the corresponding line. The console has an input area for testing out JavaScript and DOM commands on the bottom. There is in fact a console object and my tests showed that Safari supports only a few of the functions for the console object. Here is a list of the FireBug console methods of which only a few are supported in Safari namely log, info, warn and error.

Supported methods:
log info warn error
Unsupported methods:
debug assert dir dirxml trace group groupEnd time timeEnd profile profileEnd count

Network

The network tab is actually quite nicely designed and show you what the transfer time or the transfer size for each resource and in total for the page. The capsule graph is color coded and breaks down the file types by Docs, CSS, Images, Script and Other. You can switch between time or size from the drop down. Web Inspector makes some suggestions as well for improving speed, for example here we see a recommendation to use file compression to save bandwidth. (I don’t really use this method now since IE6 is buggy with gzip deflation.) Click on any file to see the HTTP request and response header for that file.

Snippet Editor

The Snippet Editor is a little utility that allows you to enter blocks of HTML and CSS and have it rendered on the fly. It is quite useful for testing out your CSS and Layout in little chunks.

Note: While using the Web Inspector and Snippet Editor, I came across numerous little annoying bugs and usability issues here and there. Also lots of features that I would expect are not there. For example you can not click on elements to inspect them, you can not add new style rules if they don’t exist already, and you can’t edit rules for CSS files loaded using @import. I would have to say that FireBug is a superior tool at this time for professional debugging, but Safari is about half way there.

Developer Menu

The first thing you will notice is the addition of the “Develop” menu (Preferences/Advanced/Show Develop menu in menu bar) item with the following tasks:

Open Page with: (Other browsers installed on your system including FireFox, Internet Explorer, Opera)

User Agent: Set you user agent from the list of options, or enter your own user-agent. Finally! This was previously part of the hidden debug menu and you had no way of specifying a custom user-agent. The other exciting additions here are the ability to set your user-agent as Mobile Safari 1.1.3 for either iPhone or the iPod touch.

You can also pull up the Web Inspector, Error console, Network Timeline and a Snippet Editor. Lastly the Developer menu allows you to disable various browser features such as Caches, Images, CSS Styles, JavaScript, Runaway JavaScript Timers, and Site-Specific Hacks. You can now also edit CSS in the Web Inspector. More on these in a later post.

Standards Support

Support for CSS 3 web fonts using CSS @font-face rules. check out what can be done with downloadable fonts in these working samples here, here, here, here, here, and here. The CSS and a sample web font are show below. If you are using Safari 3.1 you should see a cool font.

@font-face {
  font-family: "Acorn Initials";
  src: url(http://www.domain.com/Acorn___.ttf) format("truetype");
}

Safari 3.1

Support for CSS transforms and transitions. Below are some demos of these.

Here is a sample of the -webkit transform CSS which is now supported by Safari 3.1. Click on the Safari logo to rotate it 1440 degrees.

The following Safari logo is skewed 35 degrees using -webkit-transform: skew(45deg, 0deg).

The following image changes its scale using -webkit transform:scale() to zoom in 30% when you mouse over it.

Support for HTML 5 <video> and <audio> elements. Watch out Adobe and Flash. Here is a demo of the video tag. There is also added support for SVG images in <img> elements and CSS images and SVG advanced text.

Support for offline storage for Web applications in SQL databases. That means you can now store your databases locally on the client’s machine. Here’s some sample JavaScript to do the client side databases. Check out this demo that shows you how it works.

database.executeSql("SELECT * FROM test", function(result1) {
   // do something with the results
   database.executeSql("DROP TABLE test", function(result2) {
     // do some more stuff
     alert("My second database query finished executing!");
   });
});

 
Running the CSS3 Selector tests reveals that Safari 3.1 has full support for CSS3 Selectors while FireFox 2 and IE 7 are still playing catch up.

Performance Improvements

Apple claims that Safari 3.1 “executes JavaScript up to 6 times faster than Internet Explorer 7 and up to 4 times faster than Firefox 2″. Performance measured in seconds. Testing conducted by Apple in March 2008 on a 2.4GHz Intel Core 2 Duo-based iMac system running Windows XP Professional SP2, configured with 1GB of RAM and an ATI Radeon HD 2600 with 256MB of VRAM. HTML and JavaScript benchmarks based on VeriTest’s iBench Version 5.0 using default settings. Testing conducted with a beta version of Safari; all other browsers were shipping versions. Performance will vary based on system configuration, network connection, and other factors.” I tested IE7, FF2, and Safari 3.1 with 3 JavaScript performance testers and the Acid 3 test kit. The tools used are
1. Acid3 tests.
2. JavaScript speed test written by Jason Orendorff
3. SunSpider test kit from WebKit.org
4. slickspeed test from Mootools.net

Here are the results in milliseconds from the tests which seem to agree with the results found by Apple. You can see that Safari 3.1 does in fact have a much more efficient JavaScript processing engine, and is three quarters of the way there when comes to passing the Acid3 tests.

Detail links at SunSpider:   IE7     FireFox 2.2     Safari 3.1

Microsoft Windows

• Improves Back/Forward performance
• Supports signed Java applets
• Shows Caps Lock icon in password fields
• Adds support for showModalDialog
• Localized in 16 languages
• Adds support for International Domain Names
• Improves handling of Japanese, Chinese, and Korean text
• Contextual menu now allows opening a link in a window or tab
• Improves pop-up blocking to work with plug-ins

Other Improvement

• Double clicking on the Tab Bar opens new tab
• Includes URL metadata when images are dragged or saved from browser
• Opens Download and Activity window in current Space
• Supports trackpad gestures for back, forward, and magnify on MacBook Air and compatible MacBook Pro computers
• Shows Caps Lock icon in password fields
• 13 Security Fixes
• Increased site compatibility
• Improved application stability

Example

Here is a sample image we want to clip:

The CSS and HTML look like this:

<div class="clipwrapper">
    <div class="clip">
     <img src="castle.jpg" />
    </div>
</div>

.clipwrapper{
  position:relative;
  height:225px;
}
.clip{
  position:absolute;
  clip:rect(50px 218px 155px 82px);
}

NOTE: The W3C recommendation suggests using commas between the coordinates, however this is broken in Internet Explorer. Strangely using the commas in IE does not work when in standards-compliant mode, but it does work when in quirks mode. To alleviate this issue I am not using commas which seems to work in all browsers including FireFox.

and the result looks like this:

Our class (.clip) sets the clipping region using the TRBL rotation syntax. I’m using pixels lengths but you can also try other lengths or percentages here and they can be positive or negative. You can also use auto, which would skip clipping that specific edge. You can also try nested clips.

The other important thing to note is that the clipping class position must be set to absolute for the clip property to work. Here, I have used a relatively positioned wrapper div to keep our image where we want. Also specifying the height of the container div keeps the next line from overlapping with the clipped areas.

Removing the clipped areas

Keep in mind that the size of the clipped image doesn not change, but you may want to get rid of the clipped off areas. This is easy to do using the top and left offsets. First we have to set the width and height of the container div to the size of the clipped image. Now we just add negative offsets to the top and left of the clipped div to match the top and left settings in the clipping class. So now our new classes are like this:

.clipout{
  position:relative;
  width:136px;
  height:105px;
}
.clipin{
  position:absolute;
  clip:rect(50px 218px 155px 82px);
  top:-50px;
  left:-82px;
}

and the result look like this:

Add Some Drop Shadow

Finally to add some drop shadow to the clipped thumbnail I am using three wrapper divs with negative offsets of slightly varying background colors to create a shade effect. So our final HTML and CSS look like this:

<div class="shade1"><div class="shade2"><div class="shade3">
   <div class="clipout">
    <div class="clipin">
     <img src="castle.jpg" />
    </div>
   </div>
</div></div></div>

.clipout{
  position:relative;
  width:136px;
  height:105px;
  top:-1px;
  left:-1px;
}
.clipin{
  position:absolute;
  clip:rect(50px 218px 155px 82px);
  top:-50px;
  left:-82px;
}
.shade1{
  width:136px;
  height:105px;
  background-color:#e8e8e8;
}
.shade2{
  position:relative;
  width:136px;
  height:105px;
  background-color:#cbcbcb;
  top:-2px;
  left:-2px;
}
.shade3{
  position:relative;
  width:136px;
  height:105px;
  background-color:#a0a0a0;
  top:-1px;
  left:-1px;
}

and here is the result:

The CSS3 working draft includes a crop property which is very similar to the clip property but would also crop off the area we have removed, so that the original object is actually replaced with the cropped section. As far as I can see no browsers have implemented this property as of now.

1) Validate your code

Although JavaScript can be very forgiving when it comes to error handling, sloppy coding will come back to haunt you in the long run. So the first step is to validate your code. I use JSLint which scans JavaScript code for syntax errors and common mistakes and recommends fixes. JSLint piggy backs on Rhino which is an implementation of JavaScript written in Java from Mozilla. You can either use the online version or download and run the scanner locally. I prefer this local method which utilizes the java runtime.

To use JSLint locally:

1. Download and unzip Rhino to a folder on your computer. You need js.jar
2. Download and save the JSLint library file jslint.js
3. Run JSLint in the Rhino Shell passing it a JavaScript file to scan. Here is the command I use assuming js.jar, jslint.js, and MYBIG.js are all in the same directory.

java -classpath js.jar 
org.mozilla.javascript.tools.shell.Main 
jslint.js MYBIG.js

You will then see a list of errors found by JSLint and suggestions for fixing your code. Some of the most common items are:

• Missing end of line semi-colon delimiters ;
• Not using dot notation to reference DOM objects (ex. form['name'].input.value instead of form.name.input.value )
• Using == instead of === for comparing with null, undefined, booleans, zero and “”
• Variable scope issues caused by declaring variables inside of loops instead of declaring them first in functions definitions.
• Not using curly braces in your conditional blocks. So make a point to always do If(x){doX();}else{doY();} even if you have one liners.
• Stay away from using eval() or with(). eval is evil
• Create your arrays using literal notation [] instead of new Array()
• Create your objects using {} instead of new Object()
• Avoid using javascript:function() in URLs
• You can read more suggestions in the JSLint docs.

2) Join your files

If you have five separate CSS files and three different JavaScript files, your server has to answer 8 HTTP requests per client. Each request requires additional processing and slows down your page loading. By concatenating your CSS and JavaScript files to only 2, you should see page load time improvements, especially when client requests are coming from distant networks.

Another tip that I have seen is to move your JavaScript include tags to the very bottom of the page, right before the </body> tag. This will allow the browser to draw the DOM before loading your library files and the page will appear to load faster.

So after your various source files are nice and lint free, and combined into a single library file you are ready to start shrinking.

3) Shrink your library

Before shipping your code, shrink it. JavaScript and CSS files are not compiled and they contain lots of wasted whitespace which are nice to have when you’re coding but serve no benefit to the user of your website. There are four different tools you can use to filter out the unnecessary bits from your JavaScript and CSS files, and for the most part they are doing the same thing. I personally use ShrinkSafe which is a happy safe medium. The reason is that this tool does not mangle your code so that its API will stay in tact. If you choose to use a decryption based method to obfuscate your code, it can have harmful side effects. First, the size of the encrypted file can in some cases actually be larger than the original! Second, your scripted API can get mangled, forcing you to update all external pointers to your code. If you have any clients who use your API via JavaScript, you should obviously take great caution in using encryption methods.

Caution: As always, backup your code before making changes to them using these tools! There is no undo!

JavaScript Shrinking

1. JSMin removes extra white-space and comments. It also reduces the line count by increasing the maximum line width. The result a bit uglier and harder to read and debug but also a bit smaller. Unlike ShrinkSafe, though JSMin does not edit your function arguments. You can download it in a variety of flavors. Here is a DOS executable version and the command to run it.

   jsmin <big.jsb >min_jsmin.js "(c)2007 CORP"

2. ShrinkSafe removes extra white-space and comments, but keeps one statement per line which is easy on the eye if you decide to edit your shrunk file. It also shrinks function arguments by replacing them with consecutive _## values which tends to reduce the files size some more. Download the jar file here and run it as follows:

   java -jar custom_rhino.jar -c big.js > 
   min_shrinksafe.js 2>&1

3. Packer has a few options you can choose to minify your scripts. The normal option removes extra white-space and puts the entire file in one super long line. You can also choose to shrink function as well as encode your script using a base62 algorithm. You can try it online. Although your file size is considerably smaller, depending on the complexity and cleanliness of your code (see JSLint above) using the two options in Packer might introduce errors with your code. In my case I had no problems with them.
4. MemTronic – Hardcore shrinkers out there can try this online tool which produces the smallest file size in my tests. Be warned that this is only for the braveheart coders, has some known issues and may have some side effects.

I have run Prototype.js against these 4 tools and the results are shown below. The results show that you can save at least 20% on your file size without compromising much stability.

CSS Shrinking

1. Clean CSS – This tool creates the best results, reducing the files size while maintaining a nicely formatted and readable CSS file. It has a plethora of options to choose from as well. For example, you can sort the properties of all the selectors which is a godsend for neat-freaks like me. It will also compress your css by converting possible properties to use shorthand notations. You can choose to save your comments.
2. CSS Optimiser – This tool only has one option which is to remove line breaks or not. Does a good job however the final file size does not decrease much if you don’t pick that option, which makes the css tough to read.
3. Icey CSS Compressor – Here is another powerful tool with lots of options to go around. Here are a few of them: Convert colors to hex, combine identical rules, combine properties, combine selectors, remove useless padding and margin. It also outputs in a nice colorful format for you. However there is no option to keep line breaks in tact so you get the output all in one line, and in my case this actually created an error.
4. Flumpcakes Optimiser – This tool has a few useful options such as combining backgrounds, fonts, lists, borders, and style which appear in multiple places. It can also convert RGB to hex and absolute to relative.

I ran the CSS from EarthLink ReaDeR through the top four tools and the results are shown below.

4) Compress your files

The HTTP implementation covers accept-encoding and content-encoding in detail and most browsers today support these methods. Basically when a browser sends a request, it tells the server it would like to have the file back in a compressed format such as gzip or deflate. The server then compresses the file and sends it back, and the browser decompresses the file and renders it in the browser. The most common format used today is GZip. Here is how to setup GZip in two popular web servers.

1. Apache & mod_gzip – If you are running on Apache and have already compiled it with mod_gzip you can easily configure gzip compression by adding these lines to an .htaccess file placed in your web root or your http.conf file.

   mod_gzip_on Yes
   mod_gzip_item_include file \.php$
   mod_gzip_item_include file \.html$
   mod_gzip_item_include mime ^text/html$
   mod_gzip_item_include file \.txt$
   mod_gzip_item_include mime ^text/plain$
   mod_gzip_item_include file \.css$
   mod_gzip_item_include mime ^text/css$
   mod_gzip_item_include file \.js$
   mod_gzip_item_include mime ^application/x-javascript$
   mod_gzip_item_exclude mime ^image/

   If you don’t have access to your .htaccess file but do have php compiled with the zlib module you can rename your javascript files to .php extensions and add this to the top of your file.

   <?php ob_start("ob_gzhandler");
   header("Content-type: text/javascript;charset:UTF-8");
   header("Cache-Control: must-revalidate");
   $offset = 60 * 60 * 24 * 365; // one year
   $ExpStr = "Expires: " .
   gmdate("D, d M Y H:i:s",
   time() + $offset) . " GMT"
   header($ExpStr);
   ?>

2. JBoss and Tomcat – To enable compression in a J2EE environment running Tomcat within JBoss, you can now enable compression by editing your server.xml that sits in the tomcat.sar folder. Just add these attributes to the Connector node:

   <connector port="8080" compression="on" 
   compressionMinSize="300"
   noCompressionUserAgents="gozilla, traviata"
   compressableMimeType="text/html,text/xml,text/css,
   text/javascript, application/x-javascript,
   application/javascript" />

The Results

Finally, here are two pages that use the compressed versions of prototype.js and reader.css, one with gzip compression enabled, and the other without gzip compression enabled. Using the Net tab in FireBug we can easily see that the gzipped version of both the CSS and JavaScript files actually result in less network traffic and faster loads times.

We cut our total throughput by 44 KB or 70%! Also the total load time is cut by 521ms or 51%, basically reduced from 1 second to half a second. If we do some quick math, for a website that gets 1,000,000 unique visitors per day, this is a daily savings of 44GB of bandwidth, and a total of about 145 precious hours saved.

Size in KB	CSS	JavaScript	Total
No Compression	12KB	51KB	63KB
Gzipped	4KB	15KB	19KB
Reduction	8KB 67%	36KB 71%	44KB 70%
Savings for 1 mil uniques/day			44 GB

Time in Milliseconds	CSS	JavaScript	Total
No Compression	281ms	741ms	1022ms
Gzipped	110	391	501ms
Reduction	171ms 61%	350ms 47%	521ms 51%
Savings for 1 mil uniques/day			145 Hrs.

So, I decided to do a quick FONT tag shorthand lab and find out once and for all what we need to do to get this thing working properly. Below are 10 sample runs which have the porperties for the font tag applied in various orders.

.f1{font: italic small-caps bold 14pt/1 arial;}

.f2{font: arial italic small-caps bold 14pt/1;}

.f3{font: 14pt/1 arial italic small-caps bold;}

.f4{font: bold 14pt/1 arial italic small-caps;}

.f5{font: italic 14pt/1 small-caps bold arial;}

.f6{font: italic bold 14pt/1 small-caps arial;}

.f7{font: normal normal normal 14pt/1 arial;}

.f8{font: 14pt/1 arial;}

.f9{font: 14pt/1;}

.f10{font: arial;}

Lessons Learned:

• Order of the properties matters.
• The correct order is font:font-style | font-variant | font-weight | font-size | line-height | font-family
• All modern browsers fully support CSS shorthand.
• Both the font-size and the font-family are required.
• The font-family must always be at the very end.
• The font-size must come before the font-family.
• The font-style, font-variant or font-weight commands are optional and will be defaulted to the value “normal” if left out.

Here is a CSS Font Shorthand Style Guide.