As with the desktop release, the Android release is light on new features, but it does add support for themes and, more importantly, lowers the CPU requirement for Firefox on Android to 600MHz.
The lower CPU requirements open up the possibility of running Firefox on a few more Android devices, though keep in mind that Firefox still requires Android 2.2 or better. You can peruse the full list of known supported devices to see if your older Android device is on the list.
Web developers will be happy to note that the same updated standards support found in today’s desktop release — namely support for @page, full width text transforms and the new viewport percentage units like vh, vw, vmax and vmin — is also in the mobile version.
For a list of everything that’s new in Firefox 19 for Android, as well as a list of bugs and issues that remain, check out Mozilla’s release notes.
Mozilla has released Firefox 19, which features a few modest improvements including a built-in PDF viewer, faster startup times and support for some new web standards.
Firefox users will be automatically updated to the latest version. If you’d like to take Firefox for a spin, head on over to the downloads page.
The biggest news in Firefox 19 is the new, baked-in PDF viewer based on PDF.js. It may not mean the end of those annoying (and untrue) buttons that say “you need Adobe Acrobat to view this file,” but at least you don’t, well, need Acrobat just to view a PDF.
This release will also be a welcome update for anyone who’s ever double-clicked on Firefox, seen nothing happen, double-clicked again and so on until Firefox suddenly comes to life with twenty blank pages open. As of Firefox 19, the browser will not execute any code before the initial window is made visible, which means you click Firefox and you see an open window much faster.
While there are not many new features in Firefox 19, web developers do get some love with support for several new CSS features, including @page, full width text transforms and the new viewport percentage units like vh, vw, vmax and vmin — handy for sizing elements or adjusting type based on viewport size. Just don’t try to use vh and the like with @page because the W3C still hasn’t quite settled how that will work.
For a full list of all the other smaller changes and bug fixes in Firefox 19, check out Mozilla’s release notes.
WebKit: not actually one ring, but many, many rings. Image: Screenshot/Webmonkey
Opera software is abandoning its homegrown rendering engine in favor of the open source WebKit rendering engine. Many developers seem to think this means one fewer browser to test in, but unfortunately, that’s not the case.
The problem with the dream of less testing because there’s more WebKit is that “WebKit” can mean many things. The WebKit in Safari does not have all the features you’ll find in the WebKit that powers Google Chrome. The situation gets even more complicated with mobile where there are about as many different versions of WebKit as there are browsers.
As Mozilla’s Rob Hawkes and Robert Nyman point out in the post WebKit: An Objective View, that means “each browser will still have its own quirks, performance differences, design, and functionality. These should all be tested for.”
Worse, individual WebKit browsers can pick and choose which APIs to include in their final builds, which means just because something is available in WebKit, does not mean it’s available in, for example, both Chrome and Safari. Couple this with Safari’s relatively slow release schedule and just the two major desktop WebKit variants are going to require testing to make sure everything works.
Throwing a WebKit-based Opera in the mix just means another WebKit browser that needs to be part of your testing.
There’s nothing wrong with this state of affairs, nor will it change all that much when Opera is on WebKit as well, but it won’t mean less testing, nor is it going to make web developers’ lives any easier (especially since most of them weren’t testing in Opera anyway).
Testing will always be a necessary part of web development, but the danger that Hawkes and Nyman foresee is that developers will test less because they assume that if something works in one version of WebKit it will work in all of them. While that hasn’t happened yet, the CSS prefix debacle certainly doesn’t bode well for the WebKit-heavy future.
For all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine, mirroring what you’ll find in Google’s Chrome browser. Apple’s Safari also uses WebKit, though it has its own JavaScript engine.
Writing on the Opera Developer Blog, Opera’s Bruce Lawson says the first WebKit-based Opera browser “will be for smartphones, which we’ll demonstrate at Mobile World Congress in Barcelona at the end of the month.”
While Opera’s desktop market share hovers around 2 to 4 percent, the company’s two mobile browsers have, until very recently, been the most used mobile browsers on the web.
Indeed, while Opera’s official announcement is vague about the reasons for the switch, it doesn’t take a soothsayer to know that the reason is mobile. One influencing factor is no doubt the fact that Apple’s iOS only allows third-party web browsers if they use the built-in WebKit rendering engine.
CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way. In fact, web developers fell in love with the -webkit prefix and often forget that there are other prefixes as well: -o for Opera, -moz for Firefox and -ms for Internet Explorer.
Using only -webkit means sites break in Opera even though Opera could have rendered the site just fine if the developer had bothered to include the -o prefix.
Of course, as Mozilla’s Christian Heilmann points out, “content not showing up or showing up broken in your product is terrible for a commercial company — the web is never wrong, if your browser shows it wrongly it is your fault, right?”
It would always be Opera’s fault in the eyes of most users and that’s why the company decided to support the -webkit prefix last year. In many ways today’s announcement is just one step further — if you’re going to support the prefix, why not just use the rendering engine? That seems to be exactly what Opera has decided to do.
So what becomes of the Opera features you know and love? The DragonFly developer tools are most likely done for, WebKit already has its own developer tools. It’s less clear what might happen to Opera’s other unique features like the built-in e-mail client or Opera Turbo, which compresses webpages to give broadband-like speeds on almost any internet connection.
An Opera spokesperson declined to comment on the future of any Opera features, telling Webmonkey only that “compression is in Opera’s DNA, but other than that we don’t talk about features of unreleased products.”
While I’m optimistic about Opera’s WebKit future, it’s hard to see the loss of a rendering engine as anything but bad news for the web. One less rendering engine means one less way to discover and fix bugs in web standards, one less place to see what you’ve done wrong. And Opera, while sometimes difficult to test in, was almost always right when it came to implementing web standards. In 13 years of building websites I’ve found no other testing environment in which I knew that if something didn’t work, it was almost certainly my code that was wrong. And I’m not alone; apparently even some Chromium developers feel the same way.
But that won’t stop developers who’d like to see a monoculture of WebKit from shortsightedly cheering this news.
Mozilla developer Robert O’Callahan summarizes why a WebKit-centric web is not a good thing:
some people are wondering whether engine diversity really matters. ‘Webkit is open source so if everyone worked together on it and shipped it, would that be so bad?’ Yes. Web standards would lose all significance and standards processes would be superseded by Webkit project decisions and politics. Webkit bugs would become the standard: there would be no way for developers to test on multiple engines to determine whether an unexpected behavior is a bug or intended.
WebKit makes a fine rendering engine and it does a good job of keeping up with web standards, but don’t assume that just because a web browser uses WebKit under the hood that it will render your pages the same as every other WebKit browser. Just look at the rendering and feature differences between Chrome, Safari, Mobile Safari and Mobile Chrome to get a sense of the pain that awaits developers yearning for a WebKit monoculture.
The other possible downside to a WebKit Opera is that the company’s once mighty voice for standards may not be heard as clearly amid the Google- and Apple-dominated WebKit developer culture.
Hopefully the WebKit community will find a place for the developers who brought us tabbed browsing, mouse gestures, “Speed Dial”, Turbo, and an uncompromising support for web standards that made Opera one of the first browsers to pass both the ACID 2 and ACID 3 page-rendering tests. For its part Opera is starting off on the right foot, offering up code that brings Presto-quality support for the CSS Multi-column Layout Module to WebKit.
Hopefully Opera engineers will continue to bring the same kind of innovation to WebKit and Chromium as they did to Presto and with any luck WebKit will listen and the web will end up a better, if less diverse, place.
IE 10 for Windows 8 has been out for months and there’s a preview version available for Windows 7, but so far Microsoft has not officially released an IE upgrade for Windows 7 users.
That’s likely to change in the very near future given that the company has released an IE 10 Automatic Update Blocker Toolkit for businesses and organizations that don’t want to upgrade to IE 10. Naturally the only reason you’d need to block IE 10 is if it is in fact finally coming to Windows 7.
There’s a second piece of good news for web developers in this announcement, namely that Microsoft is planning to automatically upgrade IE 9 users to the much more web standards-friendly IE 10 (except of course for those users who download the newly released blocking toolkit).
While IE 10 is a fine web browser, Microsoft’s track record for getting customers to actually update to the latest versions of its software is, well, terrible. And that’s the real problem most developers have with IE 10: It’s not that it isn’t a good browser with impressive support for web standards, what worries web developers is that there’s always the chance that it will be left to rot for 10 years like IE 6.
Hopefully, given Microsoft’s push to automatically upgrade Windows 7 users to the latest IE release, that won’t be the case.
Mozilla has released Firefox 19, which features a few modest improvements including a built-in PDF viewer, faster startup times and support for some new web standards.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code