Archive for the ‘Web Standards’ Category

Mozilla Blends Social API, WebRTC for More Social Apps

Mozilla is making good on its promise to take its fledgling Social API beyond the simple Facebook integration it showcased for the launch of Firefox 17. In fact, the company’s newest Social API demo removes the need for social websites entirely, tapping emerging web standards to create a real-time video calling, data sharing app — one part Skype, one part Facebook, all parts web-native.

The direct peer-to-peer video calls and file sharing features come from WebRTC, a proposed web standard that Mozilla and others are working on in conjunction with the W3C. The RTC in WebRTC stands for Real-Time Communications, and the core of WebRTC is the getUserMedia JavaScript API, which gives the browser access to hardware features like the camera and microphone.

Much of the enthusiasm around WebRTC comes from the fact that it enables web apps to do many of the same things that, without WebRTC support, require platform-native APIs. WebRTC will help developers build web apps that can compete with native apps, but it has other tricks up its sleeve — like a whole new way to connect with your friends on the web.

“While many of us are excited about WebRTC because it will enable several cool gaming applications and improve the performance and availability of video conferencing apps, WebRTC is proving to be a great tool for social apps,” writes Mozilla’s Maire Reavy on the Mozilla blog.

Reavy goes on to paint a picture of seamless social sharing through WebRTC and Mozilla’s Social API:

Sometimes when you’re chatting with a friend, you just want to click on their name and see and talk with them in real-time. Imagine being able to do that without any glitches or hassles, and then while talking with them, easily share almost anything on your computer or device: vacation photos, memorable videos — or even just a link to a news story you thought they might be interested in — simply by dragging the item into your video chat window.

Mozilla’s Social API-WebRTC mashup goes beyond previous demos, using a new WebRTC feature, one which Firefox is the first to support, DataChannels. DataChannels offer a way to send data from one WebRTC-enabled browser to another. DataChannels can send pretty much any data the browser can access, be it images, videos, webpages or local files.

For more details on how the DataChannel API works, check out this earlier post on the Mozilla Hacks blog. If you’d like to see exactly what’s happening behind the scenes of Mozilla’s Social API-WebRTC demo, the code is available on GitHub.

File Under: CSS, Web Standards

Exercise Better Web Typography With CSS Hyphens

Forget The Homer; look at those sweet, sweet hyphens. Image: Screenshot/Webmonkey.

Last night, while reading Craig Mod’s excellent article, Subcompact Publishing, I noticed something that only type-obsessed nerds probably notice: some really good-looking hyphenation. A quick right-click to “inspect element” revealed this gem: -moz-hyphens: auto;.

It’s true; while we were sleeping Firefox, IE 10 and Safari all implemented the CSS hyphenation spec. In fact, Firefox has had hyphenation support for over year (starting with version 6). Sadly, Chrome doesn’t support hyphens just yet, nor does Opera. Still, if you’d like to do something really simple that will vastly improve the readability of your text for Firefox, IE 10 and Safari users, add this to your site’s stylesheet:

p {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    -ms-hyphens: auto;
    -o-hyphens: auto;
    hyphens: auto;
}

Right now the -o- prefix isn’t doing anything, but it future-proofs the code a bit for when Opera adds support. The only catch to hyphenation is that not only does the browser need to support it, it also needs to have a hyphenation dictionary for the language you’re using. The Mozilla Developer Network has a good rundown of which browsers support which languages.

There’s no real need for a fallback since the web has never had any hyphenation. Browsers that don’t support the CSS hyphens rule will simply render the page as they always have, but those that do will now be a bit more readable.

And, as a kind of footnote, if you have any interest in the future of publishing, Subcompact Publishing is well worth a read.

[Update: It looks like developer Peter Paul Koch just noticed hyphenation support as well. He's got a short post that notes one potential problem with hyphens that I missed: you need to explicitly declare a language, as in <html lang="en"> in order to trigger hyphenation. See Koch's post for more details.]

File Under: privacy, Web Standards

New W3C Co-Chair Steps Into the ‘Do Not Track’ Fray

Image: Footprints by Kimba Howard/Flickr

The W3C, the standards body charged with overseeing the development of HTML and other web standards, has announced a new co-chair for the group that’s hard at work creating the Do Not Track (DNT) privacy standard.

Peter Swire will now co-chair the Tracking Protection Working Group alongside Intel’s Matthias Schunter.

The Do Not Track header is a proposed web standard for browsers to tell servers that the user does not want to be tracked by advertisers.

This isn’t Swire’s first foray into the controversial waters of the Do Not Track standard. The Ohio State law professor previously testified about DNT before the U.S. Senate and has been critical of the advertising industry’s attempts to derail DNT.

“I personally would not like to have an internet where I believed that each moment of my browsing might easily be breached and shown to the entire world,” Swire testified to the Senate. He also called out the Digital Advertising Alliance’s proposed exceptions for “market research or product development,” as “so open-ended that I have not been able to discern any limits on collection under them.”

While Swire has a good track record supporting user privacy, he clearly has his work cut out for him. All the major web browsers now support Do Not Track, but some of the biggest advertisers on the web — notably Google — are not, thus far, paying any attention to users that actually broadcast a DNT signal as they browse.

Swire’s new job will be a potentially Herculean task — to get advertisers to actually comply with the DNT header. (Co-chair Schunter is in charge of the specification.) As I’ve written before, asking advertisers not to set tracking cookies is like asking Cookie Monster not to eat them.

Microsoft recently further muddied the DNT waters by shipping IE 10 with DNT effectively enabled by default. Critics argue that having DNT on by default means it’s no longer a user-controlled setting and does not comply with the intent of the standard — which is to make DNT something users explicitly opt into. The Apache web server and Yahoo have both already announced they plan to ignore DNT when it comes from IE 10.

File Under: CSS, Web Standards

Use Tomorrow’s Web Standards Today With CSS ‘@Supports’

Woolly, the CSS sheep.

Using CSS 3 on the web today means that, inevitably, some browsers won’t be able to display some elements of your design. Hopefully you’re using progressive enhancement so that your pages still function in less-capable browsers, which might not understand all those fancy transform rules.

For more complex projects progressive enhancement might even mean turning to a feature detection library like Modernizr, which will detect and apply CSS classes based on the current browser’s capabilities.

Modernizr is great when you need it, but did you know that soon the browser itself will be able to give you the same information?

Both Opera 12.10 and Firefox 19 (currently in the Aurora channel) support native CSS feature detection through the CSS @supports rule. CSS @supports offers the same capabilities of Modernizr — selectively applying CSS based on what the current browser supports — but it does it through much faster native code. Even better, because browsers that don’t support @supports will just ignore it, you can start using it today.

Opera Software’s Chris Mills recently posted a nice intro to using @supports which you should read for more details, but here’s an example to illustrate the basic idea:

@supports ( box-shadow: 2px 2px 2px black ) {
    .my-element {
        box-shadow: box-shadow: 2px 2px 2px black;
    }
}

The code above uses @supports to check for support for the box-shadow property and then applies a box shadow to browsers that will display it. Of course since many of the features you’d likely be detecting are still prefixed, a more complete example (pulled from the W3C’s @supports page) would look like this:

@supports ( box-shadow: 2px 2px 2px black ) or
          ( -moz-box-shadow: 2px 2px 2px black ) or
          ( -webkit-box-shadow: 2px 2px 2px black ) or
          ( -o-box-shadow: 2px 2px 2px black ) {
    .outline {
        color: white;
        -moz-box-shadow: 2px 2px 2px black;
        -webkit-box-shadow: 2px 2px 2px black;
        -o-box-shadow: 2px 2px 2px black;
        box-shadow: 2px 2px 2px black; /* unprefixed last */
    }
}

Now we’re checking for not just box-shadow but any vendor-prefixed versions of it as well. We’re also not just applying box-shadow, but also changing the outline color to white, which (assuming a white background) would not be good to do in browsers that don’t support box-shadow since it would make the outline invisible to the user.

As you can see @supports is pretty handy for progressive enhancement and it avoids the overhead of loading a JavaScript library like Modernizr. CSS @supports also works with operators like not and or so that you could write a rule that says the opposite of what we did above. In other words, detect that the current browser doesn’t support box-shadow and do something else.

CSS @supports gets even more powerful when you start chaining @support rules together, which is what Mills does in his post on the Opera Dev center, detecting for animations and transforms to serve one thing to browsers that support 3D transforms, one to those that only understand 2D transforms and a third to those that don’t support transforms at all.

So should you ditch Modernizr and go with @supports? Probably not just yet, but soon. First off, if you’re using Modernizr for more than just CSS detection then obviously stick with it. But, as Opera’s Bruce Lawson notes in a follow-up to Mills’ post, “the reason to use @supports over Modernizr is performance; functionality that’s built into the browser will always be faster than adding it in script.” Getting rid of Modernizr would also mean eliminating an external dependency, which saves an HTTP request as well.

In fact Modernizr itself plans to defer to @supports in future releases. If you’d like to have the best of both worlds today, what you need to do is first detect for @supports and then if it’s not available load Modernizr. See Lawson’s post for a code snippet that does just that.

File Under: Browsers, Mobile, Web Standards

Microsoft Offers Guide to Adapting Your Site for IE 10

Nokia Windows Phone 8. Photo: Ariel Zambelich/Wired.

Microsoft’s Windows Phone 8 offers much better HTML5 support than its predecessors thanks to the Internet Explorer 10 web browser.

Unfortunately, if you’ve been building WebKit-centric sites IE 10 users won’t be able to properly view your site, which is why Microsoft has published a guide to adapting your WebKit-optimized site for Internet Explorer 10.

If you’ve been following CSS best practices, using prefixes for all major browsers, along with the unprefixed properties in your code, then there’s not much to be learned from Microsoft’s guide (though there are a couple of differences in touch APIs that are worth looking over).

But if you’ve been targeting WebKit alone, Microsoft’s guide will get your sites working in IE 10, WebKit, and other browsers that have dropped prefixes for standardized CSS properties.

Sadly, even some the largest sites on the web are coding exclusively for WebKit browsers like Chrome, Safari and Mobile Safari. The problem is bad enough that Microsoft, Mozilla and Opera are planning to add support for some -webkit prefixed CSS properties.

In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t. So far Microsoft hasn’t carried through and actually added support for -webkit to any versions of IE 10, but Opera has added it to its desktop and mobile browsers.

Microsoft’s guide to making sites work in IE 10 for Windows Phone 8 also covers device detection (though it cautions that feature detection is the better way to go) and how to make sure you trigger standards mode in your testing environment, since IE 10 defaults to backward-compatibility mode when used on local intranets.

For more details on how to make sure your site works well in IE 10 for Windows Phone 8, head on over to the Windows Phone Developer Blog (and be sure to read through the comments for a couple more tips).