Archive for May, 2011

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