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
If you were secretly hoping that all web browsers would one day give up and adopt the WebKit rendering engine, we’ve got some bad news for you — Google just crushed those dreams.
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).
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.
The hits just keep getting killed off. Google is shutting down yet another service — the company’s domain blocking tool, which allowed logged-in users to block unwanted domains from Google’s search results.
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).
Websites are getting fatter, dramatically fatter, with the average page size of sites tracked by the HTTPArchive now nearly 1.3 MB. If the current rate of page size increase continues, that number will reach 2MB sometime early next year.
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.
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.]
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.
Google has 
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code