All posts tagged ‘W3C’

File Under: APIs, Web Standards

New Standard Hopes to Unify Your Address Book

If you’re like most of us, you probably have contact and address book data spread all over the web — friends on Facebook, contacts in Gmail, followers on Twitter, and names in your local address book application.

Wouldn’t it be nice if all that data were available in one place where you could see it all, control which sites have access to it and manage your on and offline friends?

The truly unified address book is still a ways off, but there is hope it will be especially useful once it arrives thanks to some emerging standards.

The Worldwide Web Consortium (W3C), the governing body that creates and oversees web standards, has published a working draft of what’s known as the Contacts API. The goal behind the Contacts API is to provide a way to unify your address book, pulling from both local and online sources, and to allow you to better control how third-party websites access your data.

The latest draft incorporates feedback based on the earlier draft, first published back in January of 2010. It builds upon the work being done on vCard and Portable Contacts, among other contact systems already being used on the web. The final version is penciled in for mid-2011.

The Contacts API is part of a broader initiative at the W3C called the Ubiquitous Web Applications activity. The purpose of the group is to develop underlying infrastructures web services can take advantage of to make web apps more powerful and more useful. The Geolocation API, which lets a web app learn your location, and the Devices API, which lets a web app access a camera or microphone in your hardware, are also part of the same initiative. It also fits into the ideals outlined by the W3C’s vision of a semantic web.

So what will the Contacts API standardize? Currently, if a site wants to access your contacts list it generally does so by grabbing, say, your whole Gmail contacts list. Even with standards like OAuth, which gives you control over which sites can access your contacts list, you still don’t have much in the way of fine-grained permissions.

Say you want Facebook to only grab contacts that you’ve put in the address group “friends” in your Gmail address book. With the current controls, you’re out of luck. But if and when the Contacts API is ratified and adopted, that’s exactly the sort of thing it would allow you to do.

The Contacts API would also give the browser a method of unifying all your various contacts lists — for example your contacts from Gmail, Facebook and your local address book all merged to single list.

It sounds grand, no doubt, but the Contacts API is a long way from reality. Mozilla has experimented with the API (along with other tools) to create the Labs project Contacts, but like the APIs it uses, Contacts is still very much a work in progress.

See Also:

File Under: Events, Fonts, Web Standards

Web Heavies Send a Love Letter to Open Web Fonts

The nascent Web Open Font Format (WOFF) is getting a boost this week thanks to some new initiatives being kicked off by the W3C, the web’s governing body.

The W3C recently created a working group to build a WOFF into a web standard, and that group will be holding its first face-to-face meeting at the TypeCon 2010 conference taking place this week in Los Angeles.

Representatives from the major browser vendors, several font foundries and web services providers will be in attendance. Also, a dozen or so select individuals will be participating in a series of presentations and panel discussions about WOFF throughout the conference. All the design industry folks in attendance will get a peek at the future of high-quality typography on the web. There are scores of topics on the program, but this year, WOFF is getting top billing.

Things are looking up for web fonts in general. Monday, Typekit announced a partnership with Adobe to include the company’s fonts as part of its licensing service. Last month, Google launched a new tool (tied to its Font API) that makes it dead easy to include any of its open source fonts in website designs.

The Web Fonts working group was formed earlier this year at the W3C, and the group has already released the first working draft of the specification that will eventually lead to WOFF becoming a recommended web standard.

WOFF works just like OpenType and TrueType — you use the @font-face CSS property to drop the fonts in — but the font data is compressed, so the files download faster, and you can include more fonts in your designs without worrying as much about payload bloat.

The W3C adds this bit: “The WOFF format is not expected to replace other formats such as TrueType/OpenType/Open Font Format or SVG fonts, but provides an alternative solution for use cases where these formats may be less performant, or where licensing considerations make their use less acceptable.”

Support for WOFF is already strong — Google, Mozilla, Apple, Opera and Microsoft browsers either ship with or are building support, and the fast-moving foundries are releasing WOFF fonts — so why is the W3C’s involvement a big deal when the open source format is enjoying such success?

Standardization by the W3C is the best path to true interoperability. It will keep all the parties on the same page when it comes to things like accessibility, cross-browser compatibility, internationalization and search engine indexing. How much metadata to include and how it is handled are also big issues. Plus, fonts have taken an astonishingly long time to arrive on the web because of red tape around licensing, and a collaborative process for developing licensing infrastructures will go a long way toward convincing some of the more conservative type designers to make web-friendly versions of their creations.

The standard will take years to complete (the process is very slow — we’re guessing 2012 or so), and until then, we’ll see designers, developers and innovative service providers like Typekit and Google continue to feed the interest in fancy web fonts. Those not on the bleeding edge may be stuck in the boring world of “web safe” fonts for a while, but at least the future is bright.

TypeCon 2010 runs from August 17 through 20.

Photo by Leo Reynolds/Flickr/CC

See Also:

File Under: Web Standards

W3C’s Unicorn Validator Checks Multiple Standards at Once

Want to find out how magically terrible your web code is? Just ask the Unicorn.

The web’s governing body has launched a new validation tool called Unicorn that checks the quality of your website’s code against multiple web standards at the same time.

You can find the new Unicorn “all-in-one validator” on the Worldwide Web Consortium (W3C) website at

The W3C maintains a number of free web-based tools for checking whether your web code is valid, and Unicorn makes several of these tools available under a single interface. Just plug in a URL and you can see your results for all of these tests on a single page:

  • HTML/XHTML markup validator
  • CSS validator
  • Atom or RSS feed validator
  • mobileOK, which tells you how friendly your site is to mobile visitors

When you visit the Unicorn page, you’ll see a dropdown menu where you can choose what to check. The default is a “General Conformance Check,” which runs all the validators at once and is particularly unforgiving. Your site may validate as strict XHTML, but your syndication feeds and mobile accessibility might be a mess. It’s almost impossible to rack up a perfect score, so be prepared for a lot of red ink.

You can also select one of the individual validation services in the dropdown. Each of the individual validators also continues to run on its own service, and the W3C confirms they aren’t going anywhere.

Unicorn will continue to roll in more validation options over time. There’s already a wiki where you can learn how to write additional modules.

The wiki is also where you’ll find links to the Unicorn code. You can run your own instance of the validator to test your own pages, or you can set up a public Unicorn server for others to use.

Every time we post about one of these validation tools, we get a small flood of comments pointing out that our own web pages don’t validate properly. We know, and we’re working on it. So, just to save you the trouble, here’s Webmonkey and Wired. You’ll notice that our RSS feeds are perfect — Unicorn’s only quibble is that we put Flash-video-object embeds in our syndicated posts. Big whoop.

See Also:

File Under: Browsers, HTML5, Web Standards

VP8 Could Become a Standard in HTML5

Mozilla will lobby for the VP8 video codec to become the recommended standard video technology on the web, the company’s CEO says. Mozilla will propose the idea to the World Wide Web Consortium (W3C) in order to have the technology, which has just been open sourced, added to the specification for HTML5.

“That’s our hope,” Mozilla CEO John Lilly tells CNet’s Stephen Shankland. “We’d love for VP8 to be specified in the HTML5 standard. Once it’s in the spec, it can really get better traction from other players.”

The company would need to rally support from all the major browser vendors and the W3C to get such a proposal into the spec. Mozilla isn’t saying just yet how it plans to go about doing so, but we can expect a statement in the coming days, according to Shankland’s report.

For its part, the W3C is anxious to arrive at a standard recommendation for a single native web video solution. The consortium has a policy that any technology it recommends adheres to its own royalty-free patent policy. The WebM project, the group behind VP8, is confident the codec does not infringe on any patents.

Continue Reading “VP8 Could Become a Standard in HTML5″ »

File Under: HTML5, Web Standards

No Virginia, Adobe Isn’t Blocking HTML5

Ian Hickson, head of one of the standards groups charged with creating HTML5, caused quite a stir over the weekend when he alleged that Adobe was trying to block HTML5.

Adobe quickly denied the charge, but not quickly enough for the open web evangelists to grab their pitchforks and take to blogs in anger. After all, it was a juicy turn of events — big company with a vested interest in its own tech (Flash, in this case) tries to block a competing technology on the free, open web. It all ended up sounding like some conspiratorial, back-room maneuvering worthy of an Oliver Stone film.

The truth is considerably more complex and, dare we say, kind of embarrassing. In fact, dig a bit into the internal workings, back-stabbing, petty snipping and politics of both the W3C and the WHAT WG, and you’ll quickly come to realize it’s nothing short of a miracle that HTML5 exists in any form at all.

This particular tempest in a teacup revolves around an e-mail from Larry Masinter, Principal Scientist at Adobe, questioning whether the Canvas 2D element, the RDFa specification and the Microdata spec were within the scope of the WHAT WG’s charter.

The answer to that is hashed out in some detail on the WHAT WG’s public mailing list. The short version seems to be that no, they probably aren’t, but WHAT WG decided to include them in the spec anyway.

As far as we can tell, no formal objection was ever lodged. Though it certainly sounds like Masinter is planning to file one when he writes:

If I need to use the word “formally” in there somewhere, or if there’s some “Formal Appeal Change Proposal” form I’m supposed to fill in, recapitulating all of the e-mail arguments made to date, suggesting the documents “change” by disappearing, and written in iambic hexameter, please let me know.

However, Masinter has since said that neither he nor Adobe has filed or intends to file any formal objections. Perhaps more importantly, even if Masinter were to do so, it’s hard to see how that would “block” HTML5. Masinter (and some others) merely object to HTML5, Canvas 2D and other specs all being lumped together, not to the specs themselves.

So how will all this hoopla impact HTML5 and the web that we mortals actually use? The answer is, it won’t.

Regardless of what the W3C ends up doing with the Canvas 2D spec and other sub-elements of HTML5, browsers are already supporting them. Certainly it would be good if these elements became an official part of the HTML5 spec, but whether or not they do will have very little impact on the web as we know it. After all the HTML5 spec won’t officially be finished until 2012, but HTML5 is already changing the web since all browsers but IE are supporting it.

The reality is that, for all their blustering and antics, neither the W3C nor the WHAT WG ultimately have much practical impact on HTML5′s adoption on web. For that, we rely on browsers and the various HTML5 elements they chose to support.

See Also: