Categories
Mozilla Programming

The Jetpack Debate

I’ve generally found Jetpack to be pretty cool. It’s easier to develop and I’m fairly familiar with both “traditional” extension development and jQuery so it seems natural to me. However I generally agree with Daniel Glazman’s blog post on Jetpack. I’ll even agree that closures can make code more difficult to read, though I think I’ve mostly adapted to it at this point.

Jetpack reminds me more of building JS “widgets” than extensions. I’m not sure I see the advantage of moving away from XUL which really isn’t “hard” for 98% of things (though XUL <wizard/> has admittedly made me say WTF a few times) to HTML unless some sort of portability were gained, but that doesn’t seem very likely at least right now. I haven’t seen any indication of intent either. XUL has the advantage of making good UI seemingly easy while HTML really doesn’t, though I’ll admit HTML5 is changing that.

The biggest problem I see with Jetpack is that too much of it is designed around existing needs. The problem with this process is that it’s always playing catch-up. The best extensions are disruptive and do things nobody ever thought of, or even thought possible. Looking at the Jetpack JEP list I see pagemods and toolbar. The kicker is these are “implementing” and “planning” respectively right now.

Things like jetpack.slideBar, jetpack.music and especially jetpack.lib.twitter make me feel a bit concerned. Why? Because they encourage too much conformity, and too many twitter client Jetpacks.

When developers are given such a sterile environment that’s intended to promote experience and stability it ends up inadvertently creating monotony and stalling innovation. If you want proof look at the iPhone. There are indeed some great apps and I say that as an iPhone user myself, but for each great application there are 1,000 that aren’t worth the price (which is often free). Many are just cookie cutter apps with a companies logo on them. Google used one undocumented API for a feature Apple didn’t think of providing a documented API for, and it was news worthy. While Jetpack distribution isn’t limited in the same way that iPhone apps are with the App Store the design questions still remain.

To quote Adblock Plus author Wladimir Palant:

…Jetpack has to support Adblock Plus, not the other way around. As it is now, Jetpack isn’t suitable for complicated extensions.

That’s the wrong order.

Categories
Mozilla

Firefox On Bing

Firefox On Bing.com

Bing’s background of the day today was a Firefox.

And again a few days later:
Firefox on Bing 2 Firefox On Bing for the second time.

Categories
Mozilla

5 Years Already?

Has it been 5 years already? The landscape has certainly changed since 2004.

I think it’s finally accepted that something can fight back against Microsoft. Size doesn’t guarantee market share on the Internet. In the pre-www world you had to convince a few managers to buy your product and you can be installed on 10k systems. Home users typically used what they knew from work. In 2009 even offices are becoming more accustomed to letting employees use what they feel works best (though not all there yet, easier system re-imaging is helping here). Home users put whatever they want on their computer. The focus is clearly shifting more and more towards the user and making their experience better.

Where will things be in another 5 years?

Categories
Mozilla Security

Plugin Check

Mozilla’s Plugin Check just launched. Considering 30% of Firefox crashes are plugin related, and they are often the source of security issues, it’s worth making sure you’re up to date.

It’s pretty simple to use. Just visit the page, and update the plugins that need to be updated. At the end of the day you want to see a string of green like this:

Plugin Check

An easy step for a faster, more stable, and most importantly more secure web browsing experience.

Categories
Google Mozilla

Google Buys On2

Google today announced they are buying On2 Technologies. This is one of their more significant purchases despite the relatively low price tag of $106.5 million since it’s video technology and Google is the largest video source on the web right now.

On2 is really an unknown to most people but their product has an amazing reach thanks to Adobe Flash. VP6 notably was included in Flash 8 and really brought about the age of Flash video (think YouTube). On2 also has VP7 which is considered a H.264 competitor. VP3 was released as open source and lives on as OGG Theora.

Of course by buying On2 Google will not need to pay any licensing for it’s VP7 technology, they can then bundle it into Chrome, Android and Google Chrome OS (finally giving Linux decent web video support). They could also open source it similar to these platforms in hopes that it will gain ubiquity.

This does however leave me wondering if this pending On2 deal had any bearing on the decision to leave HTML 5 <video/> codec ambiguous. It’s noteworthy since Google is very involved in the HTML 5 efforts. As I mentioned last month licensing is really key. If VP7 were open sourced and it’s licensing were compatible to meet Apple and Mozilla’s needs (which could lead to inclusion in Safari and Firefox respectively), OGG Theora is potentially dead overnight. Given Google’s strategy so far of making technology open source in efforts to encourage adoption, I wouldn’t rule this out, though it would likely take a while to evaluate everything and make sure they legally have that option. Timeline could also come into play here. The web isn’t necessarily going to wait for Google. These reviews can potentially take a long time. No guarantee others will incorporate it either, though it’s a pretty good deal should licensing work.

It’s also interesting that now Microsoft has Windows Media Player, Apple has QuickTime, and Google has On2’s codec bundle. It’s not exactly a “player”, but considering it’s usage it’s just as important.

It’s going to be very interesting to see how this plays out. One thing that seems relatively certain is that Google just made web video more interesting.

Categories
Mozilla Web Development

Debating Ogg Theora and H.264

Since the big HTML 5 news that there will be no defined codec for <audio/> or <video/> there has been a lot of discussion about the merits of such a decision, and what led to it. To quote Ian Hickson’s email:

Apple refuses to implement Ogg Theora in Quicktime by default (as used by Safari), citing lack of hardware support and an uncertain patent landscape.

Google has implemented H.264 and Ogg Theora in Chrome, but cannot provide the H.264 codec license to third-party distributors of Chromium, and have indicated a belief that Ogg Theora’s quality-per-bit is not yet suitable for the volume handled by YouTube.

Opera refuses to implement H.264, citing the obscene cost of the relevant patent licenses.

Mozilla refuses to implement H.264, as they would not be able to obtain a license that covers their downstream distributors.

Microsoft has not commented on their intent to support

I think everyone agrees this is going nowhere and isn’t likely to change in the near future. For the sake of moving HTML5 forward, this is likely the best decision.

Here’s how I interpret everyone’s position:

Apple’s Argument

One of the undeniable perks behind H.264 right now is that there is hardware decoding available and used on on certain devices. One of the most notable is the iPhone. Using hardware decoding means your not using the CPU which results in better performance, and most importantly better battery life.

Thus far there’s no hardware Theora decoder on the market (if you know of any let me know, my research says none), which I suspect is why Apple is hesitant to jump on board. Until there’s hardware that’s proven to perform well, be cost-effective in the quantities Apple needs, and not be bombarded with patent infringement claims, I suspect they’d rather settle with H.264. The patent part is critical. Apple can update software to comply with patent wars pretty quickly, as many other companies have done with software in the past. Hardware is not so easy. Last minute hardware changes are harder to deal with than software because of the many things it impacts, and the inability to update at a later date.

I’m almost positive the lack of hardware support is the exact same reason Apple has been so against Flash support. Remember the YouTube application isn’t using VP6 like regular flash, it’s using H.264 (that’s why it took so long for all of YouTube to be available on the iPhone).

If there’s enough Theora content out there, there will likely be Theora decoder hardware made to meet market demand. To get to this point will be difficult with the amount of VP6 (Flash) and H.264 content already on the web. H.264 alone has a major head start in applications. VP6 has several years of video on the web now (and I still don’t think it has a hardware decoder on the market though that might be due to licensing again).

In the long run, I think mobile technology will improve enough to make this a somewhat unnecessary constraint. Mobile CPU’s and GPU’s are just starting to get to the caliber needed for video. Performance per watt should improve. Battery technology is just starting to get pushed to the limits. This is a good thing for Theora in the long run, but the question is how long?

Until it can be played with minimal impact on battery life, I don’t think any company who has a heavy investment in mobile will want to jump on board.

Google’s Argument

Google has money and can license H.264. Shocker. Google however has trouble when it comes to Chromium. I suspect Google doesn’t care too much about which way this goes since what they support in Chrome doesn’t mandate that YouTube support it. However if the encoding quality for a given bitrate is good enough, it becomes a viable option.

Regarding the quality argument, I’ll simply point to this comparison. I the quality today is comparable already, and likely to get better as the encoders improve. I’ll leave this discussion here.

Opera’s Argument

Opera says H.264 is to expensive to license. I don’t know what the costs are, and what they would be for Opera, but I’ll take their word on it. After all, the do have a product available for free download. While commercial and closed source, they don’t have Google’s revenue stream and I respect that.

Mozilla’s Argument

Mozilla can’t license for downstream Gecko use etc. I’m sure a good part of the argument is also that requiring licensing fees to use <video/> is bad for the web and open source. I agree.

Microsoft’s Argument

No comment. Historically they implemented <marquee/> but not the <blink/>. Make of that what you will.

<video/> could be supported by plugin if needed. I recall Adobe supporting SVG by plugin a few years ago.

Where to go from here?

I think there are a few possible outcomes. As for what I think are the most likely:

  1. There’s a push for hardware decoding that makes Theora on mobile technically possible and working well. If Apple legally is satisfied and jumps on board that changes the game. As I stated earlier I think Google is mostly ambivalent since they support both right now. Opera doesn’t want H.264 anyway, so they are cool. IE 8 can likely be handled by a plugin. Apple really is the deciding factor. Theora is the future.
  2. See what the web does. I suspect at least for a long while the web will just stick with Flash since it works on almost all desktops. For mobile the iPhone and Android make up pretty much the bulk of the mobile video market and that doesn’t look like it’s changing so fast. Content providers that want mobile will encode for mobile. That means 3 target platforms, not ideal but reasonable. H.264 and whatever Adobe adopts is the future.

I know how the media is interpreting all of this. How do other developers, and open source folks see it?

Categories
Mozilla Web Development

Optimizing @font-face For Performance

You want to use @font-face, then you realize it’s got some downsides. First of all, it’s another http request, and we know that the golden rule of web performance is to keep http requests to a minimum. Secondly fonts aren’t even small files, they can be 50k+ in size. Lastly the lag of fonts loading last means you page seems to morph into it’s final form.

Here’s a cool little optimization. By using a data: url you can use the font inline by encoding in base64. For example:

@font-face {
    font-family: "My Font";
    src: url("data:font/opentype;base64,[base-encoded font here]");
}
 
body {
    font-family: "My Font", serif
}

You can see this in action here. This seems to work fine in Firefox 3.5, and Safari 4 (presumably any modern WebKit based browser). Other browsers will simply act as if they don’t support @font-face.

In practice I’d recommend putting it in a separate stylesheet rather than inline css so that your pages are smaller and css can be cached for subsequent page views.

Data url’s are part of Acid2, which most modern browsers either pass or plan to pass. If you use an Open Type font you’d get pretty decent compatibility (IE only supports Open Type). Using True Type you’d still get pretty good compatibility sans IE. Check the @font-face page on MDC for more details. Unlike images, browsers that support @font-face are likely to support data: url’s as well, making this a pretty good solution.

Special thanks to Open Font Library for having some nice free fonts with awesome licensing. This post was partially in response to a comment left the other day on my @font-face hacks blog post.

Categories
Mozilla

Firefox 3.5 Released

Firefox 3.5

Firefox 3.5 has been released. Click the logo above to get it now. If you don’t know why you want it, read my blog post from a few days ago about things you’ll love about Firefox 3.5.

Categories
Mozilla Web Development

@font-face Hacks

I’m going to make a bold prediction on the night before a certain web browser is scheduled gets an upgrade. @font-face (MDC) will change web design, but not just for typography. As I suggested a few days ago, to use a font on the web it needs to sit on a webserver so the browser can download it, hence the website is “distributing” the font. Licensing for many fonts doesn’t currently permit this, making @font-face for fonts somewhat problematic and hard to use… at least today.

Cool Trick!

Rule #1 of Steve Souders popular book “High Performance Web Sites” is simply:

Make Fewer HTTP Requests

That said, @font-face can be essentially as an image sprite by creating your own font with the glyphs you want. Unlike image sprites they aren’t hacky in nature requiring tricky coordinates, nor are they obnoxiously memory intensive (and a drag on mobile devices). Firefox also loads fonts last, so you can be assured it won’t slow down the rest of your page. They also degrade nicely for devices that don’t support them.

Of course this changes webdesign to use simpler icons and pick 1 color per glyph… but there are some pretty interesting enhancements for example the ability to scale. Fonts are designed to resize much better than an image.

The other caveat is that this can make your markup slightly ugly. However it’s not so bad when your building something in JavaScript. Consider for example implementing Pac-Man. Rather than a dozen images, or some complex sprite you can simply move <em>p</em> around. You can have quite a few glyphs in 1 font file.

Of course you can also use <canvas/> or a data: url to embed images, but IE doesn’t support <canvas/> and only recently started supporting data:. IE has supported OpenType (not TrueType) fonts since IE 4.

I’d be curious if anyone actually implements this and how well it works in practice. It’s not a true replacement for image sprites, but for a few cases, such as simple icons, it could actually do the trick.

Um What?

This trick can also be engineered to work against the way the web traditionally works. For example, I could create a ROT13‘d font or any other encoding I imagined. This essentially lets you remap the way characters are on the page, and the way they appear. For example on the page may appear:

<span class="rot13font">rknzcyr@qbznva.gyq</span>
<small><strong>Note:</strong> Do not copy/paste my email address</small>

That looks like a totally invalid address, but with a ROT13 font, you’d know what it is… though if you copy/paste it you’re going to get the encoded version. (I could in theory course engineer some JS to ROT13 the string). This also could deter some spam bots, which lore says have found ways around JS munging.

Conclusion

Moral of the story: @font-face can be fun for more than just typography. Cult of Helvetica be damned… all you typography geeks.

Categories
Mozilla

Things You’ll Love About Firefox 3.5

For the upcoming Firefox 3.6 release: go here!

Firefox 3.5 is around the corner. For those who don’t pay attention to development here’s the big features worth checking out. There are lots more, but these are my favorites:

User Centric Features

Private Browsing – Officially it’s called “Private Browsing” but most know it as “porn mode”. Simply put once you turn on the feature nothing about your browsing is saved to your computer until you turn it off. No browser history, cookies, cache, no passwords, download list. Great for shared computers where you may not want the next person to know where you shopped, what you bought etc.

Faster JavaScript – Everyone is doing it. Firefox 3.5 now ships with TraceMonkey which uses a technique, called trace trees to add just-in-time native code compilation to SpiderMonkey, the JS engine in Firefox. Bottom line: faster JavaScript makes JavaScript powered sites like Gmail way faster.

Faster Awesomebar – The awesomebar is a fast way of browsing the web, but the UI can sometimes get a little sluggish. Some awesome work has been done to optimize it for better performance. Faster UI = better browsing experience.

Better Awesomebar – The Awesomebar got a few enhancements including autocomplete for tagging, which is extremely handy as well as editing tags on multiple bookmarks at the same time.

Undo Closed Window – We’ve all done it before. Now you can undo a closed window just like a closed tab.

Drag Tab To New Window – Previously you could drag/drop to reorder tabs. Now you can drag a tab off the tab bar to move it into its own window. This may sound trivial but it actually makes organizing tabs much easier.

Video/Audio – Firefox 3.5 supports the new HTML5 <video/> and <audio/> tags. Specifically it supports Vorbis in Ogg containers, as well as WAV with support for more formats expected in the future. I’ve discussed open video before and suggest learning more about how important this is there.

SSL Error Pages Suck Less – The error pages shown when there is an SSL error were pretty tough on users since they didn’t display anything helpful. The new error pages are a bit more helpful. The bug implementing the changes has tons of details on the changes.

Geolocation – Simply put a website can (if you allow it) gather information about your internet connection and using a location service (provided by Google by default) will calculate your location. No more needing to constantly type in your zip code, or city name to get local information. For privacy you need to explicitly allow it. Geolocation is in a word awesome.

New Icon – Well, it’s not really new. It’s “refreshed” I guess. It’s not a huge change, but it does look really sharp, especially in more modern operating systems that use larger icons like Mac OS X. Alex Faaborg has it on his blog in various sizes for you see.

Developer Centric Features

Web Workers – My personal favorite is web workers. Essentially its background processing in a separate thread for JavaScript. No more locking up the browser’s UI because you need to do some complicated JS calculations. I’ll leave it to the documentation linked above for examples. Very handy stuff.

@font-face – Designers have long been frustrated with the lack of font options on the web. They often resort to using images and flash as a way to expand their font options. With @font-face it’s now possible to use custom fonts and reference them via css. There is however the issue of licensing of fonts used on a webpage since the font file itself is accessible via a web browser.

Native JSON Enough said. Native JSON is fast. var obj = JSON.parse(someJS);

Cross Site xhrxmlHttpRequest() has ushered in a new era of JavaScript. It’s not however without some serious limitations. One of the most obvious limitations is that you can’t use it across hostnames. Until now.

There’s more cool toys, but these are my favorite.

Still not convinced of all the new stuff? Check out this demo, then look at the source behind it. It’s pretty impressive.