Archive for January, 2011

File Under: HTML5, Programming, Web Standards
Jan
18
2011

HTML5 Gains Logo, Loses Meaning

By

The W3C's new HTML5 logo

What’s that thing flailing awkwardly over the mouth of a mechanical shark? Why that’s HTML5 in its dashing new logo. Yes, the W3C, the standards body that oversees the development of the HTML5 spec, has blessed HTML5 with a snazzy new logo.

Naturally there are badges you can add to your site and t-shirts and stickers are already on sale (a portion of the proceeds go to the development of the W3C’s HTML5 Test Suite). The only thing left to do is figure out what “HTML5″ actually means, and that’s where the W3C has has thrown “HTML5″ over the shark.

HTML5 already enjoys more buzz that a web developer left alone in the back of a Mountain Dew truck (it even has it’s own posse), the only problem is that the buzz makers conflate just about every emerging web technology under the HTML5 umbrella. Purists have long decried headlines proclaiming the glory of HTML5 above an article about JavaScript and CSS 3, but now the one group that ought to know best appears to throwing in the towel and embracing the HTML5 hype.

While the new HTML5 logo looks good, the FAQ that accompanies it is troubling. According to the W3C, the logo is “a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.”

It doesn’t really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we’d like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”

As web developer Jeremy Keith quips, “the term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland.” We had high hopes that Bruce Lawson’s acronym NEWT — New Exciting Web Technologies — would catch on and save HTML5 from buzzwordland, but alas, that appears unlikely.

With the blessing of those who oversee it, HTML5 now apparently means just about anything new and cool on the web. The new HTML5 logo is pretty sharp and the t-shirts look nice, but if we can’t have precise terms and linguistic clarity could we at least get a unitard with belt and cape?

See Also:

File Under: Browsers
Jan
18
2011

Firefox 4 Enters Home Stretch With Beta 9 Release

By

Firefox 4 beta 9Mozilla has released a new beta version of Firefox 4, as the next major update for the popular web browser nears completion. Firefox 4 beta 9 is primarily a bug fix release, though there a couple of small new features.

If you’d like to take Beta 9 for spin on your desktop, head over to the Mozilla beta downloads page. It’s been a very long development cycle for Firefox 4 — the final version isn’t likely to arrive until the end of February — however, the enhancements being made over versions 3.5 and 3.6 are substantial.

Fortunately for early adopters the beta releases are stable enough to use in day-to-day browsing, so it’s not like we’re waiting a long time for nothing. We can reap the rewards well before the official release date.

On the Windows platform, beta 9 now ships with the tabs-in-the-title-bar feature we covered earlier this month. Firefox 4 beta 9 also includes support for IndexedDB, which allows approved sites to store data on your computer for offline use. Other improvements include an overhaul of the bookmarks and history code, enabling faster bookmarking and improving Firefox’s startup performance.

The best news for those eagerly awaiting the final release of Firefox 4 is that beta 9 has squashed some 660 bugs. Indeed, beta 9 is among the fastest and stablest betas we’ve used, but it’s still not ready for prime time. Problems remain with the new tab-sorting interface — dubbed “Panorama” — and there are enough other small problems that it looks like we’ll see a beta 10 before Firefox 4 is official.

So far Mozilla is sticking to its “when it’s ready” slogan and has not set a final release date for Firefox 4. With the latest nightly builds already renamed to beta 10, you can expect one more beta. After that there will be at least one release candidate, which pushes the final release of Firefox 4 well into February.

See Also:

Tags: ,
File Under: Browsers, Multimedia, Security
Jan
13
2011

Adobe Working on an Easier Way to Delete ‘Flash Cookies’

By

When it comes to erasing your tracks on the web, nothing is more pernicious and difficult to delete than the Flash-based cookie. Technically known as “local shared objects,” Flash cookies don’t go away when you clear your browser-based cookies. Instead they hang around, potentially collecting data without your knowledge or consent.

To delete Flash cookies you have to navigate through the Flash Player settings dialog. Unfortunately most users don’t know how to do that and Adobe has, until now, put very little effort into simplifying the process (it has at least made Flash respect the “private browsing” mode in modern browsers).

Now Adobe is finally taking some steps toward simplifying the process of deleting Flash cookies. The company has announced it is working on a new API that will allow your browser to delete Flash cookies along with the rest of your cookies. For now only Mozilla and Google are working on the API with Adobe, but presumably Adobe is talking to Microsoft and Apple as well.

While there’s no shipping code at this point, if the API were to make it into Firefox and Chrome it would give users an easy-to-find menu for quickly clearly Flash cookies. Adobe’s blog post says users can expect to see the changes “in the first half of the year.”

The move would no doubt by a small boon to privacy, but as Ars Technica points out, Flash cookies aren’t the only source of hard-to-defeat, persistant online tracking. For instance, the dreaded “evercookie” stores data in no less than 13 places and is nearly impossible for the average user to delete.

Still, for those annoyed at the complexities of deleting Flash cookies, things may soon, thankfully, get a bit simpler.

Miniature Food photo by Stéphanie Kilgast/Flickr/CC

See Also:

Tags: , ,
File Under: Browsers, Mobile, Programming
Jan
13
2011

Speed Up Your Mobile Site With the ‘Mobile Perf’ Bookmarklet

By

Speed is the most important element of your website. The best designed, most informative site in the world is useless if it doesn’t load fast enough for people to stick around. Nowhere is this more true than on mobile websites.

Testing mobile websites is something of a headache — there is no Firebug for mobile browsers, which means no YSlow or other profiling tools. True, you can load the site in desktop browser and profile it that way, but sometimes what works on the desktop isn’t necessarily working the same way in a mobile browser.

That’s why Google developer Steve Souders’ created the Mobile Perf bookmarklet, a handy javascript bookmarklet that you can use to test sites on your mobile devices. The bookmarklet is really just a set of links to other bookmarklets, but combining them all in one place makes life a bit easier.

The Mobile Perf bookmarklet contains links to Firebug Lite, the awesome DOM Monster, CSSess, Zoompf and Souders’ own SpriteMe and Page Resources. If you’ve been looking for an easy way to test website performance on the small screen, grab a copy of the Mobile Perf bookmarklet.

See Also:

Tags:
File Under: CSS, HTML5, Visual Design, Web Standards
Jan
13
2011

Styling Webpages With ARIA’s ‘Landmark Roles’

By

We’ve covered how you can make your webapps more accessible using WAI-ARIA — the W3C’s emerging specification for Accessible Rich Internet Applications — but did you know ARIA can also help style your pages?

Web developer Jeremy Keith recently took a look at how ARIA’s “landmark roles” can be used, not only to make your pages more accessible, but for styling purposes as well. Consider HTML5′s header and footer tags. The average page has a main header and footer and then may also use the same tags within an article tag, for example, to wrap a headline, dateline and other auxiliary information.

So how do you target just the main header and footer tags without also styling the inner tags? Well, you could drop some IDs in your page, something like <header id="main">. But ideally the ID attribute is not simply a styling hook to be thrown around at the designer’s whim.

Keith points out a better way: using ARIA’s landmark roles. To stick with the same example, you could write something like this:

<header role="banner">
    ...header code here
</header>

Now you can target that specific header tag with CSS’s attribute selector:

header[role="banner"] {
    your styles here
}

Not only have you avoided the plague of otherwise meaningless ID attributes, you get the accessibility benefits too — ARIA roles are supported in JAWS, NVDA and Voiceover. It’s a win-win solution: more accessible code with styling hooks built in.

Be sure to read through Keith’s post for some landmark role examples. Also see our early post on building a more accessible web with WAI-ARIA, and of course, read through the WAI-ARIA role spec, which has more examples and guidelines for when and where to use them.

Italian Masks photo by Peter Lee/Flickr/CC

See Also:

Tags: , ,
File Under: Browsers, HTML5, Multimedia, Web Standards
Jan
12
2011

Google Dropping H.264 Codec from Chrome Browser [Updated]

By

Google has rather nonchalantly dropped a bombshell on the web — future versions of the Chrome browser will no longer support the popular H.264 video codec. Instead Google is throwing its hat in with Firefox and Opera, choosing to support the open, royalty-free WebM codec.

Google says the move is meant to “enable open innovation” on the web by ensuring that web video remains royalty-free. While H.264 is widely supported and free for consumers, sites encoding videos — like YouTube — must pay licensing fees to the MPEG Licensing Association, which holds patents on AVC/H.264

Prior to Google’s announcement, the web video codec battle was evenly split — Firefox and Opera supported the open Ogg and WebM codecs, while Safari and Internet Explorer supported H.264. Google took the egalitarian path and supported all three codecs.

Google’s move away from H.264 makes sense given that Google is already heavily invested in WebM. In fact, the only reason the WebM codec exists is because Google purchased On2, the creators of the VP8 codec. Once Google acquired the underlying code it turned around and released VP8 as the open source WebM project.

There’s been considerable outcry from developers concerned that they now need to support two video codecs to get HTML5 video working on their sites. However, given that Firefox — which has a significantly greater market share than Google’s Chrome browser — was never planning to support the H.264 codec, developers were always going to need to support both codes for their sites to work across browsers.

Google’s decision to drop H.264 from Chrome does raise some questions though. For instance, Android also ships with H.264 and so far Google hasn’t made any announcement regarding the future of H.264 on the Android platform. One of the reasons H.264 has become so popular is that the codec enjoys robust hardware support across devices — whether it’s desktop PCs, mobile devices or set top boxes. While WebM has made some strides in hardware acceleration since it was originally released, it still lags well behind H.264. At least for now it seems that Android most likely needs to continue supporting H.264.

The move also raises questions about YouTube, still the largest video site on the web. Currently the site serves H.264 videos to most browsers, whether through the HTML5 version of the site or using the Flash Player. It seems obvious that Google must be hard at work converting the site to use WebM, but will it continue to support H.264 for those browsers and devices that don’t support the WebM codec? So far Google hasn’t made any announcements regarding YouTube and H.264.

Critics of Google’s decision to drop H.264 support in Chrome point out that Chrome ships with Flash, which, like H.264, is not really an open web technology. Indeed it would seem hypocritical for Google to dump some closed tools while keeping others, but, in Chrome’s defense, Flash is well entrenched in the web and ditching it really isn’t practical. Rather Google’s decision seems to be pragmatic — the company is in a position to take a stand on video codecs and it is doing so before H.264 becomes as entrenched as Flash.

[Google did not respond to a request for comment on this article. A Google Spokesperson tells Webmonkey that the announcement is related to "Chrome only and does not affect Android or YouTube." Presumably both will continue to offer H.264 support. As for Flash, the Spokeperson says, the Chrome announcement "is about the importance we place on open technologies being the foundation of the emerging web platform moving forward." In other words, dropping Flash support isn't practical.]

See Also:

Tags: , , ,
File Under: Programming, Social
Jan
11
2011

Goo.gl URL Shortener Coming Soon to a Twitter Client Near You

By

Google’s URL shortening service, goo.gl, has added an API, giving third-party developers a way to integrate the service into their own apps. The new API means Twitter clients and other apps that use short URLs can hook into goo.gl just like they do bit.ly and dozens of other shorteners.

The goo.gl API is, like most Google APIs, a RESTful JSON-based API. There are only three real methods — insert, list and get — but that’s enough info for apps to shorten and expand URLs, as well as fetch history and analytics for shortened links.

The goo.gl shortener is a late entry into an already crowded field, but of course the Google name carries a good bit of weight so you can expect most Twitter clients to add goo.gl to their list of URL shortening options. The goo.gl shortener also has a couple of nice extras like QR codes and, according to stat tracking site Pingdom, it’s both the fastest and most reliable URL shortener out there.

If you’d like to play with the new service, the API documentation and developer guide can be found on the Google Labs site. And yes, the API is a labs project and may be subject to change before it graduates into a real web service.

See Also:

Tags: ,
File Under: HTML5, JavaScript
Jan
10
2011

Awesome Guitar Tab Mashup Showcases Audio Data API

By

Attention budding guitar players, the web just might turn into the best guitar teacher around.

The Mozilla hacks blog has details on an awesome web-based guitar tab player experiment from developer Greg Jopa. Using Mozilla’s experimental Audio Data API and the Vexflow HTML5 music notation rendering API, Jopa’s guitar tab player displays interactive sheet music that traces the notes of a song as it plays.

If you’re using Firefox 4, head over to the demo site to see the mashup in action. Other browsers won’t work, but the demo movie below shows how the guitar tab player works.

The reason this experiment only works in Firefox is because it uses Mozilla’s new Audio Data API, which gives web developers a way to interact with raw audio data in HTML5′s <video> and <audio> elements using JavaScript. With the Audio Data API, developers can read and write audio data within the browser, opening the doors for online tools like spectrum analyzers, audio remixing tools and 3D audio visualizations.

While Mozilla’s Audio Data API hasn’t been blessed by the W3C just yet, plenty of what we use on the web right now — XMLHttpRequest anyone? — started out exactly the same way. Because the web embraced XMLHttpRequest, it became a standard. Given this awesome experiment and some of the other great demos we’ve seen that use the Audio Data API, we’re really hoping the W3C adds the Audio Data API to the spec.

See Also:

Tags: ,
File Under: HTML5, Web Standards
Jan
10
2011

Join the Early Adopters and Help Make HTML5 Better for Everyone

By

Whenever we write about HTML5 here at Webmonkey — whether it’s something great, like Microdata, or something not-so-great, like the flaw in WebSockets — there is an inevitable comment or two telling everyone that they should wait until HTML5 is done. Some people think even the W3C doesn’t want you adopting HTML5 just yet.

Of course all those people, including the W3C, are wrong. Not only is much of the HTML5 spec well on its way to being finalized, browsers already support much of it. The level of support varies by browser, but HTML5 is very much here today.

The real reason you should use HTML5 now is that early adopters are already helping to make it better, finding bugs and giving the browser makers a reason to fix them.

Mark Pilgrim’s site Dive Into HTML5 is a fantastic resource for learning HTML5 and it’s written in HTML5. Pilgrim recently pointed out that the site’s use of HTML5 and CSS 3 has “led to bug fixes in at least four browsers and one font.”

If we all waited to use HTML5 until it was “done” we wouldn’t know about those bugs. It’s early adopters — like many Webmonkey readers — who are helping to make the web better by using HTML5 today and helping to discover the parts that don’t work in the real world. Browser bugs aren’t always discovered by reading specs or through stress tests like ACID 3, they’re discovered in the wild, on the web. Finding them now means that than in five or ten years when HTML5 is set in stone, it will have fewer problems.

Naturally we’re not suggesting that HTML5 is right for every website. Mainstream sites don’t want to discover bugs, though that hasn’t stopped big names like Nike from jumping in the HTML5 waters.

Maybe some parts of HTML5, like say WebSockets, aren’t quite ready to be used on the New York Times homepage. But smaller sites using WebSockets are helping to pave the way so that eventually sites the size of the Times can use WebSockets and the rest of HTML5 without worrying about bugs.

Not every site needs to live on the edge, but those that do make the web a better place for all the rest.

[Note to the commenters who will inevitably point out that we don't use HTML5 at Webmonkey: those of us that write for Webmonkey do not also write the code that runs it.]

5 Mosaic photo by Leo Reynolds/Flickr/CC

See Also:

Tags: ,
File Under: CSS, HTML5, Web Standards
Jan
7
2011

A Guide to HTML5 Features You Can’t Detect

By

What language does that browser speak?

What language does that browser speak?

Web developers looking to play with the new features in HTML5, CSS 3 and other NEWT tools are still struggling with incomplete and inconsistent browser support. While HTML5 and its siblings are far from perfect (and complete), that doesn’t mean you can’t use them; it just means using them is a little more complicated since you need to detect the current browser’s level of support and then adjust accordingly.

One of the easiest ways to detect the current web browser’s level of HTML5 support is the Modernizr JavaScript library. We’ve covered Modernizr several times in the past and it’s a great addition to any HTML5 toolkit.

But sadly, not everything can be detected with JavaScript. If you’ve ever bashed your head against the keyboard trying to figure out why something wasn’t being detected, Modernizr has a new wiki page for you: The Undetectables.

The page lists a number of features that simply can’t be detected using general feature tests. Instead, these features can be found by either user agent sniffing (which leads to heartache and doom), browser inferences or as the wiki puts it “simply providing the same (slow) fix to everyone.”

In some cases there are workarounds, like the great keypress JavaScript effort from Google , which fixes a number of erratic, inconsistant keyboard behavior quirks in today’s browsers. However, in many cases you’re probably better off avoiding the undetectable features until browsers catch up.

If your code has been behaving strangely, despite your best efforts to detect a browser’s features, save yourself some hair pulling and head over the new Modernizr page to see if perhaps the problem is on the list of things that can’t be detected. If you discover other problems trying to sniff a browser’s capabilities, be sure to let the Modernizr devs know about it.

See Also:

Tags: , ,
« OLDER POSTS