This will be great for talented web designers who want to use non-standard fonts, but I know that it'll result in us seeing websites covered in 'grunge' fonts and other illegible crap just because the 'designer' thought it looked cool.
Even though I posted this link, I don't fully agree with the premise. Not only will there be an explosion of "This looks cool" font usage, I'm worried what happens when their servers or their network fails. What about when it slows down due to unforeseen spike in traffic? They haven't talked about the backup options, which scares me.
Also, someone has mentioned that this is really pandering to the type foundries who aren't willing to modify their business models and their licensing to accommodate web usage. Maybe this is a good first step or maybe it's a RIAA thing for the fonts.
"Not only will there be an explosion of "This looks cool" font usage, I'm worried what happens when their servers or their network fails. What about when it slows down due to unforeseen spike in traffic? They haven't talked about the backup options, which scares me."
Since they are using CSS font mechanisms (I think), it will depend on what the CSS engine does. If it completely can't get a font, presumably it'll use the same fallback rules it already uses when you call for a font that isn't there. The interesting question is what exactly the browsers do for such fonts, but my guess is that they would be treated exactly like a script tag in the header, adding something that would have to be downloaded before the page will even begin to render. But, further presumably, the JS they provide and the fonts will be properly labeled with cache control headers so they don't hit the host server on every page load.
"If it completely can't get a font, presumably it'll use the same fallback rules it already uses when you call for a font that isn't there."
The question is what defines "can't get a font completely". Is it a timeout? How long is this timeout? If I spend time and resources to optimize the loading time of my site and the JS script times out getting a font, isn't that lost time for me?
This all feels like a workaround for license issues as opposed to a true solution. Type foundries should let web developers purchase fonts that can be published on the web.
CSS would pick that up and just use the next specified font, presumably. The same way that if I specifed: font-family: {fancy font, Arial} your browser would automatically render Arial.
Comments
This will be great for talented web designers who want to use non-standard fonts, but I know that it'll result in us seeing websites covered in 'grunge' fonts and other illegible crap just because the 'designer' thought it looked cool.
I'm happy and scared at the same time.
Even though I posted this link, I don't fully agree with the premise. Not only will there be an explosion of "This looks cool" font usage, I'm worried what happens when their servers or their network fails. What about when it slows down due to unforeseen spike in traffic? They haven't talked about the backup options, which scares me.
Also, someone has mentioned that this is really pandering to the type foundries who aren't willing to modify their business models and their licensing to accommodate web usage. Maybe this is a good first step or maybe it's a RIAA thing for the fonts.
I thought it was interesting, though.
"Not only will there be an explosion of "This looks cool" font usage, I'm worried what happens when their servers or their network fails. What about when it slows down due to unforeseen spike in traffic? They haven't talked about the backup options, which scares me."
Since they are using CSS font mechanisms (I think), it will depend on what the CSS engine does. If it completely can't get a font, presumably it'll use the same fallback rules it already uses when you call for a font that isn't there. The interesting question is what exactly the browsers do for such fonts, but my guess is that they would be treated exactly like a script tag in the header, adding something that would have to be downloaded before the page will even begin to render. But, further presumably, the JS they provide and the fonts will be properly labeled with cache control headers so they don't hit the host server on every page load.
See how Yahoo serves their YUI stuff: http://developer.yahoo.com/yui/articles/hosting/
"If it completely can't get a font, presumably it'll use the same fallback rules it already uses when you call for a font that isn't there."
The question is what defines "can't get a font completely". Is it a timeout? How long is this timeout? If I spend time and resources to optimize the loading time of my site and the JS script times out getting a font, isn't that lost time for me?
This all feels like a workaround for license issues as opposed to a true solution. Type foundries should let web developers purchase fonts that can be published on the web.
Most likely it is: 1. Load font.
2. Render.
3. Is font available? If yes render, if not, use next font.
If that download is taking forever, I'd imagine the page would render in the secondary font until the Load font command is eventually successful.
Define forever? ;)
CSS would pick that up and just use the next specified font, presumably. The same way that if I specifed: font-family: {fancy font, Arial} your browser would automatically render Arial.
We might see a little font-equivalent of the animated GIF, but for the most part, I think we'll see much better looking webpages.
At the end of the day, the web really is mostly type.