> Of course you can use WOFF2 as a Base64 encoded string:
> ...
> url('data:font/woff2;base64,...') format('woff2'),
> url('data:font/woff;base64,...') format('woff');
Please, pretty please don't Base64 the WOFF and WOFF2 fonts in the same file. That's basically just inflating your font size by a guaranteed 80% or so. A browser supporting WOFF2 is guaranteed to support WOFF!
I'd honestly recommend waiting until WOFF2 support is better before you use them at all unless you have server-side support detection. In a year or so it'll make sense. Now? Not so much. [1]
I do believe you should base64 encode your WOFF fonts and link the others. In fact, I wrote a tool for that (if you are pulling fonts from Google's or some other service). [2]
In a nutshell, this guy explains that the benefit of WOFF2 is that its "compression format offers a 30% average gain over WOFF 1.0", only to go on and demonstrate how to embed both WOFF1 and WOFF2 as data: URLs in the same CSS?
From time to time, I will run my blog through some optimization app, and it will complain about my CSS. I dig deeper, and realize that this app is running my CSS through the W3C CSS validator, which screams at data URLs.
> Think about the correct mime type for WOFF 2.0 files (Google uses font/woff2. W3C recommends application/font-woff2):
Heh. I'm very annoyed there is no official MIME registry for font/. fonts and archive formats abuse the application/ registry. In decades now this hasn't changed. Pretty annoying. Maybe this will be a needed push?
There was a discussion about this on the IETF lists a while ago — in short, there's so much impetus against new top-level types that it's unlikely to ever happen, seemingly, and that the application type was the appropriate place for fonts to go. See the thread starting at https://www.ietf.org/mail-archive/web/apps-discuss/current/m....
It's been the status quo for a long time now — and existing implementations are basically irrelevant (all browsers just sniff and totally ignore any type because of this mess).
So... Silly question, perhaps, but how is it possible that we need to replace WOFF already? Didn't we have TTF and OTF for decodes without needing replacement, and now we need to replace WOFF before it's even used a whole lot? What did the WOFF designers miss?
WOFF is simply gzip plus a header. This works well for OTF fonts where the format is already heavily optimised for low size. However TTF files don't compress as well, particularly the 'glyf' table whic contains the outlines and typically accounts for a large percentage of the file size. WOFF 2 adds a preprocessing stage which rewrites the glyf table into a more compact format prior to gzipping.
WOFF was a minimal format that exists primarily for the sake of getting the large font foundries on-board with webfonts — the aims were very low.
WOFF2 actually tries to incorporate a lot of the work done since TTF/OTF, some of it patented previously. For example, it includes MicroType Express, which is now covered under the W3C patent policy.
I'd honestly recommend waiting until WOFF2 support is better before you use them at all unless you have server-side support detection. In a year or so it'll make sense. Now? Not so much. [1]
I do believe you should base64 encode your WOFF fonts and link the others. In fact, I wrote a tool for that (if you are pulling fonts from Google's or some other service). [2]
[1] http://caniuse.com/#feat=woff2
[2] https://github.com/mmastrac/webfont-dl