Viewing MS Office docs in Chrome. Image: Screenshot/Webmonkey

Google Chrome OS users have long enjoyed the ability to open Microsoft Office documents right in the web browser. Now Google is expanding its MS Office support to include Chrome on Windows and Mac as well.

The new Office Viewer beta is an extension for Google Chrome. You’ll need to be using Chrome 27 or better (currently in the beta channel), but provided you’re willing to use the prerelease version, you can install the new Office Viewer (also a beta release) from the Chrome Store.

The new extension can open most Microsoft Office files including .doc, .docx, .xls, .xlsx, .ppt, .pptx. The interface is very similar to the existing PDF view in Chrome and comes from QuickOffice, which Google acquired last year.

The main downside to the new plugin is that it’s definitely still a beta — very buggy and rough around the edges. In my testing two very simple spreadsheets simply didn’t open and selecting text in .docx Word documents was hit or miss; sometimes it worked, other times it was as if the document had been converted to an image.

On the plus side your MS Office files open in a specialized sandbox which protects you from any malware and viruses lurking in the files.

Still, there are enough rough edges that Chrome’s Office plugin isn’t ready for prime time. While it’s a necessity on Chrome OS, which has no Microsoft Office suite, everywhere else you’re probably better off using Google Drive to view files when you’re online (assuming you want to use Google services, Zoho Docs works well if you don’t), and Microsoft Office or Open/Libre Office when you’re not.

Google has updated the stable channel of Chrome for Android to Chrome 26, which offers two new syncing features designed to save you a bit of time on mobile devices.

You can grab the latest version of Chrome for Android from the Google Play Store.

This release has two noteworthy features — password syncing and form autofill syncing. Keeping track of passwords is a pain and let’s face it, most mobile password managers leave much to be desired. With the new Chrome for Android you can sync and access your saved passwords across devices.

Even if you prefer not to have Chrome store your passwords for you, the form autofill syncing is equally handy — especially given how tedious it can be to fill out forms using your mobile device’s tiny keyboard.

Like all of Chrome’s syncing features, you’ll need to be signed into your Google account to use the new password and autofill sync.

This release also fixed a few bugs and offers some modest performance and stability improvements. For more details, see the Chrome blog.

Most likely you’ll go your way and I’ll go mine. Image: sacks08/Flickr

Google has announced it is forking the WebKit rendering engine to create Blink, a new rendering engine for all Chromium-based web browsers — notably Chrome, Chromium, Opera and their mobile counterparts.

Blink will make its web debut in Chrome 28 (and Opera 14). Based on Google’s Blink FAQ and initial announcement, expect Blink to diverge significantly from the WebKit project.

That means web developers will soon be back to testing their sites in both Chrome and Safari. Of course, as has been pointed out in the past, there have always been enough significant differences between the two that you should have been testing in both anyway.

Among the good news in the announcement is Google’s decision to not use CSS prefixes for new features. Instead Blink will follow Firefox’s lead and use flags to enable experimental features. That means developers can test and use new features by setting the appropriate flag in about:flags. Blink will carry over support for all currently existing -webkit- prefixes, but will be removing the prefixed features in favor of the unprefixed rules as soon as it is safe to do so.

The other good news is that there are once again four major rendering engines on the web.

As much as web developers might like to see the web have a single rendering engine that all browsers use, that sort of monoculture doesn’t lead to a healthy web. It’s interesting to note that Google’s fork appears to be motivated by this very problem, albeit from a browser maker’s angle — the sheer number of projects using WebKit meant development wasn’t moving fast enough for Google.

Adam Barth, Software Engineer at Google, writes on the Chromium blog that Google’s decision to fork WebKit was “not an easy decision.” But Google believes that “having multiple rendering engines — similar to having multiple browsers — will spur innovation and over time improve the health of the entire open web ecosystem.”

Google has outlined a new policy regarding experimental new features that differs significantly from WebKit’s here’s-a-new-feature-just-ship-it policy. Blink will instead limit new features to those that have at least been proposed as standards and preferably already have at least one other implementation. In those cases where WebKit is the source of a new feature, Google has pledged to “propose an editor’s draft (or equivalent) to the relevant standards group” and “discuss the feature publicly with implementers of other browser engines.”

For web developers little will likely change in the sort term. The first browsers with Blink at their core will not be on the web for some months and when they do arrive they will at first differ little from WebKit. The longer term picture will likely look pretty much like the web before Opera killed off its Presto rendering engine last month — four major browsers with minor differences between them that require testing to ensure total support.

There’s also the question of what happens to the WebKit project. Google has been one of the driving forces behind WebKit for some time. Now those contributions are gone and it’s up to other WebKit supporters — Apple, BlackBerry and Samsung, among others — to pick up the slack (with Samsung joining in Mozilla’s next-gen rendering engine project it’s unclear exactly how much commitment Samsung has to WebKit).

For more background on the Blink announcement, see Google’s FAQ. For one of the best all-around, unbiased looks at what Blink means for the web, see Peter-Paul Koch’s write-up over on the QuirksMode blog.

Google has updated the stable release of its Chrome web browser, adding a much-improved native spell check and word suggestion features.

The new versions are live for Windows, Linux and Chrome OS. Google says it is “still working on Mac support” (Chrome for Mac has been updated to v26, but it does not yet contain the new spell checker).

To use the new spell checking feature, turn on the new “Ask Google for suggestions” option which you’ll see when you right click any highlighted misspelling. The new spell check also does some grammar checking and recognizes proper nouns (especially people’s names, handy for composing email) and homonyms.

Chrome 26 also sports a new personal dictionary. If the spell-checker keeps underlining a word you want it to ignore, just right-click the word and select “Add to dictionary.” If you’re signed in and syncing your data through your Google account your dictionary additions will go with you.

Image: THOR/Flickr

Google’s site-blocking tool was originally aimed at “content farm spam,” but Google hasn’t done much with it of late, and it even stopped working for a while, despite being available via a link from your profile.

Now the service is officially gone, replaced by a Chrome add-on that does nearly the same thing. Unfortunately that means the ability to ban sites from Google’s search results is now limited to those using Google’s Chrome web browser. For more on the Chrome add-on see our earlier review.

The bad news about the Chrome extension is that it’s client-side filtering, not server-side. That means that if Google returns results from domains you’ve blocked those results are simply hidden (sometimes there’s even a brief flash of the blocked results).

That means you’ll end up with fewer search results than you would with the server-side solution, which filtered out your blocked domains before the results were sent. For example, if there are ten results on the first page and three are from domains you’ve blocked, using the add-on method you’ll only see seven results, whereas the server-side method would have fetched the next three results to show a total of ten.

If you used the account-based version of the blocking tool, you can head over to your account and grab the list of sites you had blocked. Just add those sites to the Chrome extension and you’ll be back up and running in no time, with not an Experts-Exchange, Quora or W3Schools link to be seen (or whatever you consider search results spam).

Home Page Photo: Carlos Luna / Flickr

Stop feeding your website donuts. Image: D. Sharon Pruitt/Flickr.

That’s bad for pretty much everyone, but doubly so for mobile users with constrained bandwidth.

Fortunately for mobile users, the network increasingly seems to see large page sizes as damage to route around.

Services like Instapaper, Pocket or Safari’s Reader have long offered an easy way to strip out extraneous content. Now mobile web browsers are increasingly taking it upon themselves to speed up the bloated web.

The recently unveiled WebKit-based Opera Mobile borrows Opera Mini’s proxy-based Turbo Mode, or “Off Road” mode as it’s known now. Once only deemed necessary for feature phones (Opera Mini’s primary market) proxy-based browsing will soon be available in all Opera browsers.

Google’s Chrome for Android browser is getting ready to follow suit.

The beta channel release of Chrome for Android recently introduced an experimental data compression feature which Google says will “yield substantial bandwidth savings.” Chrome’s compression is nowhere near the level of Opera’s, but it does roughly the same thing — puts a proxy server between the user and the bloated site in question and then applies various speed improvements like using the SPDY protocol and compressing images with WebP.

To turn on the compression head to chrome:flags and look for the “enable experimental data compression” option.

Here’s Google’s description of the various optimizations:

For an average web page, over 60% of the transferred bytes are images. The proxy optimizes and transcodes all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy also performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which are not essential to render the page. These optimizations, combined with mandatory gzip compression for all resources, can result in substantial bandwidth savings.

In other words, Google and Opera are doing what web developers ought to be doing but aren’t. Just like developers should have been making reader-friendly pages, but weren’t, so “reader” modes were born.

It works too. In the video embedded below Google’s Pete Le Page shows how Chrome’s new proxy options take a page from The Verge and reduce it from a husky 1.9MB to a still fat, but somewhat better 1.2MB.

Want to make sure the internet doesn’t see your site as damage it needs to route around? Check out developer Brad Frost’s article Prioritizing Performance in Responsive Design, which has a ton of great advice and links, including what I think is the most important thing developers can do: Treat Performance As Design. In other words, if your site isn’t svelte and fast, it’s not well designed no matter how pretty it might look.

[Note: It is not ironic to post about web page bloat on a page that is, arguably, pretty bloated.]

Webmonkey.com in the latest Chrome for Android Image: Screenshot/Webmonkey.

Google has released a major update to its Chrome for Android web browser.

The latest version of Chrome for Android — available in the Google Play Store — features an updated version of Google’s V8 JavaScript engine, which has finally been optimized for mobile devices. That means Chrome for Android should now be faster than the old, stock Android web browser.

According to Google, the latest version of Chrome for Android improves on Google’s Octane benchmark tests by 25 percent on average. While benchmarks aren’t always the best indicators of real-world performance gains, the speed boost should mean that JavaScript-heavy pages like Gmail or Facebook load a bit faster.

Our friends over at Ars Technica put the latest version of Chrome for Android through the paces using not just Google’s own Octane test, but the Sunspider and Kraken benchmarks as well. The results don’t always feature quite the speed improvement that Google claims, but this is without a doubt the fastest version of Chrome for Android yet.

The performance improvements aren’t just in JavaScript either. Scrolling webpages is much smoother and, most noticeable in my testing, pinch-to-zoom is much more responsive with none of the stuttering and lag that marred previous releases.

Other nice improvements include the ability to keep web audio playing even if you switch to another app (handy for music streaming sites), and support for coming web standards like CSS Filters.

Google has also released an update for Chrome on iOS, though the changes on the iOS side are largely cosmetic. Apple’s App Store policies prevent Google from including the V8 engine in Chrome, so iOS users won’t see any speed improvements. There are however a few design tweaks, like a unified search/URL bar and a quick way to see the entire history of a tab by holding down the back button.

Google’s Ro.me experiment running in Chrome for Android. Image: Screenshot/Webmonkey

If you’ve already installed the beta channel of Chrome for Android you’ll be automatically updated to the latest release. If you’d like to try it out, head over to the Google Play Store (unfortunately, searching the Play Store for “Chrome Beta” doesn’t work). It’s worth noting that Chrome and Chrome Beta install as two different apps.

WebGL is a JavaScript API for adding hardware-accelerated 2-D and 3-D rendering to the HTML5 Canvas tag. It’s the cornerstone of many sophisticated animations on the web — think cutting-edge games or interactive videos like Google’s earlier Ro.me experiment.

The WebGL API is based on OpenGL, a desktop graphics standard, which means WebGL can run on many different devices — your laptop, your phone, even your TV. That said, older Android phones will likely be a disappointment when it comes to rendering complex WebGL animations.

The latest Chrome for Android Beta gives users access to chrome://flags, a hidden menu page that allows interested developers to run experimental features. Head to that address and scroll down to find the option to turn on WebGL.

Other handy developer tools in chrome://flags include an FPS counter, which shows a page’s frame rate, CSS Shader support and the same experimental WebKit features option you’ll find in the desktop release of Chrome.

It’s not perfect, but Google’s voice transcription demo is impressively fast. Image: Screenshot/Webmonkey.

Forget touchscreens; the input device of the future is your voice. So far there’s no need to worry about HAL 9000-like web browsers taking over your laptop, but Google is hoping to bring speech recognition to the web.

The latest beta version of Google’s Chrome web browser has added preliminary support for voice commands, improving on the tools that shipped back in Chrome 11. That means you’ll soon be able to browse the web, dictate e-mails or, in Google’s strange vision of the future, “have a freestyle rap battle,” all without touching a mouse, trackpad or screen.

In fact you can try dictating an e-mail today, just make sure you’ve got the latest beta channel release of Chrome installed and head over to the e-mail demo page. The demo will also work with the new beta channel for Android release, which means that, between this and Android’s Voice Actions, Android users will soon be able to do just about everything by voice command.

Of course, as with any speech-to-text transcription, mistakes happen and eventually you may end sounding like you said “all your base are belong to us.” In the screenshot you can see that Chrome twice gets the word “entity” wrong, but even with some mistakes the real-time transcription is impressive.

The backbone of the demo is Google’s Web Speech API, a JavaScript API that allows web developers to easily integrate speech recognition into their web apps. In the case of Chrome that means you send the voice input over to Google’s servers and get back the transcribed text which you can then use in your app. See the HTML5Rocks blog for more detail on how to create a simple textfield demo. You can see the code behind Google’s demo over on GitHub.

Right now the Web Speech API is just a webkit feature, though a W3C Community Group has worked on a standards proposal. From a W3C Community Group the proposal could move to a Working Group that would then start working on an actual specification — all of which may or may not actually happen — but at the moment it’s a non-standard, though impressive feature.

Chrome for Android beta channel. Image: Scott Gilbertson

Starting today, you can install a beta channel release of Chrome for Android on any device running Android 4.0 or better. Note that it appears that you need to follow that link to get the beta channel release. Searching in the Google Play Store did not show the beta channel. The beta channel can be installed alongside the normal release channel.

The current release for the beta channel is Chrome 25, which is a significant update for the mobile version of Chrome, adding support for the new CSS Flexible Box Model syntax, dynamic viewport units (useful for responsive designs) and CSS calc(). The Android version of Chrome also gets the same updated IndexDB and CSS Filters support we looked at in the desktop release.

The beta channel release should also be a bit faster. The Chromium blog claims that improvements to the V8 JavaScript engine give the browser a 25 to 30 percent improvement on Google’s Octane benchmark tests.

The beta channel for Android offers some new tricks in Chrome’s developer tools, notably “big improvements in measuring your mobile performance with the Timeline’s frames mode.” Google also says it’s easier to navigate and edit your active scripts in the revamped Sources panel.

For more details on everything that’s new in the beta channel of Chrome for Android be sure to read through the Chromium blog’s announcement.