This is the archive of version one, made in 2006, launched in 2007, and active until 2012. It’s archived to preserve the original design and its content that was referenced in multiple posts, books and galleries. There’s a holding page before the new site arrives.

Entries tagged with ‘standards’


  1. @font-face in IE: Making Web Fonts Work

    All Hallows’ Eve seems the perfect time for something a little spooky. Getting @font-face working in IE may just be spooky enough. As you probably know @font-face already works in Safari 3 via WebKit and is supported in the latest Firefox 3.1 beta. With IE, that means around 75% of the world audience could see custom typefaces today if their EULAs allowed it. Fortunately, there are good free faces available to us already, as well as some commercial faces that permit embedding. Fontin is one of them and I’ve built it into this example page:

    Before we get into the nitty-gritty of making this work, which you can skip to if you wish, I thought a little history and a brief summary of the current status of the web fonts debate might be useful.

    Web Fonts: Then & Now

    Web fonts have been with us for a decade. They were an original part of the CSS2 recommendation in 1998. Recently, the godfather of CSS, Håkon Wium Lie, brought them sharply into focus with articles in CNet and A List Apart. The ironic thing is, IE has supported web fonts using the Embedded Open Type (EOT) format since 1997. The problem was that EOT was a proprietary format, belonging to Microsoft. Not for much longer: it’s been submitted to the W3C and is going through the process towards becoming a web standard.

    Since the debate opened up, the web and type communities have both been busy discussing how the future will unfold. More collaboration between the disciplines would be beneficial to both, and I’d encourage any interested designers or developers to get involved with organisations like the Association Typographique International (ATypI).

    Recently, Bert Bos of the W3C paid a visit to the ATypI Conference in St Petersburg to meet with type designers face to face. His summary of the current situation is essential reading. The debate has continued apace on the ATypI mailing list, which unfortunately has no public archives. However, if you are member of the ATypI, you can see this summary about the conference panel on web fonts by Nadine Chahine that started the debate in earnest. Simply put, type designers seem anxious about @font-face linking making it too easy to steal a font. Both Microsoft’s EOT format and direct font linking are under consideration with EOT a favourite with many. However, rather than paraphrase a wide-ranging set of opinions, I’d encourage you to join the ATypI yourselves as designers and developers to participate or observe.

    If you have other favourite comments or posts about the future of web fonts, please add them to the comments.

    As a designer, I want a straightforward way of licensing and including fonts for my work. I will pay, respect the rights of type designers as I expect mine to be respected, then get on with the glorious business of merging content with type. It’s not as simple as it sounds, though. The licensing of fonts, and the protection of the rights of smaller designers in particular, is a sticky issue. DRM does not work, so what then? Richard Rutter has shared thoughtful insights which are very much worth a read. My view is that I would be perfectly prepared to pay a separate or extra licence fee to use quality fonts on the Web. I would have no problem selling this to my clients. Embedding or linking to fonts has to be straightforward though. I get paid to think about, plan and implement design, not grapple with obstructive software (more on that later). If fonts were delivered through a third-party web service as Richard suggests, the one proviso must be that it would have to be done by someone who knows exactly what it means to scale a service for millions of users. Like most designers though, I have very little knowledge of the real security and scalability issues, but hope to see a comment from a real security expert, shortly.

    User agents are currently taking divergent routes. Bert Bos’ summary reports:

    Mozilla has stated that they don’t want EOT. But they are not opposed to letting the browser check the license, as evidenced by the proposal to let HTTP headers carry license data.

    Microsoft has said that it is impossible for them to support linking to native OpenType as long as font vendors oppose it.

    Apple’s Safari has implemented font download with no checking of licenses. They said they are against EOT, but would not be against browsers checking licenses, e.g., using Mozilla’s proposal.

    Opera remarked that there are more existing and announced implementations for downloading native OpenType than for EOT. They conclude that the market apparently doesn’t need EOT and thus they see no need to support it themselves either. W3C’s limited resources should be spend on more important standards.

    That means that designers and developers have the same perennial problem: Two different implementations to achieve the same result. Safari 3 and Firefox 3.1 beta both support direct linking to OpenType (.otf) font files. Presumably Opera will soon. Only IE 4 to IE 7 support Embedded Open Type (.eot) files. IE8 does not, but will at some point. So, to see Fontin display in standards complaint browsers like Safari 3 and IE, we need to provide two separate fonts.

    @font-face Example

    The @font-face example uses Fontin Regular by Jos Buivenga — a free face kindly provided by Jos with a licensing permitting embedding with attribution. Jos also has many other fine faces available via his foundry site, Exljbris. The example is a quick one using a traditional scale, with all of the CSS available in the <head> of the file.

    1. Set the basic font-family:

      h1, h2, h3, p, td{
      font-family:'Fontin-Regular', georgia, serif;

      Notice the 'Fontin-Regular' name — this is an arbitrary name that can be whatever you like. All it does is tell the browser when to apply the font file referenced in the @font-face rule.

    2. @font-face and .otf for standards compliant browsers:

      Ed: White space inserted for clarity.

      src: url('Fontin-Regular.otf') format('opentype');

      Note the 'Fontin-Regular' name, again. This rules basically tells the browser, when the @font-face is set to 'Fontin-Regular', use the font found at this URL.

      Screen sample of Fontin Regular in Safari 3 set at 16px with 24px line height from the example:

      Fontin in Safari 3

      When Safari renders the page, it will look for the font file, then render the text accordingly. There’s a slight delay as WebKit works. In the example you might notice that the text not requiring the loading of a font file renders quickly, but the rest is blank until the browser catches up. For reference, the Fontin-Regular.otf file is 32KB in size. Some font files can be much larger.

    3. Create the .eot file with WEFT:

      To do this you will need to download and install WEFT3, a Microsoft application for creating EOT files from TT fonts. WEFT is not able to create EOT files from an OTF. It must be converted to a TrueType file, first. WEFT is the only tool for this as far as I’m aware, although I believe there is an open source one in development. If it wasn’t for WEFT, embedding EOT files would be easy. What I want WEFT to do is convert the font to EOT, and allow me to create a subset if required. It does that, but in a nightmarish, frighteningly over-complicated way. Perfect for an All Hallows’ Eve entry. Here are a few tips I learnt the hard way:

      1. WEFT requires the URL of the page or site where the EOT font will be used. It will then ‘scan’ the pages by crawling the site to see what glyphs are used and try and create a subset of the EOT file accordingly. If it refuses to analyse a valid URL as it did for me, get granular and specify pages or sub-directories in your information architecture.
      2. If you’re using WEFT via Parallels and XP Pro, it may refuse to add some fonts in your windows/fonts directory to its database of available fonts. Try using a standalone PC if you can. I haven’t tested in any other virtual machine.
      3. Use the wizard to set up your project, but after that try it manually using the View menu item to see what fonts are available to convert, and the Tools menu item to convert them.
      4. WEFT will try to save the EOT file to a remote location. You can over-ride this manually to save the file wherever you please for you to upload yourself.
      5. Disable your original OTF fonts on your system before testing (obvious but worth a prompt).

      Be warned, WEFT is awful to use, in every way. It did not work for me running Parallels with XP Pro on a Mac. 7th Nov: After more experiments, Weft will accept TrueType (.ttf) files in Parallels. It also worked with the gracious help of Jon Gibbins and his standalone PC running XP Pro. Because it is so painful, I cannot give support for WEFT. You can try the Microsoft WEFT user community, but I can’t comment as to its usefulness, and I could not find any other support avenues.

      Hopefully, you now have an .eot file to use.

    4. @font-face and .eot for IE using conditional comments:

      Ed: White space inserted for clarity.

      <!--[if IE]>
      <style type="text/css” media="screen">
      src: url('Fontin-Regular.eot');

      These are screen samples from IE:

      Screen sample of Fontin Regular in IE6 set at 16px with 24px line height from the example:

      Fontin in IE6

      Notice the bar missing from the capital ‘A’ towards the end of the second line. The tyepface designer, Jos Buivenga is currently looking into the font hinting, with input from John Boardley.

      IE7 sample:

      Fontin in IE7

    See a full size Safari 3 screenshot, and IE6 screenshot on Flickr.

    That’s all! Try the example in different browsers to see how it works for yourself (but please don’t blame me for ClearType’s poor anti-alias at larger font sizes).


    We have only a few web fonts with a EULA that permits embedding right now, unless they are free. Please respect the EULAs of any typefaces you try out until the type community resolves the issue for all commercial fonts.

    My feeling after doing this is that EOT has potential advantages in file size over OTF, but OTF files could always be edited (as far as I’m aware) to create subsets just like EOT. Although EOT is not a DRM solution per se, it feels like one. If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long.

    What we need to encourage designers and developers to use EOT today is a good tool to create EOT files in the first place. Perhaps even one hosted remotely, where we can buy a licence, convert the font to EOT, grab the same OTF subset for complaint browsers, and get the work using the typefaces we’ve always dreamed of. WEFT is not the tool right now to enable EOT usage. In fact it discourages it.

    Regardless of what security is implemented, the font file will have to be on the audience’s machine somewhere, even temporarily. ‘Defense in depth’ is a term used by web app security experts. It would seem that the question is how much depth will satisfy foundries and type designers, and what form that depth will take.

    As a designer, I can only speak for myself to say that if OTF and TTF were supported, regardless of how easy it was to steal the file, I would still pay as required by the EULA. I have a strong feeling the vast majority of my colleagues feel exactly the same.


  2. Typeface != Font

    Typeface and font.

    A typeface is not a font. A font is not a typeface. It’s been said before, but confusion still resigns supreme; even the Online Etymology Dictionary and the holders of the rights to Georgia get it wrong. So, at the risk of stating the obvious, but in the hope that someone might find this useful, I’m going to attempt a little disambiguation.

    Define: Typeface

    A typeface is designed by a type designer. I think of a typeface as the design of a type family. Like every family, type families have names. An example of a type family name is Georgia. Georgia is a type family — a typeface — not a font.

    Typeface = a type family’s design

    In many non-European cultures like the Chinese, the family name comes before the personal name. For example, my Chinese name is Tan Tek Whah. “Tan” is my family name. “Tek” is my generation name. “Whah” is my first name. The last two are identify me personally. The same is true for fonts. They have a family name (typeface) and personal names (style, variant, size) that identify them uniquely within that family.

    Define: Font

    To understand why a font is not a typeface, it’s useful to know where the term came from. Here’s a (very abridged) bit of history drawn from various sources:

    Font (or previously, fount) is derived from a Middle French word, fonte, meaning something that has been melted. In type founding, metal was melted then poured into a hand mould with a matrix, to cast each individual piece of movable type, known as a sort. Font, fount and fonte have a common ancestor in the Latin word, fons, meaning spring or source (of water). They are all related to the word, fountain. So, now you might be able to see why “font” is a word that describes a variant of a typeface, and a container for casting water on Christian babies’ heads.

    Everytime a specific variant of a typeface was cast at a specific weight, a font was created. Therefore, a font is a particular casting of a typeface belonging to that type family. In electronic publishing nothing is cast, but fonts are still digitised from the design created by a type designer.

    Font = one member of a type family

    In my mind I think of a font as a variant of a typeface.

    Spot the heading error in the Georgia page by Ascender Corp, licensees of the Georgia typeface.

    Using the Georgia typeface example, the “Georgia Regular”, “Georgia Italic”, “Georgia Bold”, and “Georgia Bold Italic” in my library are all fonts of the Georgia typeface.

    Wait though, we’re not done! A font was more granular than just the variant of a typeface: Each size of those variants would, historically, have being cast individually. Therefore, a font is actually any variant in a typeface’s size and style. For example: “9pt Georgia Bold Italic” is a font as is “12pt Georgia Bold Italic”, and “9pt Georgia regular”.

    Electronically evolved terms

    These days, rather than casting specific sizes, we hit a button and the typeface variant changes size. Size has ceased to be so important because changing it has become so easy, and we don’t have to buy typefaces at different sizes. So these days, even people who understand clearly what the word “font” means have been known to use it to just describe a variant like Georgia Italic, or Helvetica Bold Condensed Oblique without reference to a particular size. That seems like a fairly logical evolution of the term to me.

    Why is this stuff important?

    Well, compared to world peace, it’s not. However, nomenclature is important because being understood is important. Struggling with my own ironic typos and awful spelling makes me doubly aware of this. There’s another reason too. I’ve been delving into the font module of CSS for a series of articles and reminded myself how confused the terminology was. The absence of the term, “typeface“ and certain uses of “font”, seemed strange to me; font-variant in particular makes no sense.

    Hopefully this explanation makes a little more sense, or at the very least, gave you an insight into Chinese naming conventions.


  3. Typographers, lend me your pain

    Dear web typographers and designers, I need your help (and your woes!) A couple of days back, Jason Teague, Director of Web Design for AOL Global Programming and member of the W3C CSS3 Working Group made a request for input from designers around the CSS fonts and CSS web fonts modules. He has volunteered to be an advocate for them, and wants our thoughts and feedback on the way forward. It’s a welcome move, and a veritable bag of snakes he’s opening, so congratulations to Jason for volunteering to take the pain. I think we should help him out.


    For my part, I’m planning to respond in detail, supported by a few test cases and examples of current rendering. Wish lists are great, but I think empirical evidence is more useful when identifying current issues and areas for improvement in the recommendations. So, if you’re a web typographer or designer and have come across problems or issues that might be worth cataloging, let me know what they are. I’ll promise to try and put together a test case and convert anecdotes to science if I’m able. Alternatively, you can just throw your thoughts into the comments for Jason’s article.

    As an example of what I think might be useful, I’m planning on discussing classic type setting techniques that are either badly supported or absent like old-style versus lining versus small-cap numerals, raised or drop caps, granular glyph weights, ligatures, baseline fixing, etc. I’ll also be mentioning browser-specific hacks I use to achieve better rendering like setting a miniscule opacity value in Firefox on OSX to de-bloat the glyphs and improve larger-size anti-aliasing.

    What do you think?


  4. Preparing for HTML5 with Semantic Class Names


    Some time ago I was asked in an interview whether I preferred HTML or CSS. It was a bit like being asked if I prefer pens or pencils. I made an instinctive choice. I chose HTML. It’s the typography of data; the inflection in our voices; the grid of meaning upon which presentation can flourish. I find it beautiful when done well, and that’s why watching HTML 5 unfold with new and refined elements is fascinating to me.

    This is a brief introduction to the new structural elements in the HTML 5 Working Draft, and how to use semantic class names in HTML 4.01 or XHTML 1.0 markup that correspond to the names of those structural elements. By doing so, you’ll get a head start in understanding how to use the new elements and also go some way towards using plain old semantic HTML if you’re not already.

    i. Introduction

    HTML 5 will be the first major change to our lingua franca since XHTML 1.0 in 2000; some might say HTML 4.01 in 1999. You’ve probably already seen the HTML 5 Working Draft of the 22nd January this year. The W3C HTML Working Group and WHATWG have been grafting away on our behalf, and trying to satisfy everyone in an open process. Not an easy task. Sometimes, amongst the concerns and the questions it’s easy to forget that, so I’m taking a brief second in between sips of coffee to acknowledge the hard work. Thanks, folks.

    Let’s get to know these new structural elements a little better. If you’d rather go straight to the horse’s mouth before continuing I recommend a comfy chair, and a perusal of HTML 5 differences from HTML 4, edited by Anne van Kesteren. W3C documents seem to be getting easier to read, and this is no exception. If you’re sticking with me for a while, let’s get to it:

    ii. The <header> Element

    The header element is for page or section headings. Not to be confused with a traditional masthead, which often holds just a logo mark, it should also contain one of <h1><h6> in hierarchical rank. It could also contain meta information for that page or section of a page like “last updated”, a version number, or blog entry information like published date, author, etc.

    A simple example for a page using a semantic class name that corresponds to the HTML 5 header might be:

    <div class="header">
    <h1>Page Title</h1>

    You could include the logo mark and other meta information within the layer. The next example for blog articles includes author and published date information (as well as an example of referencing the section and article elements with semantic class names):

    <div class="section">
    <div class="article">
    <div class="header">
    <h1>Page Title</h1>
    <p>By <a href="*">Author</a> on [date]</p>
    [Article content…]
    <div class="article">
    [Repeat as required…]

    iii. The <nav> Element

    The nav element should contain a set of navigation links, either to other pages, or fragment identifiers in the current page. Referencing it with semantic class names is simple:

    <div class="nav">
    <li><a href="*">Menu item 1</a></li>
    <li><a href="*">Menu item 2</a></li>
    [Repeat as required…]

    iv. The <section> Element

    A section element defines a section of a page or a distinct piece of content. It would ordinarily have a header and possibly a footer. This is how we could represent it using semantic class names:

    <div class="section">
    <div class="header">
    <h2>Section Title</h2>
    [Section content…]

    I’ve also been using <div class="section"> to define a group of layers that are related (like news and events). In such an example, those sub-sections would be nested, each with their own <h1><h6> in rank order to maintain heirarchy. For example:

    <div class="section">
    <div class="header">
    <h2>News and Events</h2>
    <p>The latest announcements and upcoming conferences</p>
    <div class="section">
    [Section content…]
    <div class="section">
    [Section content…]

    Each section could also have a layer with a semantic class name of header if the content made it necessary.

    v. The <article> Element

    This is how the HTML 5 working draft explains article element:

    “The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.”

    Multiple article elements can also be nested. We looked at the example of a series of blog posts using semantic class names in the header section. This is an example using semantic class names in a unique article page with header and footer:

    <div class="article">
    <div class="header">
    [Article content…]
    <div class="footer">
    [Footer content…]

    vi. The <figure> Element

    The figure element contains embedded media like <img> and the new elements of <audio> and <video>. It also contains an optional <legend> element performing the function of a caption. Our semantic class name version could be like so:

    <div class="figure">
    <img src="*" alt="*">
    <p class="legend">[…]</p>

    vii. The <dialog> Element

    The dialog element replaces a <dl> to contain converations like transcripts. Using it as a semantic class name is straightforward:

    <dl class="dialog">
    <dt>Speaker 1</dt>
    <dd>So I said to him, I said…</dd>
    <dt>Speaker 2</dt>
    <dd>You never. You did? Oh my…</dd>

    viii. The <aside> Element

    To quote the working draft:

    “The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.”

    I’ve been using “aside” as a class name for sidebars with mixed content, but my reading of the draft also indicates it may also be appropriate for pull-quotes and anything partially related to the main content, but not of it. See the sections relating to the ins and img elements for examples. It woud seem appropriate to use it with a semantic class name like this:

    <div class="section">
    [Section content…]
    [Repeat sections as required for main content…]
    <div class="aside">
    [Aside content…]
    <div class="footer">
    [Footer content…]

    This is what the working draft has to say:

    “The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.”

    In the changed elements section of HTML 5 differences from HTML 4, it also explains that, “The address element is now scoped by the new concept of sectioning.” This is important, because now, if you have multiple sections in a page, each can have both a header and a footer with a corresponding address in the footer for each if you deem it necessary. However, that would seem to be a rare use-case. Let’s stick with a more common one: A single footer for each page with a single address element; here’s how it might be done using a semantic class name:

    <div class="footer">
    [Other footer content …]

    x. Multiple Class Names

    Let’s recap a little: By using semantic class names, we give the information a semantic boost, and each chunk of related data is self-contained. However, it may have become obvious to some designers reading this that a side-effect of using this method, and eventually using HTML 5 elements themselves, will be lots of different content within containers of the same name. <div class="section">, for example. You might want to present different content very differently in the browser. Multiple class names will enable you to do that. class="section" can becomes class="section news", or class="section services". The "section" class name allows us to standardise some of the presentation; say, typography for example. The "news" class name will allow us to present it differently as a section variant.

    So now we have the best of both worlds; the critical structural elements are included by default with more semantic class names providing hooks to apply our creativity to.

    xi. End Notes

    Bear in mind HTML 5 is a working draft so there will probably be some changes before it becomes a recommendation. It would seem unlikely that any of the new structural elements will be removed, but a sharp eye on the draft updates might be a good move.

    Any errors in this article are my own. If you some across any, please let me know and I’ll make corrections.

    xii. References & Further Reading

    1. References:
      1. HTML 5 Working Draft
      2. HTML 5 differences from HTML 4 and specifically, the new structural elements section
      3. Semantic class names
      4. Plain old semantic HTML (POSH)
      5. <header>
      6. <nav>
      7. <section>
      8. <article>
      9. <figure>
      10. <dialog>
      11. <aside>
      12. <footer>
    2. Further Reading:
      1. A Preview of HTML 5 on A List Apart by Lachlan Hunt
      2. HTML 5 Latest Working Draft at WHATWG
      3. WHATWG on Twitter
      4. W3C HTML Working Group


  5. Adios, IE8 Meta Mayhem!

    I’ve been holding back on a comment on the recent furor about the IE8 meta http-equiv switch. Mainly because the great and the good had it covered, but also because there was already a possible workaround, which John Resig pointed out: Use a HTML5 DOCTYPE.

    Dean Hachamovitch and the IE team put out the fire yesterday with a switch of their own:

    “We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can.”

    Great news! Now the legacy application vendors using IE as the platform, and relying on less-than-perfect rendering will bear the burden of telling IE which rendering engine they need. (Another radical idea might be for folks who are refactoring applications to use conditional comments like any good self-respecting developer should.) At least, with this announcement, the folks producing standards-driven code will not face the bizarre requirement of having to tell IE8 to not use IE7’s rendering engine. Makes sense to me guys, what took you so long? OK, the problem is more complex than that. After all, as Nigel Parker of Microsoft pointed out in his follow-up post to Kiwi Baacamp where he entered the debate:

    “Microsoft’s view [is] to support backwards compatibility for at least 10 years…”

    By anyone’s measure that’s a hefty commitment, and probably leads the field for backwards compatibility. Even more so when you consider that most new “killer apps” are targeted at the cool kids using the latest OS or browser, and often don’t work without Javascript. (Nudge, nudge Twitter.) A fact that always concerns me when you consider that “universality” is at risk of becoming a hackneyed word, and there’s a whole world out there getting online, often with less money than we spend on Starbucks, and the equipment to prove it.

    Anyway, I digress. Congratulations to the IE team and the collective intelligence in our community for reaching scientific solutions, intuitively. It just goes to show all the cynics out there that, as well a flaming each other, we also have a rare capacity for collectively recognising Robert M Pirsig’s metaphysics of quality.


  6. What Future for Web Typography & Screen Fonts?

    The browser wars of yesteryear were a frustrating period for anyone working on the Web. We’ve come a long way since then. Following the vanguard of Opera, Safari and Firefox, IE8 will be the first Microsoft browser to pass the ACID2 test when it’s released in 2008. Congratulations to the IE team! 2008 may well be a seminal year for Web standards.

    However, the same might not be said for Web fonts. While we have commonly supported standards with which to author information for the Web, we still only have ten core Web fonts to present it, with six most commonly used. There are hundreds if not thousands of outstanding typefaces. A few are shipped by Microsoft, Apple and Adobe with their software, allowing us to use them with font stacks. That leaves a multitude of beautiful, important typefaces that can only be used as text in images or with kludges like sIFR. The current situation is like the browser wars, or perhaps, the type wars.

    In a world where the Web is the platform, having ten core Web fonts makes no sense. It stifles innovation in the same way that poor Web standards support used to.

    The core Web fonts, then & now

    The Microsoft core Web fonts project was started in 1996 and discontinued in 2002. To put that in context, 1996 was the same year that Internet Explorer 3 was released with a CSS gallery to test IE3’s first tentative implementation of W3C CSS.

    Today, the core Web fonts remain in stasis. Apple have renewed the license with Microsoft this year but there are no plans to expand either the typefaces or the font variants. Back in 2006, Andrei Herasimchuk made an excellent proposal closely followed by Jeff Croft’s own worthy suggestion, both of which have unfortunately not come to fruition.

    Other Web fonts with @font-face

    More recently, Web fonts and the @font-face CSS property have come into focus. Håkon Wium Lie’s article on A List Apart started some valuable discussions. Ascender also recently announced new licensing for Microsoft faces which could apply to downloads, and the observations of people like Richard Rutter give us all hope for the future.

    However, as people have already mentioned, @font-face support is not a reality yet and there are questions over support across platforms that have not been addressed. Think mobile phones for example. End-user license agreements (EULAs) will need careful consideration and the methods of protecting type designers’ and foundries’ rights are still a matter for debate.

    Universal Web Type

    If the Web is the platform, and browsers are the gateways to it, then we don’t just need standards for layout and object rendering, but also a standard type library that is universally available to all, with a mechanism to allow new faces to be added over time.

    This is not an alternative to @font-face—there will always be a place for very specialist typefaces for specific uses—but it is a compliment to it.

    I would like to invite you to contribute how you think this might work. This is how I see it:

    1. Organisation: We should form a grass roots organisation to provide universal Web type. It could be part of, or complimentary to the Web Standards Project and the W3C. It would reach out to, and include anyone who has a stake in implementing, creating or using Web fonts.
    2. Structure: The organisation should be co-operative and democratic, with membership open to all. Intellectual copyright and assets would be jointly held by the group on behalf of everyone.
    3. Purpose: The group would strive to find common ground between all stakeholders to research or support common standards, find funding to create a font library with complete typefaces that would be freely distributed.

    The group could be funded by a mixture of micro-finance, donations of time and money, public funding and sponsorship. It would also affirm the right of type designers to proper remuneration for their work, and foster recognition of type’s importance to the Web.

    I’m deliberately publishing this idea to elicit your feedback and comments. The way forward is not clear, and I do not claim to have the answers, but I believe that between all the interested parties—whether individuals, companies or organisations—we have the ability to give everyone a better typographic experience.


  7. Opera sues Microsoft over Web standards in the EU Court

    Opera and Operati, I love you! There’s a crate of cider at my place if you want to swing by and pick it up. Yesterday, Opera filed an anti-trust complaint in the EU court against Microsoft:

    First, it requests the Commission to obligate Microsoft to unbundle Internet Explorer from Windows and/or carry alternative browsers pre-installed on the desktop. Second, it asks the European Commission to require Microsoft to follow fundamental and open Web standards accepted by the Web-authoring communities.

    Read the Opera press release and treat yourself to a smile. They rely in part on the recent decision taken by the court against Microsoft over bundling MediaPlayer with Windows. Opera accuses Microsoft of stifling innovation by embedding a browser than does not support Web standards as it should. All true. How many compromises, hacks and tweaks have we made over the years for Billy Gate’s browser?

    Of course, if this suit was successful Opera would have a better opportunity to grab themselves some market share. Good on ’em. If Opera had a stripped down version of the browser, but with tools akin to Firebug or Chris Pederick’s Web developer toolbar it would be my primary browser, right now.

    Co-incidentally, I’m just about to pay Microsoft for the priviledge of a new copy of WinXP, all because I can’t run multiple copies of IE for testing on Vista easily. Imagine a world where we could run multiple versions of IE without clever hacks. A world where IE passed the Acid2 Test (like Opera) and conditional comments and IE specific style-sheets became a relic of history. I’m almost salivating at the thought.

    There’s a long way to go before that happens. I’d like to think that Billy’s browser would of made it to the point of goodness regardless but, if Opera’s action helps it along, so much the better. It’s just a shame these kinds of actions seem necessary. Then again, Kim Stanley Robinson’s idea of revolutions by law in Pacific Edge always seemed much more preferable than any other method.

    Good luck to them!