Archive for May, 2011

File Under: Uncategorized
May
30
2011

Stop Typekit Fonts From Slowing Down Your Site

By

That's a fancy-lookin' T you got there.

That’s a fancy-lookin’ T you got there.

Typekit is one of the easiest ways to get fancy fonts working on your website. Just sign up for an account, pick a font and paste a few lines of code into your pages. TypeKit takes care of the rest, ensuring that your fonts load and there’s no unsightly flash of unstyled content (FOUT) or other problems.

There is, however, one possible problem with the default way of embedding Typekit fonts. If the TypeKit code fails to load, it can slow down the rest of your site. Typekit avoids FOUT by pausing your page load for a fraction of a second, but if the Typekit script never finishes loading, that fraction of a second can turn into many seconds. While Typekit has excellent uptime, let’s face it, outages happen, and we understand if you don’t want to hang your own site’s fate on another.

For those worried about depending on Typekit there is a workaround — load Typekit scripts asynchronously. The Typekit blog recently put posted an in-depth look at various way to embed Typekit fonts in your pages, including an asynchronous method which won’t slow down your page should Typekit become temporarily unavailable.

The disadvantage of the asynchronous design pattern that Typekit outlines is that it means a bit of extra code in your pages. Most likely a few more bytes in your HTML isn’t going to cause a significant speed hit, but it is something to keep in mind.

See Also:

Tags:
File Under: CSS, JavaScript, Software & Tools, Web Standards
May
25
2011

Review: Hype Animates the Web, No Flash Necessary

By

To create animations using web standards like HTML5, CSS 3 and JavaScript requires writing code. That’s fine for programmers who love nothing more than the blank space of a new document in their favorite text editor, but it’s a problem for designers accustomed to the visual, drag-and-drop workflow of animation apps like Flash. There’s nothing quite like Adobe’s Flash application for designers who want to stick with web standards.

Hype is hoping to change that. The new Mac OS X application uses many of the familiar interface elements that Adobe Flash offers — timelines, keyframes and drag-and-drop editing — but generates web standards output consisting of HTML, CSS and JavaScript. In short, Hype hopes to be to standards-based animation what the Flash app is to creating Flash movies.

While the initial release of Hype is impressive, it’s far from a Flash replacement. Perhaps more disappointing is that animations created with Hype suffer some of the same drawbacks you’ll encounter when using Flash.

The Good

For those with a background in Flash, the Hype learning curve is very short. Hype’s menu layout and palette structures are different, but the basic elements are essentially the same. To use Hype you drag objects — images, videos, vector art, etc — onto the stage and then you animate them by creating keyframes. One thing that’s different from Flash is Hype’s very handy “record” feature. To animate an element, just get everything where you want it for the first frame, add a new keyframe and then click record. Everything you do after that is recorded and translated into CSS and JavaScript-based animation.

To create a more complete movie-like animation Hype uses scenes, which break up your content and allow you to create transitions. For example, to create a slideshow, just drag your images into Hype and then create a new scene for each image. Add some transitions and you’re on your way. (That’s not the only way to create a slideshow, but it’s one of the simplest.)

Hype doesn’t offer everything you’ll find in Flash. Most notably there is no concept of MovieClips — self-contained movies within movies. There’s also no equivalent to Flash’s customizable tweens and advanced filters for blending objects.

Hype does offers plenty of canned elements, like buttons, boxes, and text boxes, to speed up simple tasks like adding text and other elements to your animations. To add elements to your page you just head to the Insert menu, select what you want and then you can style it with the properties palette just like you would any other element in Hype.

Hype's Flash-like IDE makes animating easy

Hype is simple enough to use that I was able to download a copy, watch the intro movie and five minutes later I generated the simple animation at the bottom of this post. Naturally to create something more interesting and useful will take you a bit longer, but it’s nothing compared to writing out the CSS and scripts by hand.

While Hype is primarily a visual editor, there are options to access properties like an element’s innerHTML and the Identity palette allows you to customize element IDs so you can target that element from other scripts. This is particularly handy if you want to create some custom CSS on top of what Hype generates.

The Bad

Hype, despite what its marketing materials claim, does not generate HTML5. It generates good old (standards compliant) HTML 4, CSS and JavaScript. That shouldn’t detract from from what Hype is capable of, but it’s disappointing to see the amount of HTML5, ahem, hype, surrounding Hype. Hype doesn’t even use canvas elements (animations are wrapped in div tags), nor does it use any of the new APIs (like say History or Web Workers).

Perhaps most disappointingly Hype doesn’t use the HTML5 History API. Because of the way Hype documents are embedded in a page, like Flash animations, Hype breaks the browser’s back button. What’s even more disappointing about Hype breaking the back button is that it’s not necessary. If Hype supported the History API, Hype documents could easily update the URL and not break one of the most fundamental elements of the web (see Mark Pilgrim’s excellent write up in the History API for more details on how to use it).

In some use cases that won’t matter, but if you’re thinking Hype would make a great slideshow creator, well, keep in mind that no one will ever be able to link to your individual photos without some extra effort on your part. Similarly, any transitions that happen in any Hype animation won’t be accessible via the back button.

Hype does offer an embedded editor so you can hook up the JavaScript yourself and take advantage of the History API, but then you’re back to writing code yourself.

Hype also makes some assumptions about your site structure when it generates HTML and JS. If you’ve got FTP access to your server then there’s nothing to worry about. But to embed my simple Hype animation in this post I had to change quite a few file references in the code. Hype assumes that all the resources it needs are in the resources folder it creates. Since I don’t have FTP access to this domain there is no way to get that folder on the server. Instead I uploaded the three required files through WordPress and then had to edit the generated Hype code to add the correct file paths. It wasn’t all that hard, but it did mean digging into the code, which at least partially defeats the purpose of Hype.

Another things to keep in mind is that Hype is heavily geared toward the WebKit rendering engine. While most of the effects work just fine in other standards compliant browsers, there are a few things that only work in WebKit. Where possible Hype falls back to pure JavaScript (for example in browsers that don’t understand CSS 3). Fortunately the Hype export function will warn you about any browser incompatibilities when you publish.

Conclusion

Despite some publishing hiccups and a few missing features, Hype is still one of the easiest ways I’ve seen to create Flash-free web animations. It’s like having most of what’s good about Adobe’s Flash app, without the downside of publishing to the Flash file format. Sadly Hype still falls prey to some of Flash’s weaknesses, but this is a 1.0 release and no doubt Hype will improve as time goes on.

Hype is currently available for $30 in the Mac app store. If you’ve been wanting to transition from Flash-based animations to web standards, but haven’t wanted to wade through the complexities of JavaScript and CSS 3, Hype is the droids you’ve been looking for. Just bear in mind that it has a few shortcomings of its own.

Hype Example

Here’s a very simple example of an animation created with Hype. Use the WebKit Inspector or Firebug to see how it works.

Tags:
File Under: Browsers
May
24
2011

Mozilla Rejects WebP Image Format, Google Adds it to Picasa

By

Google built the royalty-free WebM video format with the sophisticated VP8 compression technology that it obtained in its 2009 acquisition of On2. In addition to advancing the goal of open video for the Web, the search giant also used On2 technology to build a new image format called WebP with the aim of reducing page load time by increasing the efficiency of image compression.

WebP uses some of the still-image compression techniques that VP8 relies on to compress individual video frames. The format is intended for use with lossy images as an alternative to the venerable JPEG. Google conducted a large-scale study demonstrating that WebP offers an average file size savings of 39 percent. Despite the seemingly impressive results, not everybody is convinced by Google’s findings. Mozilla, which has officially refused to support the format in Firefox, has emerged as one of WebP’s most prominent opponents.

Building mainstream support for a new media format is challenging, especially when the advantages are ambiguous. WebM was attractive to some browser vendors because its royalty-free license arguably solved a real-world problem. According to critics, the advantages of WebP are illusory and don’t offer sufficient advantages over JPEG to justify adoption of the new format.

Aside from Google—which introduced official support for WebP in Chrome 12—Opera is the only other browser that natively supports the format. Despite the ease with which it can be supported, other browser vendors are reluctant to endorse the format and make it a permanent part of the Web landscape.

After studying quality and performance characteristics of WebP, Mozilla decided last month not to support the format. The WebP feature request in Mozilla’s bug tracker was resolved with the “WONFTIX” label and a number of community-supplied patches to enable the feature in Firefox were politely rejected.

“As the WebP image format exists currently, I won’t accept a patch for it. If and when that changes, I’ll happily re-evaluate my decision!” wrote Mozilla developer Joe Drew in a Bugzilla comment.

Mozilla’s Jeff Muizelaar offered a more detailed technical explanation about the problems with WebP in a blog post. His well-articulated critique sheds light on the problems with Google’s testing methodology, lays out the weaknesses in the WebP feature set, and explains Mozilla’s broader philosophical objections against indiscriminately adding new image formats to Firefox.

Muizelaar’s complaints about Google’s WebP testing methodology are familiar because they echo some of the concerns that were raised early on by other WebP critics like x264 developer Jason Garret-Glaser. The gist of it is that Google is using peak signal-to-noise ratio (PSNR) as its basis for quality comparisons—a technical benchmark that experts say fails to account for how images are actually perceived. Another problem is that Google recompressed existing JPEG images rather than starting with uncompressed source files. Both of these factors raise doubts about the validity of Google’s testing.

WebP’s lack of basic feature parity with JPEG in areas like metadata handling and ICC color profiles is identified by Muizelaar as another major problem with Google’s format. It also doesn’t add any important features that JPEG lacks, such as support for an alpha channel. He goes as far as using the phrase “half-baked” to describe the deficient WebP feature set.

Adopting a new image format in Web browsers is a big decision. Once a format becomes a part of the Web, it will have to be supported in perpetuity—adding overhead to the browser—even if it largely fizzles and only gains a small niche following. The chances of WebP attracting widespread use at this stage are very limited, so it seems prudent to avoid shoveling it into the browser.

Muizelaar argues that there is still room for further optimization by improving JPEG compression. The time that Google is putting into WebP, he says, would be better spent by improving JPEG encoders or contributing to existing next-generation image format efforts. One in particular that he cites as more promising than WebP is Microsoft’s JPEG XR, which has a better feature set than WebP, but also suffers from a lack of obvious quality advantages.

Google’s enthusiasm for WebP hasn’t been dampened by Mozilla’s criticism. A post published on Google’s official Chromium blog last week highlights a number of quality improvements in the implementation and discusses the growing number of third-party adopters. Most significantly, Google is adding WebP support to its own Web applications—including Picasa and GMail.

A new “fancy” upsampler that Google has integrated into the decoder implementation will reduce the pixelation of edges between colors in compressed images. The encoder has been improved with an experimental feature that it can selectively apply different compression and filtering behavior to various sections of the image in ways that will reduce the kind of “ringing” artifacts that are commonly seen in lossy images. The search giant also touts improved progressive loading support for WebP, which shipped in Chrome 12.

Despite WebP’s present limitations and lack of clear competitive advantages, it seems like Google is still making meaningful progress. The WebP format isn’t ready for widespread adoption today, but further optimization and perhaps a rethinking of the container format could someday make it successful.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

See Also:

Tags: ,
File Under: Blog Publishing, Browsers
May
24
2011

WordPress Drops Support for IE 6

By

The popular blog publishing tool WordPress has joined the growing cadre of sites dropping support for Microsoft’s Internet Explorer 6 web browser. The recently upgraded WordPress.com brings a handful of new features and a revamped, cleaner design in the admin pages, but perhaps the biggest news in the release is that the admin pages no longer support IE 6.

Users visiting the admin section of WordPress.com with IE 6 will now see a message to upgrade their browser (the same message will appear in the self-hosted WordPress 3.2 when it is released in June). The WordPress blog says it’s dropping IE 6 because, “it has required increasingly complex code trickery to make the WordPress dashboard work in the IE 6 browser, which was introduced 10 years ago and does not support current web standards.”

WordPress is just the latest in a long list of sites that have abandoned IE 6, including Gmail, YouTube, Basecamp and hundreds of others.

Indeed you’d be hard pressed to find a web developer who wants to keep supporting IE 6. Even Microsoft has set up a website that essentially dances on the grave of IE 6 (after WordPress announced it would drop IE 6, Microsoft actually said “thank you WordPress“).

However, according to Net Applications, IE 6 still has almost 12 percent user share worldwide. In the U.S. the number is just under 3 percent, but in China it’s still nearly 35 percent.

Compounding the problem are the number of corporate intranets that require IE 6. Microsoft is hard at work trying to convince large corporations to upgrade — if you’re still using IE 6, that means you haven’t upgraded to Windows 7, which is Microsoft’s real goal with the kill IE 6 campaign — but for Microsoft’s biggest customers, upgrading means investing millions of dollars in new infrastructure.

While developers may enjoy dropping IE 6 because of its subpar support for web standards, for end users that’s generally not a concern. What is, or at least should be, the bigger concern for users is that IE 6 is less secure.

If you’re part of the tiny segment of users that can — but haven’t — upgraded from IE 6, we suggest doing so. Grab a copy of Firefox or Chrome and join the modern web.

See Also:

Tags: ,
File Under: Uncategorized
May
23
2011

Simplify Firefox: Experimental Add-on Hides the URL Bar

By

LessChrome HD Offers a minimalist take on browser chrome

Mozilla Labs has released a new experimental Firefox add-on, dubbed LessChrome HD, which hides the URL bar to give webpages a bit more room. The idea is to only show the Firefox user interface when needed, the rest of the time the screen real estate is given over to the actual webpage.

The LessChrome HD experiment is available through the Mozilla Add-ons site and you can even try it out without restarting Firefox. LessChrome HD works in Firefox 4 and above.

LessChrome HD doesn’t dispense with the URL bar, it’s just hidden. Moving your mouse anywhere into the window chrome will reveal it, as will the old cmd-L keyboard shortcut or cmd-T to create a new tab. Mozilla refers to this as an “on-demand interface.” In other words, it’s there when you need to navigate and disappears when you’re just reading something on the page.

LessChrome HD is somewhat similar to the new hidden nav bar option in Chrome 13 and seems to hint at a new UI design direction for browsers: hiding the URL bar. The extra screen real estate is useful if you’re using a small screen laptop, but even if you’ve got a massive monitor the minimalist user interface helps focus your attention on the web page, rather than the web browser.

Not everyone likes this trend. Software developer Dave Winer likens the missing URL bar trend to building a house without a backdoor, writing that the URL bar is “the way you can be sure you can get somewhere even if all the powers-that-be don’t want you to go there.” I’d argue that LessChrome HD and Chrome 13′s URL bar experiments are more like hiding the backdoor than eliminating it. That said, I’d hate to see this become a default in any web browser. It seems to work well as it is — an add-on for those that want it, while those that don’t can safely ignore it.

See Also:

File Under: Browsers
May
23
2011

Firefox 5 Enters Beta Channel With CSS, Speed Improvements

By

Mozilla has pushed out the first major update for Firefox 5, opening the new beta channel for early adopters. Firefox 5 beta 1 is the first release in the beta channel, which is part of Mozilla’s move to a faster release cycle designed to get experimental builds of the web browser out to a wider audience.

If you’d like to take the new beta for a spin, head over to the Firefox channels page and download a copy. Also note, if you’ve been using the Aurora channel, recent updates to that pre-beta release mean you can now switch to the new beta simply by heading to the “About Aurora” menu and choosing “change.”

The new beta release means that Firefox now has three major channels you can use: Aurora, Beta and Release (there’s also a nightly builds channel, but it tends to be very unstable). The three main Firefox channels correspond to Google Chrome’s dev, beta and stable releases.

The first beta release of Firefox 5 adds support for CSS animations, which allow developers to animate transitions between CSS states. For a list of all the animations Firefox 5 currently supports, head over to the Mozilla developer page (note that all the supported rules currently require the -moz prefix).

Firefox 5 beta sees some performance improvements to JavaScript, memory, and networking performance. There’s also been some speed boosts for canvas-based animations.

Other new features include improved support for web standards like HTML5, XHR, MathML and SMIL, along with the usual bug fixes that come with any beta release.

To go along with the new desktop beta, there’s also a new beta of Firefox 5 for mobile devices. Firefox 5 beta for mobile adds support for the Do Not Track header and offers some speed improvements, particularly on 3G networks. To grab the latest version of Firefox 5 for Android, head over to the Android market.

See Also:

Tags:
File Under: CSS, Web Standards
May
20
2011

A Guide to CSS Hacks for Internet Explorer

By

Woolly, the CSS sheep.

Internet Explorer. That’s all you really need to say to raise a web designer’s blood pressure. And yes, we know IE is improving, but there are still plenty of users stuck on IE 8 and IE 7 (even IE 6) and you can’t just leave those browsers out in the cold.

The first method that came along to deal with IE’s rendering quirks were various CSS hacks — slip an underscore in here, add an asterisk there and you can target specific versions of IE in your stylesheets.

CSS hacks work well enough, but they’re a pain to maintain. Using conditional comments to load IE-only stylesheets is another option, but now you have extra HTTP requests and two stylesheets to maintain. You could also use conditional comments to add CSS classes to the <html> or <body> tags of your pages, but that increases the size of your pages in every browser.

The truth is there’s no perfect way to handle IE. Each method has its advantages and disadvantages and the right answer will vary from project to project.

We can’t tell you how to handle IE, but we can tell you that developer Mathias Bynens has put together a very well written and thorough rundown of all the different ways you can handle Internet Explorer’s rendering quirks — conditional stylesheets, conditional classnames and good old CSS hacks. Bynens also has a fourth option: combining conditional classnames with “safe” CSS hacks.

Bynens defines “safe” CSS hacks as hacks that “work in specific versions of a given web browser” and are “unlikely to be parsed by all other browsers, including future versions.”

Regardless of how you choose to deal with Internet Explorer, the reality is you will have to deal with it. Bynens’ post makes a great primer on the various options available and is well worth adding to your bookmarks.

See Also:

Tags: , ,
File Under: HTML5, Web Standards
May
20
2011

Drink Up HTML5, It’s Last Call

By

After more than 3 years of development, the World Wide Web Consortium (W3C) HTML Working Group has voted to move the HTML5 draft specification to Last Call status. That means HTML5 is about to crawl out of the dark pub and into the harsh morning light of the web.

While the HTML5 spec may just now be emerging into the light, savvy Webmonkeys have been using HTML5 tools for some time. In fact, HTML5 is already all over the web. Whether it’s natively embedded video or highly experimental movie projects or very angry birds, clearly its draft status has not stopped developers from embracing HTML5.

It’ll still be several years before HTML5 reaches the official Recommendation status (the current timeline puts the finalized HTML5 spec out in 2014), but Last Call is the first of a series of important steps for the web’s new lingua franca.

Last Call status means there will be 10 more weeks of bug reports and then the W3C’s HTML Working Group will have until January 2012 to fix those bugs. Once that’s done, barring any substantive changes, HTML5 will move to a Candidate Recommendation, and then, eventually on to become an official W3C Recommendation — prime time status.

There are technically two days left in the voting for Last Call status, but it is unlikely that the HTML Working Group won’t move HTML5 to Last Call (and so far there are no Formal Objections). However, W3C Working Group co-chairman Daniel Glazman has a entered a resounding “No” vote with some criticisms worth mentioning.

Among Glazman’s contentions is the still unsettled longdesc attribute. Although longdesc is part of HTML4 (it provides a link to a long description of an image, to supplement the alt attribute), it’s long been on the drop list for HTML5. But HTML5 is supposed to maintain backwards compatibility with early versions of HTML and the absence of longdesc creates a problem.

Glazman believes that until longdesc is added back in, and a number of other outstanding issues are resolved, the HTML5 Working Group should hold off on the move to Last Call.

HTML5 community leader Shelley Powers calls the No votes “politics, as usual.” There has certainly been no shortage of politics and infighting in the development of HTML5, and we wouldn’t expect the move to Last Call to be any different.

If you’re curious who voted Yes and No, and who abstained, head over to the W3C site and check out the Last Call poll results (Minor point worth noting: Voting results are wrapped in table tags — are poll results really tabular data? Discuss.)

See Also:

Tags: ,
File Under: Browsers
May
20
2011

Chrome 13 Introduces Experimental Hidden Nav Bar Option

By

The Google Chrome user interface has always followed a model of minimalism. The Chrome developers have sought to cut the cruft as much as possible to slim down the parts of the browser window that don’t show content. They could soon take it to the next level by excising the traditional navigation toolbar.

A new experimental user interface option that has landed in early pre-release builds of Chrome 13 offers a first look at what they have in mind. The browser navigation toolbar can be completely hidden, leaving only the tab bar, menu button, and content area. The forward and back buttons are moved into the tab bar, placing them in the top-left corner of the window.

To access the URL textbox, the user has to click a browser tab. This will cause a floating navigation bar interface with a URL textbox and refresh button to drop down from the tab. The floating bar will remain on the screen as long as the textbox is active, but it will slide back up and disappear after a few seconds when the textbox doesn’t have focus and the cursor is out of range.

Chrome 13: They shrunk my URL bar

We tested this feature ourselves using the Canary build channel on Windows. The feature isn’t yet supported on Mac OS X. It’s obviously still very experimental and isn’t configured out of the box. To test the new hidden navigation bar, you have to enable the feature from the about:flags panel and then toggle it from the tab context menu.

This new streamlined navigation bar obviously poses some phishing risks, because it doesn’t make the domain and SSL status of the current site easily visible to users. It’s important to remember, however, that it’s still at an early stage of development is only being made available as an option rather than a default.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

See Also:

Tags:
File Under: JavaScript, Web Apps
May
18
2011

Yes Virginia, That Is Linux Running on JavaScript

By

Linux running in a JavaScript-based emulator

JavaScript never seems to get any respect. It’s not a real programming language, detractors complain, it’s just some script language that runs in the web browser. We’re not sure what makes JavaScript less “real” to some, but thanks to today’s web browsers, JavaScript has become a very powerful language. Powerful enough to run Linux in your web browser.

French developer Fabrice Bellard has built a JavaScript-based x86 PC emulator capable of running Linux inside a web browser.

If you’d like to try it out, point Firefox 4 or Chrome 11 to the demo page. Keep in mind that this is just Linux, no X Window or other graphical interface, just the command line, a small C compiler and QEmacs, Bellard’s emacs clone. Still, it’s really Linux, really running in your web browser, really using JavaScript to emulate hardware.

For more info on how Bellard did it, as well as what the hardware emulator supports, see Bellard’s technical notes.

Because the hardware emulation is built around the Typed Array spec, Bellard’s Linux experiment only works in those browsers that support JavaScript typed arrays, namely Firefox 4+ and Chrome 11+ (though a bug in Chrome 12 prevents it from working in the latest version of Chrome ).

Bellard is probably best known for founding the FFMPEG project, but unlike that very useful project, Bellard says his JavaScript-based Linux experiment has no real goals. “I did it for fun,” writes Bellard, “just because newer Javascript Engines are fast enough to do complicated things.”

That said, Bellard does have a few possible uses in mind, including serving as a benchmark for JavaScript performance (how fast can your JavaScript engine boot Linux?), client-side processing and perhaps, with a few improvements, running old DOS games and other software in the browser.

See Also:

« OLDER POSTS