Archive for February, 2011

File Under: Browsers

New Chrome Add-on Blocks Sites From Search Results

Blocking a domain with Google's new Chrome add-on

Google has released a new add-on for its Chrome web browser that allows you to block domains and subdomains from search results. The new extension is aimed at so-called “content farms,” which often rank high in Google search results, but feature low quality content.

If you’d like to blacklist some domains from your search results, and you’re using the Google Chrome web browser (or Chromium), you can download the new add-on from the Chrome Web Store. Once the add-on is installed, you’ll see a new option to “block this domain” beneath each search result. To edit your list of blocked sites, just click the red hand icon in the toolbar.

The add-on is part of Google’s plan to cut down on content farm spam. Google defines content farms as “sites with shallow or low-quality content.” Often the content is written for no other reason than to show up in Google’s search results and pull in traffic. However, because content farms often have some pages of valuable content, classifying them as outright spam might not be accurate either. And of course what constitutes a “content farm” is open to debate.

In a thread about the new add-on over at Hacker News, Google’s principal engineer, Matt Cutts writes “people feel comfortable with Google removing blatant spam: hidden text, cloaking, sneaky JavaScript redirects, etc. People tend to feel less comfortable if they feel like Google is making an editorial decision.”

The new Chrome add-on turns that editorial decision over to you. Don’t want to ever see another eHow or Yahoo Answers link in your search results? Just block the domains and you’re done.

That said, the add-on is far from ideal. It only works in Chrome (or Chromium) and instead of truly removing the results, it merely hides them. That means that if the first page of results for your search contain only one result from a domain that isn’t in your blocklist, you’ll only see one result on the initial page. There is no reflowing of results. To get more than that one result, you’ll have to click through to the next page.

Ultimately the ability to block sites from Google’s search results is useful enough that it seems destined to end up on the server side — perhaps as a Google Labs experiment. Cutts says that Google started with the add-on because it was quick, but the company is working toward a server-side solution.

Cutts also says that Google is collecting the sites you block and may use them to influence search results in the future. As it stands, there’s nothing to stop a company from blocking its competitors’ sites, which is obviously a problem. Cutts makes it clear that Google is only looking at the sites people block, not actually using that information to re-rank sites.

Still, if there are sites you’d love to block from your Google search results, there’s now a way to do it — provided you use Google Chrome.

See Also:

File Under: HTML5, Web Standards

HTML5 Will Be Done in 2014, What Comes Next?

Web developers were given a green light Monday to start using HTML5.

Even though many are already using the still-unfinished language to code complicated web apps, the web’s governing body made the transition official by announcing that HTML5 will be complete by 2014.

The World Wide Web Consortium (W3C) has extended the charter of the HTML Working Group (HTMLWG) — the group charged with creating HTML5 — and announced that HTML5 will move to last call status later this year. After a couple of years of rigorous testing, the spec should be finalized by the second quarter of 2014.

“Developers can use HTML5 now and we encourage them to do so,” Ian Jacobs, head of W3C marketing, tells Webmonkey.

The web does not move at the pace of standards bodies, it moves at the pace of web browsers and innovative developers. No one, least of all the HTMLWG, expects the web to wait around for HTML5 to reach the official “recommended” status. Indeed developers are already using HTML5 and its related standards all over the web. HTML5 is here, even if it won’t be official for a few more years.

2014 may seem like a ways off, but it’s a much more promising timeline than 2022, which, despite never being an official date, is often cited as the one the W3C had originally targeted. Assuming the HTMLWG meets its goal, 2014 will mark the first official update for the HTML spec since HTML 4.01 was released in 1999.

HTML5 will give the web several new markup tags, like video and audio, the canvas element for animations and new semantic elements like header, article and aside, which give greater meaning to elements in webpages. Developers should note the 2014 date applies to the HTML5 spec only, not the associated APIs, like Geolocation or Web Workers, which are separate standards.

With a target date on the horizon, HTML5 is now entering the home stretch. Two years of testing still lie ahead, but the HTMLWG is already preparing to focus on the future — the next version of HTML.

The WHATWG, which consists of the browser makers that implement the HTML spec, recently declared its version of HTML to be a “living standard” and the group will no longer be versioning HTML (check out our guide to understand the difference between the HTMLWG and the WHATWG).

Jacobs says the W3C has no plans to follow the WHATWG’s versionless path. “Many industries need stable versions [of the HTML spec]… they require stability in the standard and very high levels of interoperability.” In other words, aiming for a moving target like the WHATWG’s version of HTML isn’t for everyone.

That means there may well one day be an HTML6, but for now the W3C is using the unofficial moniker “HTML.next.”

However, while the spec itself may eventually expand again, Philippe Le Hegaret, the interaction domain leader of the W3C, says APIs are the future. “Not everything needs to be in the spec itself,” Le Hegaret tells Webmonkey. APIs already encompass many features frequently labeled HTML5, such as the Geolocation API, offline storage API and the Web Workers API.

The advantage of APIs is that development can move at a faster pace and new technologies can be finalized individually, without waiting on other elements in the spec.

That’s good news for the future of the web, since the pace of development is only accelerating. The web is no longer something on your PC, it’s on your mobile device and it’s starting to encroach on your living room.

Whether it’s in the spec or separate APIs, both Jacobs and Le Hegaret believe that at least some of the features in future versions of HTML may well involve the collision of the web and television. Netflix, Sony and LG all recently joined the W3C and are interested in what will happen as more televisions begin to connect directly to the web.

Television on the web will likely bring a new set of requirements — possibly new tags, new APIs and a whole new platform looking to implement them. Le Hegaret says that there have already been proposals for features in HTML.next, though nothing is official just yet.

In the mean time, look for HTML5 to reach last call status later this year. From that point the only thing standing between HTML5 and the 2014 finish line are thousands of tests to ensure that HTML5 works everywhere it should.

See Also:

MPEG LA Starts the Search for VP8 patents

MPEG LA, the one-stop shop for motion video patent licenses, yesterday announced a call for patents essential to the VP8 video compression algorithm — the algorithm that is fundamental to Google’s WebM video format. MPEG LA is asking organizations that hold patents believed to cover integral, unavoidable parts of the VP8 algorithm to come forward and submit those patents to the licensing company. The patents will in turn by analyzed by MPEG LA, and those deemed to be relevant will be pooled together. The pooled patents will then be available to license as a single convenient bundle.

In its promotion of WebM and VP8, Google has insisted that all the relevant patents were developed by codec company On2, which Google purchased last year. The patents can be licensed from Google without payment of any royalties or any restrictions on usage. Google has been heavily promoting WebM for use with the HTML5 <video> tag, which allows plugin-free video to be embedded in webpages, and the royalty freedom is a key part of WebM’s value proposition.

Competitive codecs such as the open and industry standard H.264 require royalties to be paid by software and hardware developers. Companies like Opera and Mozilla, as well as the W3C group that is developing the HTML5 specification, deem these royalties be an unacceptable impediment to their usage. They have no such qualms about the royalty-free WebM.

If MPEG LA is successful in assembling a patent pool, that royalty freedom could come to an end. The company is soliciting patent submissions until March 18th. Once the submissions have been made, it will determine which patents are essential to VP8; only those patents that are unavoidable can form part of the patent pool. The owners of those selected patents will then decide on the license conditions they wish to impose, and these conditions could include royalty payments.

Whether this will happen, of course, is the big question. MPEG LA might fail to form a patent pool altogether: it may receive no relevant patent submissions, in which case the patent pool process will likely end. Such an outcome still won’t mean that WebM is in the clear — a company may feel that it’s more lucrative to avoid a patent pool and allow WebM usage to become more widespread before asserting claims — but it would probably imply that there aren’t dozens of potential claimants just waiting to come forward.

This sort of outcome might well see Microsoft’s current neutral stance towards WebM (it will work in Internet Explorer 9, just as long as a suitable third-party codec is installed) become more overtly positive. Redmond might start shipping a WebM codec of its own, for example.

If MPEG LA does form a patent pool, the license terms will be critical. MPEG LA exists to monetize patents, however, so it’s unlikely that any patent pool would permit the kind of indiscriminate royalty-free license that Google currently offers. More likely, they would choose terms similar in kind to those of H.264; Web video may be free, but decoders still incur a royalty. This would put WebM implementors in a difficult position — either drop WebM support, pay up, or risk going to court to fight a patent infringement suit.

An infringement suit is an unappealing prospect: even if you win, the drain on your financial resources can mean that ultimately, you lose. This is especially problematic for organizations like Mozilla, since Google offers no indemnification for users of WebM — if Mozilla gets sued, Google won’t step in to help. As such, the safest, most conservative option for Opera and Mozilla would be to drop support. Google has deeper pockets and can better sustain a legal attack, but even there, the company has to weigh its options carefully. A lost court case could cost tens of millions of dollars. Paying up just to avoid the problem may very well be the better option.

But paying up is problematic too. VP8 is, for most purposes, inferior in quality to H.264. H.264 is much more widespread in software tools, hardware accelerators, and so on: it’s enormously widespread already. If VP8 loses its key feature — royalty freedom — implementers may very well decide that, since they have to pay anyway, they’d be better off paying for the superior, more widely used H.264 license, and abandoning WebM entirely.

Whatever happens — and it will probably be many months before we find out — this is bad news for WebM. The formation of a patent pool directly undermines Google’s claims about the codec — and yet, even if MPEG LA fails to create a pool, question marks surrounding the codec will remain.

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

See Also:

File Under: Browsers

New IE9 Offers Geolocation, Privacy Controls and More Speed

Microsoft has released the first release candidate for its coming Internet Explorer 9 web browser. IE9 is a major overhaul, bringing much needed speed improvements, better support for web standards, privacy controls and tighter integration with Windows 7.

Overall IE9 RC1 is a huge leap forward for Microsoft, embracing web standards and speeding up the browser. When IE9 is released web developers will finally be able to stop using CSS hacks and start using HTML5 with more confidence. Of course IE8 and IE7 will still be with us for some time to come, but things are looking up.

Curious developers running Windows can download the release candidate from Microsoft. This version of IE9 expands support for semantic HTML5 elements (like <nav>, <section> and <article>), adds more CSS 3 properties and introduces support for the geolocation API.

The additional geolocation support rounds out Internet Explorer’s new HTML5 features. While IE9′s competitors have implemented some of the more experimental APIs (like Web Workers and offline cacheing), IE9 does close the feature gap considerably and is leaps and bounds beyond where IE8 left off.

When it comes to CSS 3 the new IE offers nearly full support, though it still doesn’t understand text-shadow (which is actually been around since CSS 2.1) or the new CSS 3 multi-column text layout tools. On the bright side, IE9 does render border-radius, 2D transforms and new CSS 3 selectors like :first-of-type. For a full rundown of IE9′s HTML5 and CSS 3 features, see our earlier coverage. Also, be sure to head over to the IE9 Test Drive website for some demos that show off IE9′s new standards support.

IE9's CSS 3 support handles border-radius rules

The new IE9 release candidate adds some privacy controls similar to those Mozilla and Google have been adding to their browsers. IE9 will support the Do Not Track HTTP header [Update: Microsoft says that IE9 does not support an HTTP header at the moment, but does offer Tracking Protection Lists which can block cookies, beacons, pixels and more]. IE9 also supports cookie-based blacklists to stop advertisers from tracking your movements around the web.

If you’ve been using the beta releases of IE9, you’ll notice several changes to the look of IE9, including the ability to put tabs back in their own row, rather than next to the address bar, which is the default setting. To give your tabs a bit more breathing room, just right click on the tab bar and select the “Show tabs on a separate row” option.

Top: the default tab arrangement; Bottom: tabs in their own row

This release also adds a new security feature which allows you to turn off ActiveX for all sites and then re-enable it on a site by site basis. ActiveX, a Windows-only “enhancement” that allows webpages to install code on your PC, has long been an excellent way to load up your Windows machine with viruses and other malware. The new controls mean you can turn off ActiveX entirely and avoid malicious code being installed.

Microsoft is also touting IE9′s hardware acceleration improvements in this release. According the IEblog, the release candidate is 35 percent faster than the previous IE9 beta. Indeed, in our informal testing IE held its own with Firefox 4 and Chrome 11. Pitted against stable releases like Firefox 3.6 or Chrome 9, IE9 fares even better.

Microsoft has not yet set an official release date for IE9, though the company’s web-centric MIX conference, which starts April 12, has historically been host to major IE announcements.

See Also:

File Under: Multimedia

New Flash Player 10.2 is Faster, Lighter on the CPU

Adobe has released Flash Player 10.2, an update that focuses primarily on speed and performance improvements. New in Flash 10.2 is something Adobe calls “Stage Video hardware acceleration,” which the company claims will “decrease processor usage and enable higher frame rates, reduced memory usage, and greater pixel fidelity and quality.”

The Stage Video hardware acceleration means that Flash Player 10.2 can leverage your graphics card for not just H.264 hardware decoding (which works in Flash Player 10.1) but also color conversion, scaling, and blitting.

To try out the new Flash Player 10.2 beta, head over to the Adobe download page. If you’re using Google Chrome, which bundles Flash Player with the browser, look for an update to arrive in the near future.

The Flash Player 10.2 beta gave us mixed results when it came to speed and the final release is no different. Windows users will see the biggest speed bump, particularly with 1080p video that has been optimized with the Stage Video hardware acceleration. Mac users will need to be on OS X 10.6 Snow Leopard in order for Stage Video to take advantage of hardware acceleration.

For the beta I ran some test on the Mac platform (using Firefox and Chromium) using several 1080p videos on YouTube. The beta put CPU usage down to the 18-22 percent range, but the final release tops that, rarely climbing over 12 percent CPU use. On Windows (again in Firefox and Chromium) the story is even better, with the numbers hovering in the low single digits.

That’s good news for watching Hd video online, but it also means less drain on your laptop’s batteries, one of the main complaints leveled at Flash Player. Keep in mind though that in order to take advantage of the new Stage Video tools, sites like YouTube and Vimeo will need to alter their video players. So, it may be some time before the full benefit of Stage Video’s improvements makes it to your day-to-day web browsing.

Other new features in Flash Player 10.2 include support for fullscreen mode with dual monitors — meaning that you can have a movie on one screen and keep working on another — and some sub-pixel text rendering improvements which should make Flash text more readable.

As for Flash Mobile, where the benefits of lower CPU usage and less battery drain are even more welcome, Adobe says to “hang tight.” Adobe plans to talk about new versions of Flash Player for Mobile at the Mobile World Congress next week.

See Also:

Gawker Learns the Hard Way Why ‘Hash-Bang’ URLs are Evil

URLs are an often overlooked part of web design, yet in many ways they may be the most important aspect of your website as Gawker’s family of sites recently discovered.

Gawker recently launched a multi-site redesign that, no sooner than being unleashed on the web, failed spectacularly, leading visitors to blank pages. The culprit was a misbehaving piece of JavaScript, but when a single line of JavaScript causes your entire suite of sites to fail you no longer have websites, you have, well, nothing.

The problem with Gawker’s redesign is that it uses JavaScript to load everything. That means that, not only is there no chance for the site to degrade gracefully in browsers that don’t have JavaScript enabled, the smallest JavaScript typo can crash the entire website.

Developer Mike Davies has a nice breakdown of why Gawker’s JavaScript-based hash-bang URLs are a bad idea. Originally designed to allow Google’s spider to crawl Ajax content, hash-bang URLs have been popping up all over the web — Twitter and Facebook use them as well — but that doesn’t make them a good idea.

As Davies writes:

the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.

And today, this emergency rescue package seems to be regarded as the One True Way of web development by engineers from Facebook, Twitter, and now Lifehacker.

The problem in Gawker’s case is that the URLs no longer point to actual content, everything depends on JavaScript parsing the hash-bang to retrieve the content. As Davies writes, “if content cannot be retrieved from a server given its URL, then that site is broken.” Think of hash-bang URLs as a worst practice of URL design.

If you’d prefer not to hang your site’s fate on the most brittle part of the open web stack — JavaScript — make sure you have a publishing system that allows you to design your own URLs and then follow the established best practices for creating good URLs.

If you’ve got Ajax content that would otherwise be missed by Google, then by all means use the hash-bang syntax, just keep in mind that the hash-bang is basically a hack, not the cornerstone of a well designed URL.

Eat at URLs photo by Scott Schiller/Flickr/CC.

See Also:

File Under: Browsers, Programming

Test Your Websites With ‘OperaWatir’

You can never run too many tests, especially when it comes to making sure your website is working properly in every web browser. But with a variety of browsers to test in, making sure everything is running smoothly takes time. That’s where Watir (pronounced “water”) comes in.

Watir is a set of open source Ruby libraries for automating web browsers to crawl and test your site. Watir essentially “drives” a web browser the same way your visitors would — clicking links, filling in forms, pressing buttons and so on. Because everything is automated you can test your site thoroughly and quickly.

Opera’s effort, dubbed OperaWatir, is the latest addition to the Watir test suite and joins the tools already available for Internet Explorer, Firefox and WebKit-based browsers. If you’re already using Watir for writing test suites (and you should be if you’re not) OperaWatir means that you can now test across all major browsers.

If you’ve never used Watir before, the Opera Dev Center has a nice tutorial on writing Watir tests tailored to your site. Opera’s tutorial walks you through the Ruby code necessary to automate common actions like clicking buttons, issuing keyboard commands and how to use the sleep command to handle Ajax refreshes.

The second part of Opera’s announcement is OperaDriver, the backend of OperaWatir that communicates with the Opera browser. While OperaWatir is written in Ruby, OperaDriver is written in Java, and it allows developers to create automated tests using the Java-based JUnit testing framework. If you’re not a fan of Ruby, OperaDriver can do the same things using Java.

See Also:

File Under: Browsers, Identity

Firefox 4 Beta 11 Offers ‘Do Not Track’ Privacy Setting

Firefox 4 goes to eleven. Mozilla has released an eleventh beta of Firefox 4, the next major version of the browser. Beta 11 includes the usual bug fixes and speed improvements, but it also has a new feature — the “Do Not Track” setting Mozilla is hoping will become a standard.

If you’re already using Firefox 4 you should be automatically updated. If you’d like to help Mozilla test Firefox 4, head over to the beta downloads page and grab a copy of beta 11.

The Do Not Track feature is a new HTTP header that will stop behavioral advertising tools from tracking where you go on the web. To turn on the new feature just check the box under the Advanced tab in Firefox 4′s preferences.

For now all you’ll be doing is broadcasting the new header information; it won’t actually have any effect. Because no online advertisers yet support the header, the new feature won’t protect your privacy. However, some of the biggest names on internet advertising already voluntarily offer a cookie-based opt-out system and it seems likely that, with Mozilla behind the new header, the same companies will support the new option eventually.

Mozilla is planning to release at least one more beta and then a round of release candidates before Firefox 4 is finalized later this year.

See Also:

Google Transforms Logo into Jules Verne’s ‘Nautilus’

Google is celebrating Jules Verne’s birthday with a logo that pays homage to the author’s famous 20,000 Leagues Under the Sea. The doodle, which marks Verne’s 183rd birthday, transforms the usual Google letters into submarine portals looking out at the sea.

The effect was created using the powerful transform tools in CSS 3 to layer together an animated diving sequence using nothing more than standard HTML and a few transparent images. If you’ve got a device with an accelerometer built-in (any iOS device, recent Macbook or Android device), you can even control the doodle just by tilting down to dive or side to side to move forward and back.

If you’re on a desktop or don’t have an accelerometer in your laptop, you can steer the Nautilus with a control stick. While the doodle worked in most browsers, it’s smoothest and fastest in Google Chrome and Firefox 4 beta.

Other Google doodles have used HTML5′s canvas element, along with some CSS 3, to create the bouncing balls experiment and the awesome, playable version of Pac-Man.

See Also:

File Under: Browsers, Multimedia

Chrome 9: Faster 3-D Graphics, Instant Search and an App Store

Google has updated the stable channel of its Chrome web browser. This release is technically labeled Chrome 9, though Google ceased focusing on version numbers some time ago, opting for a rolling, every-six-weeks update schedule.

If you’d like to take the latest version of Chrome for a spin, head over to the Chrome downloads page. If you’re already using Chrome, the update will arrive automatically.

If you’ve tested the beta release of Chrome 9, there won’t be anything new to see in this update. But for those that prefer to stick with the stable channel, Chrome 9 brings several features from the beta channel to prime time — notably, support for 3-D WebGL hardware acceleration. This release also adds support for the new Chrome Web Store, and Chrome Instant, a tool that loads web pages as soon as you start typing in the URL bar.

WebGL, which was originally developed by Mozilla, acts as a bridge between the browser and the desktop hardware acceleration tool OpenGL. The WebGL project gives web developers a way to connect the HTML 5 Canvas tool, which can be used to display complex graphics in the browser without plug-ins like Flash, to the operating system’s native, hardware accelerated graphics engine — in this case, OpenGL. The result is much improved performance for 3-D apps on the web. Google notes a couple of demos you can try out, the Google Body experiment in particular does a nice job of showcasing the power of WebGL.

This release is also notable for being the first stable version of Chrome to include access to the new Chrome Web App Store (U.S. users only). To check it out, just click the new link on the New Tab page.

Chrome Instant mimics Google’s instant search feature when you type a search in the URL bar. If you type a web address, Chrome Instant will start loading the page as you type, which makes getting to your favorite sites a bit faster. The only catch is that Chrome Instant is disabled by default. To turn it on, head to the “basic” tab on Chrome’s preferences page and check the “Enable Instant” option under Search.

See Also: