Why we support the new .webfont proposal
There has been a flurry of activity in the W3C Web Fonts mailing list lately, much if it responding to a proposal from Tal Leming and Erik van Blokland for a new format for linked font files. In their proposal, they outline an XML “wrapper” that describes a variety of metadata and the ability to embed the font data agnostic of format.
At Typekit, we are particularly interested in the steady technical progress being made at the intersection of browser developers, web designers, and the type industry. Recently, we’ve been digging in deep into how fonts interact with browsers, how they’re rendered, and the best way to serve them. From that perspective, we’re very happy to see a proposal like this and look forward to supporting it fully.
Momentum for this recommendation is coming from the right place, as shown by this list of supporting foundries. As Bert Bos, the W3C representative and co-author of the CSS specifications, accurately pointed out, “What’s most interesting to me is that the proposal comes from font makers and is nevertheless written in language that programmers understand.” Speaking the same language is crucial to bridge the gap between those implementing technical solutions and the commercial interests of a creative industry.
The proposal also embraces native web design patterns. Like most successful web technologies, it outlines a format that will be both human and machine readable. Just like HTML and CSS, designers and developers should be able to view source and see what’s going on in their fonts using whatever tools they’re comfortable using. Compared to the obscure binary OpenType tables that currently contain metadata, this is an important step forward.
Earlier in the web’s history, attempts to enable linked or embedded fonts have failed. Those solutions were based on proprietary and patent-encumbered technologies which required platform-specific development tools. Instead, we need an open collaborative approach between all interested camps. This proposal will need time to mature and be implemented, but it’s following the right approach.
We’re excited to support these developments broadly in the community; while that happens, we’ll continue to build Typekit’s server-based solution to deliver on those goals today.