Dec32010
File Under: CSS

Why Percentage-Based Designs Don’t Work in Every Browser

Here’s a rule any web designer can live by: Your designs don’t need to look exactly the same in every browser, they just need to look good in every browser.

It’s a maxim that will spare you many a hair-pulling hour. That said, there some things you would expect to be the same across browsers that aren’t. One such problem that’s likely to crop up more often as designers jump on the responsive, flexible-width bandwagon is percentage-width CSS rules.

According to the spec, browsers, given a percentage width, would simply render the width of the page based on the size of the container element. And, in fact, that’s what browsers do, but how they do it varies quite a bit. As a result, percentage-based widths are often displayed quite differently across web browsers.

Developer Steffan Williams recently ran into this problem when trying to create a percentage-based version of his Gridinator CSS framework. Williams created a container <div> with a width of 940 pixels and then wanted to create a 12 column grid within that container. Do the math and you end up with columns set to a width of 6.38298 percent.

Pull that up in Firefox or Internet Explorer 6/7 and you’ll see what you expect to see. In Safari, Chrome and Opera, however, you’ll see something different. IE 8 and 9 are also slightly off.

The problem is not a new one; developer John Resig pointed this out years ago. But as Williams notes, it’s odd that browser behavior when rendering percentage-width grids is still so inconsistent across vendors, especially given how much today’s browsers tout their CSS 3 support.

The problem isn’t necessarily a simple case of Firefox and IE being right and the others wrong. As Opera CTO and CSS creator Håkon Wium Lie tells Webmonkey, the problem is “the CSS specification does not require a certain level of precision for floating point numbers.”

This means browsers are free to round your carefully computed percentages up or down as they see fit. According to Lie, Opera considers the result of Williams’ experiment to be a bug. Same with the WebKit project, the engine that handles rendering in both Safari and Chrome, though in Webkit’s case the bug has been unassigned since 2006. But really, there is no right or wrong here, just different ways of rounding.


Continue Reading “Why Percentage-Based Designs Don’t Work in Every Browser” »

Dec32010
File Under: Browsers

Chrome 8 Offers Built-in PDF Tools, Security Fixes

Staying on track with its rapid-fire, six week release cycle for its web browser, Google has pushed out the final version of Chrome 8. The latest release packs in some 800 bug and security fixes, as well as a new inline PDF viewer.

If you’re using the stable, everyday version of Chrome, you should be automatically updated to Chrome 8. If you’re using another release, or would just like to give Chrome a try, head over the Google Chrome download page.

The new, built-in PDF viewer means that when you click on a link to a PDF now, Chrome will no longer download the file to your PC. Instead, Chrome will offer a preview in the browser where you can view and search the document. Also, thanks to the sandboxing model, this decreases the chance of malicious code, malware or anything else bad being delivered through the PDF. Of course, if you then decide to download the file, Chrome won’t protect you from anything that might be lurking inside.

The PDF reader joins Flash in the list of things that Chrome manages for you. That means Google can push out updates and security fixes as needed to these components of its browser, rather than relying on users to update plug-ins themselves. You can disable the PDF viewer (or any other plug-in) by navigating to about:plugins inside Chrome.

Chrome 8 is also the first version capable of connecting to the Chrome Web Store. Although there’s nothing to see at the moment, Google is planning to release a store similar to the Android Marketplace or Apple’s App Store, but with a focus on web applications, Chrome extensions, and Chrome themes.

See Also:

Dec22010
File Under: Browsers, Web Services

Xmarks Lives: LastPass Buys Downtrodden Bookmark Syncing Service

Just when we all thought we’d never see it again, the cross-browser bookmark syncing service Xmarks has received a life-saving injection.

The company has been acquired by LastPass, maker of a cross-browser password manager and form filler add-on. The deal was announced Thursday, and terms were not disclosed.

Xmarks will live on as a freemium service. The initial cross-browser syncing tool you’re already familiar with will be free, but users will be encouraged to upgrade to a paid subscription to unlock more advanced features. It’s the same model employed by LastPass for its own Premium version of its (otherwise free) password-syncing service.

Xmarks Premium will be offered for $1 per month ($12 per year) and it comes with some new features like apps for the iPhone and Android phones, and technical support. You will also be able to bundle the premium offerings from LastPass and Xmarks together for $20 per year.

There’s already an iPhone app for Xmarks, and the company just recently released an Android app, too. Xmarks says anyone currently using the iPhone app can continue to use it without upgrading to the premium service, but they will have to buy in to the $12 per year plan to get future upgrades.

It looked like curtains for Xmarks in September, when the company announced it would shut down its service in early 2011.


Continue Reading “Xmarks Lives: LastPass Buys Downtrodden Bookmark Syncing Service” »

Dec12010
File Under: Browsers, Multimedia

Chrome Browser to Start Sandboxing Flash Player

The latest developer channel release of the Chrome browser now supports sandboxing for Adobe’s Flash Player on Windows 7, Vista and XP.

This feature should provide extra protection against malicious browser exploits through the Flash Player. The dev channel releases of Chrome on Windows already support sandboxing for HTML rendering and JavaScript execution, two of the most common paths people can use to run malicious code on an unsuspecting user’s machine. Sandboxing keeps these sensitive parts of the browser more secure while still allowing web pages and apps to access the other, less-sensitive parts of the browser.

Windows users on the dev channel should see the update arrive automatically. We should note that the sandbox does have some bugs and may break other parts of the browser — this is a developer release, after all. Once the kinks are ironed out, all of these sandboxing features will begin making their way into proper stable Chrome releases.

Google’s Chromium team has been working with Adobe to build better Flash controls into Chrome, and to utilize Chrome’s sandboxing technology for the plug-in. Google says Wednesday’s update makes Chrome the only browser on XP that sandboxes Flash. For more about sandboxing and how Chrome is implementing it, read the overview post on the Chromium blog from October. Also, Wednesday’s release comes less than a month after Chrome introduced click-to-play controls for Flash and other plug-ins.

Adobe’s Flash Player is the most widely-used browser plug-in on the web, and it’s the dominant choice for video playback and games online. Even so, the technology gets beat up for performance issues and its security shortcomings, and it’s still falling out of favor among standards enthusiasts who are pushing HTML5 as the better solution for displaying multimedia in the browser.

Adobe also released a new beta version of the Flash Player on Wednesday that improves some of its performance issues.

See also:

Dec12010
File Under: Multimedia

New Flash Player 10.2 Goes Easy on the CPU

flash logo[Updated, see below] Adobe has released the first beta of 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.” And the hardware acceleration technology does do all of these things, though your mileage will vary depending on what kind of hardware and software you’re using.

To try out the new Flash Player 10.2 beta, head over the Adobe download page. Be aware that, while 10.2 appears to be relatively stable, it is a beta release and there may be bugs.

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.

Adobe’s press release makes a rather bold claim: “using Stage Video, we’ve seen laptops play smooth 1080p HD video with just over 0% CPU usage.”

Sadly, we have not seen such results. While we won’t argue with the smoothness of the playback in this new release, Flash is still going to use quite a bit of your PC’s CPU. Based on my testing (done on a Macbook Pro laptop using both Firefox 4b7 and Safari 5, and a Mac Pro tower using the same browsers — Wired is an all-Mac office), while CPU usage is down in Flash 10.2, it’s still a long way from zero.

Update: Since this article was published, we’ve been hearing from you, our awesome readers, in the comments and over e-mail. Some things to note: The new beta performs much better on Windows computers than it does under Mac OS X. Also, full hardware acceleration on Mac OS X requires Snow Leopard or later, otherwise it falls back to using software rendering in the CPU. Thanks for the comments, and keep them coming!

On our Macs, we tested several 1080p videos on YouTube in Flash Player 10.1 and found that on average the 10.1 plugin used between 44-48 percent CPU. Watching the same movie in Flash 10.2 did drop the CPU usage down to the 18-22 percent range, but definitely not zero.

Worse, running the same tests on Adobe’s Stage Video optimized demos, Flash 10.2 actually performed worse than than it did on normal 1080p movies with the cpu usage varying widely between 5 and 60 percent (the 18-20 percent range appears to be the norm).

The short story is that, while Flash 10.2 does offer decreased processor usage, it doesn’t quite live up to Adobe’s claims. While Flash Player 10.2’s performance falls short of the hype, there’s no question that it’s a huge leap forward in terms of performance. The smaller CPU footprint alone is well worth the upgrade, provided you don’t mind running beta software. So far Adobe has not set a final release data for Flash 10.2.

One other thing to keep in mind: 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.

As for other new features in this release, there’s Internet Explorer 9 GPU support and support for fullscreen mode with dual monitors — meaning that you can have a movie on one screen and keep working on another.

Custom cursors get some love in this release, too, with Flash Player 10.2 handing off the job to the operating system rather than using resources to manually draw custom cursors. The beta also improves text rendering, adding sub-pixel rendering enhancements that should make your typography look a bit nicer and more readable.

It’s worth noting that the Flash Player 10.2 beta does not replace the Flash Player “Square” preview release — in other words, Flash Player 10.2 still isn’t 64-bit native. If 64-bit support is important to you, stick with the Flash Player “Square” preview.

See Also:

Nov302010
File Under: Location, Web Apps, Web Services

Mining Flickr to Build 3D Models of the World

Microsoft’s PhotoSynth tool is jaw-droppingly awesome. But, because it’s a Microsoft project, the technology is unlikely to appear on some of your favorite non-Microsoft online apps, like Google Maps or Flickr.

However, our friends at ReadWriteWeb stumbled across a very similar tool — at least in terms of the end result — developed by the University of North Carolina in conjunction with Swiss university, ETH-Zurich.

The team has developed a method for creating 3D models by pulling in millions of photographs from Flickr and using some fancy algorithms to generate 3D models of local landmarks. Perhaps even more impressive the results can be generated using a single computer in under a day.

Project lead Jan-Michael Frahm touts the project’s efficiency saying, “our technique would be the equivalent of processing a stack of photos as high as the 828-meter Dubai Towers, using a single PC, versus the next best technique, which is the equivalent of processing a stack of photos 42 meters tall — as high as the ceiling of Notre Dame — using 62 PCs. This efficiency is essential if one is to fully utilize the billions of user-provided images continuously being uploaded to the internet.”

While the results are cool and would make an impressive addition to any number of geo-based services, more serious use cases include helping disaster workers get a better idea of where they’re headed and the extent of damage.

So far the researchers have released a movies demonstrating the technique on landmarks in both Rome (get it? built in a day…) and Berlin, and the results are impressive. For more information on how the process works, check out the UNC website.

See Also:

Nov302010
File Under: HTML5, Web Standards

Can WAI-ARIA Build a More Accessible Web?

Accessibility in web design has come a long way since the days of table-based layouts with single-pixel .gif spacers. But even current best practices are far from perfect.

Today, we’ll tell you a bit more about these accessibility troubles as they relate to dynamic web apps — fitting, as today is Blue Beanie Day. For four years now, design guru Jeffrey Zeldman has encouraged web authors to wear a blue beanie on November 30 to show their support for web standards. Also, you’re encouraged to take a picture of yourself wearing a blue beanie and upload it to a Flickr pool. So, with standards quite literally on the brain, we’ll tackle the topic of rich web apps.

One of the coolest things about web apps is that elements refresh inside the browser without reloading the page. But most screen readers used by those with disabilities can’t parse these changes, so users who rely on them will remain unaware of any dynamically refreshed elements on the page. That’s just one of the many problems that WAI-ARIA, an emerging specification for Accessible Rich Internet Applications from the W3C, is hoping to solve.

At its core, WAI-ARIA is a means of annotating page elements with the roles, properties, and states that define exactly what those elements do. Take a navigation element as a simple example. In HTML5 we might do something like this:

<nav>
    <ul>
        <li>Home
        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

While it might seem that the nav tag would defining the nav element’s “role,” not every browser will understand it (just because the browser can display it, does not mean it understands the tag). Also, the purpose of a navigation element may be obvious to most users, but to a screen reader being used by somebody who can’t see, the navigation strip could be just a jumble of words. Leveraging WAI-ARIA’s syntax, we can double up to ensure screen readers will know that this chunk of code is navigation:

<nav role="navigation">
    <ul>
        <li>Home</li>
        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

The role="navigation" attribute is what’s known as a landmark role and is designed to let non-visual browsers know where they are.

It seems simple, and indeed when the spec is finished and fully supported by all the major screen readers, WAI-ARIA promises to make the web more accessible without overly complicating your markup. Unfortunately, there are numerous problems with WAI-ARIA at the moment, which make support uneven and can be confusing for web authors trying to do the right thing.


Continue Reading “Can WAI-ARIA Build a More Accessible Web?” »

Nov292010
File Under: Browsers, Security

Secure Firefox With New HTTPS Everywhere Add-on

Earlier this year, the Firefox add-on Firesheep created quite a controversy by making it easy to capture unencrypted web traffic.

Firesheep sniffs unencrypted cookies sent across open wi-fi networks. That means anyone with Firesheep installed can watch your browsing sessions while you lounge at Starbucks and grab your log-in credentials for Facebook, Twitter or other popular sites. Armed with those credentials, anyone using Firesheep can essentially masquerade as you all over the web, logging in to other social sites, blogs and news sites using your Facebook or Twitter username and password.

None of Firesheep’s mechanisms are new. But Firesheep made sniffing web traffic point-and-click simple — it was suddenly dead easy to do something that used to require a good bit of hacking knowledge.

The best way to protect yourself from Firesheep is simply avoid connecting to unencrypted sites when you’re on an open wi-fi network. That means making sure that you connect over HTTPS rather than HTTP everywhere you surf. But sadly, doing so is complicated and depends on which site you’re trying to connect to.

That’s where the Electronic Frontier Foundation’s HTTPS Everywhere Firefox add-on comes in. The extension makes it easy to ensure you’re connecting to secure sites by rewriting all requests to an HTTPS URL whenever you visit one of the sites it supports.

Of course if the website you’d like to visit doesn’t support HTTPS, there’s nothing the add-on can do, but for many big sites — Twitter, Facebook, Google, PayPal, The New York Times, Bit.ly, Amazon — HTTPS Everywhere automates the process for you.

With HTTPS Everywhere installed, if you type “twitter.com” in the Firefox URL bar, the browser will automatically connect to https://twitter.com rather than http://twitter.com.

That’s a good start, but it won’t completely protect you from anyone sniffing with Firesheep. The latest beta release of HTTPS Everywhere, released over the long weekend, improves the add-on’s protection against Firesheep, but you’ll need to do some extra stuff.

First, head the HTTPS Everywhere preferences (Tools -> Add Ons -> HTTPS Everywhere -> Preferences) and check the “Facebook+” rule. Then install the Adblock Plus extension and use it to block the insecure http:// advertisements and tracking sites that Facebook (and other sites) sometimes include. There are more instructions on the EFF’s site.

Now you can browse Facebook at the coffee shop in relative peace. Certain parts of Facebook may not work properly — some applications can’t use HTTPS, and the chat app won’t work — but at least you aren’t broadcasting your login credentials to anyone who wants to listen. The EFF says it has alerted Facebook to the incompatibilities, and that it’s waiting for Facebook to fix them.

See Also:

Nov292010
File Under: Browsers, HTML5, JavaScript

Building a GameBoy Emulator in HTML5 and JavaScript

Like Flash before it, HTML5 is where programmers are turning to experiment, and nothing seems to make developers experiment quite like the desire to recreate the classic video games.

We’ve already seen Pac-Man, Astroids and Conway’s Game of Life come to the browser in standards-friendly forms, and now Nintendo’s classic GameBoy platform is getting similar treatment.

The Mozilla Labs gaming blog has a guest post by developer and gamer Imran Nazar, who is hard at work building a GameBoy emulator using JavaScript. As Nazar points out, “HTML5 now offers the Canvas element for easily controlling a two-dimensional graphical display.” Couple that with the improved JavaScript speeds in modern browsers and you have the perfect platform for an emulator.

Nintendo’s GameBoy was the first portable gaming system most of us ever encountered, so the nostalgia factor is high. But the real point of this experiment is to help your understand the processes behind the scenes — how emulators work and how JavaScript can be used to build them.

The emulator isn’t quite finished yet, but Nazar has a great series of posts on his blog covering the various aspects of what he’s done. Not only is it a fascinating look at how emulators work, it also gives some great insight into what JavaScript is capable of doing. You can see the latest version of the emulator on Nazar’s latest post.

If you’re not interested in how it works and just want to get your nostalgia fix by playing some GameBoy games, check out this earlier emulator from programmer Pedro Ladaria.

See Also:

Nov242010
File Under: Browsers, HTML5, Mobile

Mobile Safari Gets More HTML5 Love in iOS Update

Apple recently updated its iOS software for iPhones, iPods and iPads. While there were plenty of new features for users (which you can read about on Gadget Lab), the updated version of Mobile Safari has quite a few nice new tricks for web developers.

Mobile Safari has long been at the front of the mobile pack when it comes to HTML5 support, and the latest version adds several more welcome new features. We now get support for WebSockets, better @font-face handling, better HTML5 forms and even support for the bleeding edge DeviceOrientation API — that’s the API that lets you access the accelerometer from inside the browser.

So far it doesn’t appear that Apple has fully documented the new features, but Maximiliano Firtman, the author of Programming the Mobile Web, has been testing the latest version of Mobile Safari and offers a nice overview of what’s new in iOS 4.2.

If you’re developing mobile-optimized site, or just want to play with next generation HTML features like WebSockets, check out Firtman’s overview of what Mobile Safari can and can’t do. If you’d like to see what Android 2.2 is capable of, Firtman has a similar overview of Froyo’s support for HTML5 and its related APIs.

See Also:

« OLDER POSTS