Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Typekit

blog.typekit.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Introducing Typekit

#11

Post by ori_b »

jerf wrote: post #9
ori_b wrote: post #6

Thanks, but no thanks. Web pages already assume too much about the way that they'll be rendered -- I have pages looking funny when I force a minimum font size so I can actually read them. I know, it's a crazy idea wanting to read web pages. What can I say? I'm weird that way. I can't imagine allowing custom fonts making this situation any better. I don't want the web to be pixel perfect, I want the end-user to have c…

"I want the end-user to have control over what they see." How, exactly, does this prevent that? What current user mechanism for control over the web pages will this preempt? What is the difference between saying "I don't want this page to be in Arial, I want it to be in Tahoma" and "I don't want this page to be ExoticTypeKitFont, I want it to be in Tahoma"?

Read the first paragraph again -- The problem is that pages start breaking when designers make the assumption that things will be pixel perfect. Allowing them to perfectly specify a font, complete with external references, further supports this [incorrect] assumption.

Re: Introducing Typekit

#12

Post by batasrki »

jerf wrote: post #10
batasrki wrote: post #4

Earlier quoted context omitted.

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…

"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…

"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.

Re: Introducing Typekit

#13

Post by jerf »

ori_b wrote: post #11
jerf wrote: post #9

Earlier quoted context omitted.

"I want the end-user to have control over what they see." How, exactly, does this prevent that? What current user mechanism for control over the web pages will this preempt? What is the difference between saying "I don't want this page to be in Arial, I want it to be in Tahoma" and "I don't want this page to be ExoticTypeKitFont, I want it to be in Tahoma"?

Read the first paragraph again -- The problem is that pages start breaking when designers make the assumption that things will be pixel perfect. Allowing them to perfectly specify a font, complete with external references, further supports this [incorrect] assumption.

Start breaking? This is still no change.

Re: Introducing Typekit

#14

Post by run4yourlives »

This is interesting, but I'm not sure how well it will work when there is already a method (SFIR http://www.mikeindustries.com/blog/sifr/) that works around this licensing issue completely.

I suppose it will really come down to pricing, but they're going to really need to cut into those expected royalties if this is going to fly. It'll be interesting to see if font designers are as pig headed as music labels, or if they can understand that a lessor percentage of a larger total is the better deal.

Re: Introducing Typekit

#15

Post by run4yourlives »

batasrki wrote: post #4
hellweaver666 wrote: post #2

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…

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.

Re: Introducing Typekit

#16

Post by run4yourlives »

batasrki wrote: post #12
jerf wrote: post #10

Earlier quoted context omitted.

"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…

"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…

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.

Re: Introducing Typekit

#17

Post by halo »

Sorry, but a "solution" that involves embedded JavaScript from a 3rd party site is not a solution people will actually want to use.

Re: Introducing Typekit

#18

Post by wysiwtf »

run4yourlives wrote: post #14

This is interesting, but I'm not sure how well it will work when there is already a method (SFIR http://www.mikeindustries.com/blog/sifr/ ) that works around this licensing issue completely. I suppose it will really come down to pricing, but they're going to really need to cut into those expected royalties if this is going to fly. It'll be interesting to see if font designers are as pig headed as music labels, or if…

Those text replacement techniques (sIFR/cufon) have downsides though. You can't manipulate the replaced text as you would normally, you lose some functionality because you've replaced text with flash/canvas/image etc., and you won't see anyone replace entire body text using those techniques.

Using the standard @font-face css technique instead of a text replacement hack allows your custom fonts to have all the same benefits of standard browser text.

Re: Introducing Typekit

#19

Post by mishmash »

run4yourlives wrote: post #16
batasrki wrote: post #12

Earlier quoted context omitted.

"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…

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? ;)

Re: Introducing Typekit

#20

Post by hollerith »

jerf wrote: post #9
ori_b wrote: post #6

Thanks, but no thanks. Web pages already assume too much about the way that they'll be rendered -- I have pages looking funny when I force a minimum font size so I can actually read them. I know, it's a crazy idea wanting to read web pages. What can I say? I'm weird that way. I can't imagine allowing custom fonts making this situation any better. I don't want the web to be pixel perfect, I want the end-user to have c…

"I want the end-user to have control over what they see." How, exactly, does this prevent that? What current user mechanism for control over the web pages will this preempt? What is the difference between saying "I don't want this page to be in Arial, I want it to be in Tahoma" and "I don't want this page to be ExoticTypeKitFont, I want it to be in Tahoma"?

A user who would prefer to see the page's text as quickly as possible rather than to see the text in the font the page author prefers might have trouble expressing that preference with pages that use Typekit's solution. In other words, if the user would prefer to see the text rendered with a font available on the local machine rather than wait for a font to download for Typekit's servers, . . .

More generally, the mentality expressed in the original post (that authors need more control over what the end-user will see) has been bad for end users who want control over what they see without delving into extremely complex details, e.g., the profusion of complexity that is Firefox's about:config.

Post reply on HN