Last week’s big news in browser land: the release of an Opera development channel version: Opera Next. In April, Firefox announced its rapid release channel browser Aurora. And last week, Chrome/Chromium finally released Canary for Mac (Canary for Windows was released in July, 2010).

What does this mean? In all three cases, it means we can now run pre-beta versions of browsers alongside stable versions. Upgrades to the dev channel happen automatically and won’t affect our main installations. Finally, we can run multiple browser version installs without tricks, hacks, or running a browser from a disk image.

Download Opera Next from our snapshot server.

• don’t require the additional HTTP request of an image file.
• are easier to modify than image files.
• “weigh less” than most image files.

That’s the ideal, at least. In their current state, gradients are actually a hot mess. The reality?

• The specification is still in flux.
• Full gradient support is not available in all modern browsers. (For now, Opera 11 only supports linear gradients.)
• Many older, though relatively recent versions of browsers (Internet Explorer 8 & 9, Opera 10 Desktop, Opera Mobile, and Opera Mini, for example) don’t suport CSS gradients at all.

So, how can developers take advantage of gradients and still support older browsers? Let’s look at some approaches.

Set a background color

Take a look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

This is a fairly common scenario. The developer (*cough*me*cough*) covered most of her bases, but forgot one: browsers that don’t support gradients at all. You can see what this looks like in Internet Explorer 9 (see Figure 1).

Figure 1. Internet Explorer 9 doesn’t yet support CSS gradients. This is what it looks like if you don’t supply a background color.

Now look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-color: #333;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

Here we’ve set a background image, but we’ve also set a background color. Browsers that don’t support CSS gradients will ignore the last three lines. (Note: each browser also ignores the other browsers’ vendor-specific prefixes.)

Setting a background color is the easiest fall back for older / less modern browsers.

Set a background image using an external file

Consider the following CSS.

#linear{
    width:400px;
    height:300px;
    background-image: url(migas.jpg);
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

In this example, we’re taking advantage of how browsers apply the cascade. As it turns out, Opera 11, Chrome whatever-the-heck-version-it’s-up-to, and Firefox 4 will not make the HTTP request for the external file. Safari, however, does (see Figure 2). Internet Explorer 9 (and less-modern browsers) will only load the external file. Depending on your audience, this may be an acceptable alternative.

Figure 2. Safari downloads all images. Click to embiggen.

Note: I have just barely tested this in mobile browsers. (Opera Mobile 11 doesn’t support gradients. Users will see the external image).

Use SVG gradients to create a background image

Internet Explorer 9 and Opera 10 (including Mobile) do not support CSS gradients. They do, however, both support the use of SVG images as background images. Another alternative to using external images, then, is to use an SVG file.

#linear{
    width:400px;
    height:300px;
    background-image: url(gradient.gif);
    background-image: url(gradient.svg);
}

This example works in all current desktop browsers, and most mobile browsers. Safari 5, again, will download both images. Most others will download the latter SVG image. The advantages here are clarity and (arguably) ease of maintenance. Want a different gradient? Change the images.

You should be aware, though, that some recent(-ish) versions of mobile WebKit — such as the T-Mobile myTouch 4G browser — don’t support SVG backgrounds. You’ll still need to add a linear gradient for those browsers, or set a background color.

Or keep doing what we’ve been doing

Of course, the growth of SVG and CSS gradients support doesn’t preclude using GIF, PNG or JPG gradients. The biggest point in favor of using bitmap images is that they still work in older browsers and current ones.

As with any aspect of web development, the right approach should balance concerns of maintainability, file size, and the browser distribution of your audience.

You left out linear-gradient!

I left it out of the examples above for two reasons: (1) simplicity; and (2) the syntax could change (though if I had to predict, it won’t change by much). Be forward-thinking! There are very few reasons not to include the proposed linear-gradient syntax in your code.

We’re going to do a baseline JIT for Firefox 4. It’s not done yet, and it hasn’t landed in any tree yet, so nobody’s tested it. It’s gonna give similar performance characteristics to Chrome. But we’re also gonna do tracing on top of that. What we discovered, is that for a lot of applications, especially when you want to do anything that’s actually CPU intensive, we smoke everybody. It’s not even fair.

So says Christopher Blizzard, the Director of Developer Relations and Open Source Evangelist at Mozilla in his interview with Lifehacker/Gizmodo.

I love seeing geeks talk sh*t.

FormData interface coming to Firefox

An overview of the FormData object of XMLHttpRequest, and how you will soon be able to use it in Firefox. From Hacks.Mozilla.Org.

Dealing With the Dreaded ‘Flash of Unstyled Text‘

Tips for mitigating, even eliminating the appearance of unstyled text when using @font-face. From Webmonkey.com.

So Apple announced the iPad, and it won’t support Flash.

That shouldn’t be a surprise. Neither the iPhone nor iPod Touch support Flash. Indeed most mobile platforms don’t (yet) support Flash. Even the smartest of smart phones have limited processing power and storage space compared to laptops and desktops.

According to Steve Jobs, Apple doesn’t support Flash on its mobile devices because “it’s buggy.” But I’d guess their decision has as much to do with Flash’s capabilities. Many of the products in that cash cow known as the Apple App Store could be developed using Flash instead.¹ Supporting Flash would undermine that billion-dollar revenue stream, piss off iPhone / iPad developers, and also put Apple at Adobe’s mercy.

Besides, everyone’s moving towards HTML5, right? Well yes they are, but not so quickly. I wouldn’t rule Flash out for another 3 to 5 years.

Why do I say this? Four reasons:

1. Flash has inertia on its side. Major content sites such as Disney and Hulu still use Flash to deliver video, animation, and interactive experiences. According to Adobe’s statistics, Flash has over 90% penetration in mature markets. Developers already know how to use Flash and ActionScript to create these experiences. In short: there are a lot of folks invested in Flash as a platform.

2. HTML 5 isn’t quite ready for prime time. It’s a shifting standard, a work-in-progress. Though even Internet Explorer 8 supports some significant HTML5 features, Internet Explorers 6 and 7 do not. And both browser versions are still used widely enough that dropping support is not an option for most developers.²

3. Flash is still the best cross-browser, cross-platform way to serve audio and video. Safari / WebKit, Firefox / Mozilla and Opera all support the HTML5 video element. They do not, however support the same codec.

   Apple is squarely in the H.264 camp. Google paid a licensing fee so that it could include an H.264 decoder in Chrome. H.264 is a patented codec. Any browser that wants to enable H.264 video will need to pay a licensing fee.

   Licensing fees and patent concerns are why Opera and Mozilla are backing Ogg Theora. Ogg Theora is an open sourced codec with no known patents. I should add here that Chrome also supports Ogg Theora. Google, perhaps wisely, chose to include both.

   The big monkey wrench in video element adoption, however, is Internet Explorer. Internet Explorer is waiting for them other fools to work out that default codec business before it implements support for the element.

   And all of this is before we get into the differences in how browser vendors will execute the specification. That’s a whole ‘nother headache.

   We will be using Flash until clients are willing to pay for separate Safari, Firefox and Internet Explorer video integration or until the HTML5 working group agrees on a default codec.

4. Adobe is working to bring Flash to other mobile platforms. As Adobe’s Chief Technology Officer Kevin Lynch explained, We are now on the verge of delivering Flash Player 10.1 for smartphones with all but one of the top manufacturers. This includes Google’s Android, RIM’s Blackberry, Nokia, Palm Pre and many others across form factors including not only smartphones but also tablets, netbooks, and internet-connected TVs. Could the iPhone and iPad’s lack of Flash support be a deciding factor in consumers’ decisions not to buy an Apple device?

My Prediction for Flash

I suspect that as HTML5 gains prominence, Flash will — eff that, it should — shift from an authoring environment for its proprietary SWF format to one that generates HTML, CSS, JS and SVG code for the browser. I think the building blocks for such software are in place. Flash Builder (formerly Flex Builder) for example, eliminates (most of) the need for FLA files. Perhaps developers will one day use a mix of ActionScript and JavaScript in the Flash Builder authoring environment to create web-ready assets and animation that don’t require a browser plug-in.

Mobile-friendly Web Development Right Now

Despite the fact that Flash is supposed to come to every other mobile platform, Apple’s decision to keep Flash off of the iPhone, iPad, and iPod Touch is not without impact. Apple still runs the smart phone market; in some ways they drive the mobile web. That means the prudent path is (still) progressive enhancement, and ensuring that your critical content and navigation are built using HTML.

So will I buy an iPad?

Nope. I have a laptop, a smart phone (a T-Mobile G1), a desktop and an iPod Touch. To me, the iPad is that weird spot between my smart phone or iPod Touch and a laptop with the convenience of neither. It doesn’t have the pocket-sized portability of my iPod Touch or my phone. And it doesn’t (yet) have the robust features of a laptop — USB ports, optical media drives, and the ability to install any app. I can’t justify the value for the price.

Besides, I still much prefer books to e-readers. I can sell books, trade books, leave books, loan books, and get books wet. I am not about to soak in the tub with a $300 device, but I would with an $11 book.

What do you think about the iPad, Apple’s decision, or the future of Flash and HTML5?

¹ Many of these apps could also be built using HTML, CSS and JavaScript, but there’s no money in that either.

² There are scripts available to make IE act right, of course. ExCanvas, for example, mimics support for the canvas element in IE. Simple HTML5 isn’t much different from HTML 4.01. You can actually forge ahead with HTML5 now if you don’t need advanced features like DOM Storage.

If Privacy Icons become widely adopted (and I think Mozilla is in a unique position to help make that happen) then the correlation of good companies using the icons and bad companies not using the icons becomes rather strong. If a privacy policy doesn’t include any icons it’s synonymous with that policy making no guarantees for not using your data for evil. The absence of Privacy Icons becomes stigmatic.

Aza Raskin, head of user experience at Mozilla, on how browsers and companies could make privacy policies more user-friendly through a “bolt-on” machine-readable icon system, similar to Creative Commons. [Via Webmonkey]

Firefox 3.6 supports multiple file input. This new capability allows you to get several files as input at once, using standard technologies. This is a big improvement, since you used to be constrained to one file at a time, or needed to use a third party (proprietary) application. This will be particularly useful, for example, for photo uploads.

From multiple file input in Firefox 3.6. The post contains code examples and a link to a demo. You’ll need the beta version of Firefox 3.6 to take advantage.

Also see: Proposed File API specification

Sometimes when developing and testing a site, you need to clear your browser’s cache. Clearing the cache is particularly important when testing SWF files. Browsers tend to hold on to those like a pitbull on a chew toy.

Firefox makes it easy to clear your cache with its Clear Private Data feature (Tools > Clear Private Data). But by default, the Browsing History and Authenticated Sessions boxes are pre-checked in addition to the Cache box. If you just want to clear your cache, you have to uncheck those boxes and then click the “Clear Private Data Now” button.

That’s a pain in the touchas when you’re in a developing – uploading – testing loop. Luckily Firefox let’s you change that.

What to do

1. Enter about:config in the address bar. Click the “I’ll be careful, I promise” button if one appears.
2. In the Filter field, enter privacy.item. These are the current settings for the Clear Private Data box.
3. Change the settings for privacy.item.sessions and privacy.item.history from true to false by double-clicking.

Restart Firefox, then go to Tools > Clear Private Data. Cache will be the only pre-selected option.

Lately, the day job has had me busting booty on a Flash/ActionScript project that makes considerable use of the ExternalInterface class.

ExternalInterface allows Flash to communicate with its HTML container using JavaScript. It’s a groovy feature, but one that changes the development process a bit. Unlike straight-up Flash development, ExternalInterface requires you to test interaction between the movie and its container.

One way to do this is using the Firebug console. Set up a simple debug function embedded in your HTML or in an external JavaScript file: function debug(data){ console.log(data); }. Then pass troubleshooting data to it using ExternalInterface.call('debug','data you want to write'); just as you would with trace().

I even used this technique to dump XML data to the console. Works amazingly well.

A minor drawback: compiler errors won’t be written to the console. Instead you will see a generic error message, and your movie won’t load.

Using Flash Tracer

For a more robust option, try Flash Tracer, a Firefox extension by Alessandro Crugnola. Flash Tracer uses native Flash logging to deliver trace() messages directly to the browser. To use it, you’ll need to install a debug version of the Flash Player.

Using LiveHTTPHeaders

Sometimes when sending and receiving data to and from a server, you can’t tell what’s wrong by looking at your Flash application. There could be an error in your server side code. Or perhaps there’s a problem with the data you’re sending. This is where LiveHTTPHeaders comes in handy.

LiveHTTPHeaders shows both browser-and-Flash request headers and server response headers. It also sends encoded GET and POST data from HTML forms or ActionScript URLRequest() / URLVariables() / URLLoader() operations.

This extension won’t show the actual data the server has returned. But you can use it to spot things like invisible line break characters and internal server errors.

Related posts:

• Essential Firefox Extensions
• My new favorite Firefox extensions
• Clearing LoadVars() in ActionScript
• OurIndustryIsBroken.com: Tracking site users and traffic with PHP, MySQL and ActionScript

TraceMonkey, Resig explains, uses a computing technique known as trace trees (PDF) which adds just-in-time native code compilation to SpiderMonkey, Firefox’s current rendering engine.

What does this mean? As Resig explains:

It means that JavaScript is no longer confined by the previously-challenging resource of processing power. With this improvement it’s leap-frogged any sort of traditional and has gone head-to-head with computationally-powerful languages like C.

In other words, we’ll get JavaScript processing speeds that are Usain Bolt-on-crack fast, opening the door for more powerful JavaScript-powered applications.

Firefox’s announcement comes a few months after the WebKit team’s announcement of SquirrelFish, which will be the JavaScript engine used in Safari 4.

Resig and Brendan Eich also point out that these TraceMonkey improvements (and presumably SquirrelFish’s improvements) in conjunction with HTML 5‘s canvas element will mean we’ll see some slick JavaScript animation and game experiences, such as this one by Zachary Johnson.

The obvious roadblock to widespread adoption of all of this whiz-bangy JavaScript+<canvas> goodness is, of course, Internet Explorer. Internet Explorer 7 does not support the canvas element. Version 8 of the browser will not, although there is a workaround for IE7 available.

Still, without the dominant web browser on board — and conceivably not coming on board for at least a few years — the widespread use of JavaScript animations may not take off for some time.

Want to check see TraceMonkey in action? Download a nightly build of Firefox (codenamed Minefield), and in the about:config panel, set javascript.options.jit.content equal to true.

Also check out Mike Schroepfer’s screencast What can you do when your browser is 7 times faster?

It takes advantage of Firefox’s Gecko rendering engine for an easy-to-use application for making layouts. You can import bitmap images, add rich text or plain text, and when you’re done, export your drawing as a PNG file.

One downside: it runs inside of Firefox. You have to start Firefox in order to use Pencil. It is, however, free and open source. I used it (briefly) on a Mac running Leopard (10.5.4) with no problems. It’s also been tested on GNU/Linux, Windows XP and Vista.

Prism and other single-site / site-specific browsers

The richness of the Pencil Project made me think about the browser as an application environment. And that brings me to Prism (formerly WebRunner), Mozilla’s single-site browser project.

Prism — available as its own package and as a Firefox extension — lets you turn any web site into a quasi-standalone application.

At first glance, a single-site browser seems pointless — dude, just open another tab. But I find that the minimal GUI of an SSB really lets me focus on the task at hand. It’s particularly nice when used with web applications such as Google or Zoho, or blogging interfaces.

Prism isn’t the only single-site browser available. Mac users, can check Fluid, which is based on WebKit/Safari. Windows users have Bubbles.

Browser as platform = The future of applications?

Today, you still need an operating system on which to run Firefox and Prism. But is there room for a super-minimal OS with a Gecko-based (or WebKit-based, etc.) GUI? I’m thinking about one that runs web applications in a single-site browser (gOS is close, as is the iPhone) and still allows for richer applications such as the Pencil Project (Flock skims the surface of this). As both browsers and the languages we use to develop web sites become more powerful and feature-rich, (when?) will the browser truly become the operating system, rather than run on top of it?

Related

• Recommended: “From Browser to Platform: Mozilla Rises”
• Bubbles, a single-site browser for Windows
• Fluid, a single-site browser for Mac OS X
• Prism, a cross-platform, single-site browser and Firefox extension

[Pencil Project found via WebAppers]

Acid1 and Acid2 tested for compliance with CSS 1 and CSS 2 specifications. Acid3 also tests for support of DOM Scripting / ECMAScript, SVG and webfonts.

Safari 3 and Opera 9 pass the Acid2 test, as does the beta version of Firefox 3. Version 8 of Internet Explorer will also pass the Acid2 test.

Here’s how today’s leading browsers handle Acid3 (check out the reference image). Each image links to a larger screenshot.

Firefox 2

Opera 9.26

Internet Explorer 6

Internet Explorer 7

Safari 3

Firefox 3 Beta

It’s an inventive use of your user’s browser history, though I suspect it could potentially be used — in combination with cookies and logins — to detect which of your users are also regular porn surfers.

With that little bit of fearmongering out of the way, I’ll direct you to two Firefox extensions designed to stop such nosy coding (found in the comments on Niall’s post:

• SafeHistory
• SafeCache

That’s where Mozilla comes in. Via Ajaxian: Mike Schroepfer’s post Mozilla and Mobile. According to Schroepfer:

• Mozilla will add mobile devices to the first class/tier-1 platform set for Mozilla2. This means we will make core platform decisions with mobile devices as first-class citizens.
• We will ship a version of “Mobile Firefox” which can, among other things, run Firefox extensions on mobile devices and allow others to build rich applications via XUL.

Say what? XUL on the mobile phone? Awww junk! I think the mobile application and web space just got hotter.