DuckDuckGo’s best two features are:

1. It has no features
2. It respects your online privacy

Well. It’s not true that it has no features. DuckDuckGo just focuses entirely on web search. It doesn’t litter the page with garbage-ey social features and doesn’t filter your search results based upon your past search history.

And sure they have lots of little goodies and widgets but mostly it’s just a nice clean search engine with no BS.

They include a ‘behind the scenes’ page where they discuss some of the technologies used. It’s fairly interesting but includes some dumb marketing language:

It was a daunting task: get this code into a browser while maintaining the unique personality and incredible quality that gamers are accustomed to. To accomplish this, we bet on JavaScript.

Safe bet. When I have to choose between JavaScript or JavaScript I also bet on JavaScript.

The Colorzilla gradient editor is a visual gradient editor like you might find in Photoshop or Pixelmator. Once you’ve specified your gradient, you see an HTML preview plus CSS style rules to create that gradient in modern browsers, and a reasonable approximation using IE’s filter syntax.

Click and draggy

A new checkbox toggles IE 9 support. Selecting this option includes a base64 encoded SVG background image along with the rest of the browser gradient definitions. In order for this to work properly it is necessary to include an IE9 specific style rule (in a conditional stylesheet) which disables the filter definition for legacy versions of IE. An example of this style rule is included in the application.

Click the box for IE 9 support

I have to confess that I’ve been using this tool in lieu of my own script. There are a few reasons.

Pros

Having the SVG definition pre-built and available right in-line removes dependencies on JavaScript and means there’s no extra HTC file to keep up with. Additionally, since there’s no scripting involved, there’s no possibility of collisions with your any scripting in your application.

If one wanted, one could just use the SVG definition and remove all the other gradient definitions (except of course the filter rule). Any browser which supports CSS3 gradients will support an SVG background image. This would let you clean out redundant, browser specific style rules in all your gradient styles.

This technique is reasonably future proof, as it uses standard HTML and a standard SVG. If IE 10 fails to support gradients, this technique will still work.

I have no idea if my HTC script will work on the new mobile IE on Windows Phone 7and (hypothetically) Windows 8. (If someone wants to give me a free Windows Phone, I’ll be happy to test.)

Cons

If you’re using CSS3 gradient definitions, it’s technically possible to tweak or edit them “by hand” without using a special tool. To make any changes to an encoded SVG image you’ll either have to decode, edit, and re-encode or you’ll have to create a new image from scratch. If you’re using a tool like the Colorzilla gradient editor, this isn’t a huge problem – but it’s still an extra step.

Since the SVG gradient is encoded inline in the main stylesheet, all browsers must download this image whether they use it or not. So in a way you’re punishing all users for IE 9’s sins. My dynamic solution targets IE 9 specifically.

It is possible that one day this tool will simply disappear. If that happens, then designers and developers might be scrambling for a replacement.

I recommend

I recommend using Colorzilla’s tool over my script for supporting IE 9 gradients. In practice, I find it’s simply far easier for me to just define a gradient and copy/paste the generated CSS into mine, and follow up with a little clean up once the design is settled.

I’m happy with my script, and there may be cases where it’s preferred (smaller download sizes, targeting only modern desktop browsers, etc) but I think the Pros of using Colorzilla’s tool outweigh the Cons.

Attention!

Mr. Stephen Fry helps out around the office by announcing to my colleagues which development environment is about to be updated.

Some time ago I wrote up a hacky way to work around an annoying IE9 bug.

The full write-up has the details, but in short, Internet Explorer 9 doesn’t play well with CSS3 border radius rules (for rounded corners on boxes) and IE’s proprietary gradient filter. The gradient pokes out from underneath the rounded corners. Unsightly.

Since IE9 has full support for SVGs, you can substitute an SVG for a gradient background on any arbitrarily sized HTML element.

Supporting both CSS3 gradients plus MS gradient filters and an extra SVG image plus supporting CSS is clunky at best. CSS hacks are best when they’re invisible.

With a little experimentation I learned one could extract the gradient details from MS’ gradient filter and build an SVG with those details. IE9 has robust support for data URIs in CSS, which means I could base64 encode the constructed SVG and use it as a background image.

Blammo.

What you have here is an HTC (HTML Component) which, on “contentready”, extracts gradient filter data, builds an SVG, base64 encodes that SVG, creates a stylesheet and style rule to hold that encoded data, and then applies the new background style to the element in question, and caches all this info so the next element with the same gradient definition just inherits the new style rule.

Screen capture of gradient bug and fix

Because each gradient is defined in a style rule, and then reused as needed, it’s pretty fast.

An example with many gradients.

Download the zipped HTC file and .htaccess file.

You can enable the filter in your IE9-targeted CSS in an HTML document like so:

<!--[if ie 9]>
	<style type="text/css" media="screen">
		.filter
		{
			behavior: url(ie9-gradient-fix.htc);
		}
	</style>
<![endif]-->

This HTC doesn’t sniff out the version of IE, so it should be included in a conditional stylesheet.

IE9 is more strict with HTCs than previous versions. You’ll need to make sure your web server is sending HTC files with the correct mime type, otherwise IE9 will ignore it. If you’re hosting on Apache, add the following to your .htaccess file or host configuration:

AddType text/x-component .htc

I’m pretty sure that Windows servers will take care of this automatically, but I don’t care.

Details

HTC files are basically a way to attach JavaScript event handlers to HTML elements via CSS selectors. In the following example, event handlers defined in behavior.htc are attached to all paragraph elements that are contained within a DIV element having the CSS class name “foo”.

div.foo p {behavior: url(behavior.htc);}

It’s like a primitive jQuery. Event handlers are defined and attached to elements at the beginning of the HTC document:

<PUBLIC:ATTACH EVENT="oncontentready" ONEVENT="myOnContentReadyHandler()" />

Later in the document a javascript function is defined with the same signature: myOnContentReadyHandler(). Within that function the JS keyword “this” refers to the element the event handler is attached to. So my example function could make all the <p> tags in a <div> with a class of “foo” disappear like so:

function myOnContentReadyHandler()
{
	this.style.display = "none";
}

The gradient fix theory of operation

Here’s how the IE9 gradient fix works:

1. Determine if the current element has both at least one rounded corner via CSS border-radius and a gradient filter applied. If so, continue.
2. Determine if the current filter gradient has already been processed and cached. If not, continue building the background SVG
3. Extract the starting color, ending color, and direction (horizontal or vertical) for the gradient from the filter css rule using the element’s currentStyle property
4. If the colors are using #AARRGGBB format (a proprietary form of RGBA color) – extract the alpha value and convert to a decimal value from 0 to 1 for use in the SVG.
5. Using the extracted colors, opacity, and gradient direction. Build an SVG graphic with a single gradient definition and a single rectangle filled with that gradient.
6. Base64 encode the SVG
7. Create a style rule with a unique classname selector defining a background image using the encoded SVG image in a data uri and removing the filter definition (e.g. removing the original gradient background).
8. Append the style rule to a dynamically created stylesheet.
9. Cache the class name of the new style rule in a globally accessible object using the filter rule definition as a key (this should be reasonably unique)
10. Apply the class name to the element.

In step #2, if the filter definition exists in the cache, we skip to step #10 and apply the cached class name to the element. This way gradients are only created once per page request and reused throughout the page.

Below are some gotchas or other considerations.

Assumptions/Conditions

1. HTC files only work when javascript is enabled.
2. Elements with filter gradients have no other MS filters.

Creating a stylesheet within an HTC

HTC files, once loaded by IE, have their own document namespace. If you want to build a stylesheet dynamically from within an HTC, you’ll need to reference the ‘window.document’ namespace.

window.document.createStyleSheet();

CSS is tricky

The SVG background is applied via a CSS classname – the CSS rule corresponding to that class name is added to a new stylesheet, which should appear last in the list of stylesheets for the document. The declaration which unsets the original filter background uses an !important rule. So the new background image styles should override any previously defined background styles. However, your CSS may not play nicely with this dynamically created style rule. If the gradient pokes through your nicely rounded corners, consult IE9’s dev tools and make sure that you don’t have a CSS rule that’s overriding the dynamic rule.

Base64

I didn’t write my own base64 encoding function. I’m no dummy. I used the JavaScript class provided by WebTookKit.info.

Facebook is scaring Dave Winer – Dave Winer writes about ‘frictionless  sharing’ – a feature of where sites who partner with Facebook can automatically post to your news feed (and therefore to your friends and creepy  subscribers)

Nik Cubrilovic does a little testing and notes that  you never really log out of Facebook – meaning that all the “like” buttons you see on other sites know who you are and what you’re looking at even if you’re not logged in. A person commenting on that article claims to be Facebook engineer; he claims that Facebook never uses this data for tracking, but this Wall Street Journal article contradicts that stating the data is used and then totally deleted. You can trust us.

After a couple of days, and a lot of noisy web traffic, Facebook works with Nik Cubrliovic to explain itself and it’s cookies and fixes a bug (which left your user id in an undeleted cookie)

If you can’t quit Facebook, because otherwise there’s no way to get Gramma’s cookie recipes, you should consider using a browser extension like Incognito which blocks all this cookie tracking nonsense.

http://kilianvalkhof.com/2010/css-xhtml/how-to-use-rgba-in-ie/

jQuery Mobile is an extension of the jQuery library, and similarly Ext JS components are based on the Ext Core library. Both core libraries do similar things. They normalize browser differences in event handling and XmlHttp request implementations; they add to or extend the core browser document object model; they provide a means to create custom events and subscribe to these events with handlers; and they provide an API to create custom components or plugins. They approach things slightly differently. jQuery focuses on a xpath/CSS selector based API for working with DOM elements. Ext has this feature too, but also creates some base classes to supplement javascript’s core objects. Ext1 also extends some of the core javascript objects (like String and Array) to provide additional functionality. Beyond this though, the libraries diverge.

Ext is component based. The goal of the library is to provide the developer with reusable application components that can be wired up with data access objects which, to a certain degree, simulate a database or an object store in javascript. The dataobjects are configured to communicate with your server application via XmlHttp request. This approach is also used by libraries like Sproutcore. Components include toolbars, forms, various navigational tools, panels, modals, dialogs, charts, etc. The components can be used independently on a given HTML page, but they are often brought together into a complete application that works much like a desktop application that lives in a browser. The default themes provided with Ext look very much like a Windows XP era desktop application.

jQuery has some ui components as well, but the scope is limited. jQuery UI basically extends HTML with a few extra niceties like date picking components, tabbed navigation, sliding selectors (imagine a volume control) and so on. These components aren’t really designed to be bolted together into an application. Instead they enhance an existing HTML interface. This underscores the differences in philosophy.

I think of jQuery’s approach as an enhanced, interactive document approach – where each web page is just that, a page of information. The page can be used (or at least read) without javascript enabled and, more importantly, be discovered and interpreted by search engines. Netflix.com is a good example of this pattern.

Ext embraces an application approach. The web page, the HTML document, is a host for a complete software application written in javascript2. The application doesn’t function (or even exist) if the browser doesn’t have javascript enabled. The application is effectively invisible to search engines. Gmail is a good example of this kind of application, so are Apple’s old Mobile Me applications (soon to be replaced with iCloud apps, I suppose).

These approaches can be combined. Google+ and Facebook have document centric “core” functionality like news feeds, but advanced features like “chat” and contact management are application-like modules that are welded onto the document base.

Combined or not though, I think these are the two ways of thinking about client side architecture of web applications. Each method has its tradeoffs.

The enhanced document approach

You get

• Search engine visibility, and likewise the possibility to support older browsers or javascript disabled or inhibited browsers
• Separation of concerns: The design and HTML/CSS implementation of that design can be largely, if not completely, separated from the interactivity
• Complete design control
• Shallow learning curve
• The ability to create a simple page/application first, then add features as they are discovered or needed.
• Lightweight JS and interaction model – for example a simple web page can be made highly interactive with a small amount of custom JS supported jQuery. The full Ext library is rather large.

You lose

• Enhanced interactivity. Powerful widgets like data grids and the like must either be manually integrated, built custom, or done without.
• Speed of prototyping and development. With a toolkit like Ext or Sproutcore, there’s probably already a widget that’s pretty close to what you need. The widget might be used as-is in a prototype, and extended for the real application.

The application approach

You get

• Speed of prototyping and development
• A reasonably good look and feel (if not UI design) “out of the box”
• Advanced features that resemble “real” desktop software (this can be very important in, say, a corporate setting)
• Easier division of server side and client side development. For example, an Ext developer can build an entire application powered by dummy JSON data, while the Java developer builds out a RESTful server application to support it. They only need to agree on the data api.

You lose

• Time due to high learning curve
• Design flexibility
• Integration of legacy or third party client side components may be difficult or impossible.
• Search engine visibility
• Libraries, components, and custom javascript tend to be large and complex with these sorts of applications
• Performance can be poor on slower machines

I imagine a seasoned jQuery developer reading this and thinking “but I just downloaded a data grid plugin for jQuery…”; there’s an Ext developer somewhere thinking “I just wrote my fifth custom Ext theme, it’s not that big of a deal…”. All true. These lists are just big executive level3 ways of thinking about the two approaches.

The next time I have to make a big decision about which approach to take with some new development, I’ll probably use this list (or a list like it) as my guide. The next time I have to convince a room full of wolves developers to take an approach, I’ll definitely make a big list on a big white board.

I’m working on a small personal project now in which I’m taking the enhanced document approach. This approach has allowed me to work pretty quickly by banging out the required features using standard HTTP type web application methods (forms, links, and redirects) while planning for more advanced features down the road. Also, because I’m forced somewhat to keep things simple, it’s allowing me to target desktop browsers and mobile browsers at more or less the same time (because I completely control the design) which is pretty cool too.

Twitter data feed borked the display of the site.

The other day Twitter went ‘bonk’ – which hey, stuff happens – but because the site has no non-javascript fallback it went boom.

Be careful out there, kids.

I pulled an old trick out of my hat that I thought would be worth sharing.

Internet Exploer 7, and 8 do not support the nth-child pseudo element selector, but they do support the adjacent sibling selector. This means you can fake a basic nth-child selector for IE with the following:

/* standard nth */
ul.menu li:nth-child(3)
{
    /* styles for the 3rd LI */
}

/* IE nth */
ul.menu>li + li + li
{
    /* styles for the 3rd LI */
}

/* alternate, more specific IE nth */
ul.menu>li:first-child + li + li
{
    /* styles for the 3rd LI */
}

Complex or formulaic nth-child selectors, or selectors with keywords are not possible with this method – but it does mean you can style, say, all the known list items in a static menu without resorting to lots of IDs or class names.

And no, of course this doesn’t work in IE 6 If you’re targeting IE 6 in this day and age you need to rethink your web strategy.