Close and Go BackBack to Viget

jQuery + Type + You.

Doug Avery
Doug Avery , ON THE TOPIC OF Javascript
4/4
2009
13

Once a month, two designers at Viget put together a presentation for the rest of the design team. Sometimes it's on finding inspiration, sometimes it's on new ideas or initiatives, and sometimes it's just a fun little knowledge-sharing presentation.

The following is one of the latter: A simple presentation I put together with some jQuery plugins to demonstrate the various ways jQuery can interact with type on the web.

You can view it here (click the headers to advance slides).

Topics Covered

  • Keeping a vertical rhythm
  • Removing "widows"
  • Ampersands, ligatures & special characters
  • Typographic animations
  • Font detection

Plugins & Links

Steve Love said on 04/05 at 10:59 AM

Nice presentation, Doug. I like the somewhat subtle animation ideas. I definitely will start playing with that a bit.

But is scripting the line-height fix for in-content images really a better solution than just targeting them with CSS? I’m not sure I see the advantage of JavaScript.

And just a couple observations:

1. When I was viewing the “Better” line-height slide (Firefox on Linux) the fix wasn’t being applied until I refreshed the page. This happened every time I visited the page.

2. There’s no way to go back a slide in the presentation other than scrolling up. How old skool. ;)

Thanks again for the ideas!

JP said on 04/05 at 05:08 PM

Hey! Papyrus has some very legitimate uses!

No, not really. But a client (paid upfront) instisted that their new business cards matched the sign on the front of the store. Ugghhh. And I never deactivated it. :P

Doug Avery said on 04/06 at 08:40 AM

@Steve I think the JS advantage shows itself in a CMS, where clients are inserting full-column images or video that push content down. Using CSS, you’d need to add a class based on the actual height of the object (right?) in order to get the space filled up right.

Interesting note about the line-height issue on FF, I think I’ve seem similar behavior in IE6. Will look into it.

@JP I have it activated for similar reasons, so, I feel your pain.

justin hileman said on 04/06 at 11:01 AM

Thanks, I enjoyed the presentation. I’ve been playing with font detection, and one of these days I’m planning to hack together an all-in-one font detection based Cufón fallback plugin for jQuery. Unless someone else gets to it before I do, that is :)

The context of the RegEx post link does make me wonder if you meant to link to my post on jQuery ampersand styling rather than the RegEx widon’t.

Doug Avery said on 04/07 at 07:36 AM

Nice catch, Justin, thanks!

re: Cufon, are you saying the plugin would only activate Cufon if a user didn’t have the font in question? That sounds like a nice upgrade.

justin hileman said on 04/07 at 09:22 AM

That’s exactly what I’m thinking. Cufón is promising, but inconsistent with native rendered text in many of the same ways as sIFR. So I’d like to use local fonts if available, and fall back to Cufón via jQuery font detection.

Okay, I’ll admit: I’m a text-selector. I’m a triple-clicker. Trying to select Cufón or sIFR is infuriating. Don’t judge me. :)

Doug Avery said on 04/07 at 09:44 AM

I like the idea, but it seems like it would only show installed fonts to the minority (example: mac users would see native Gill Sans, Windows would see the cufon version), so it wouldn’t be a huge step forward.

Another way might be by detecting the browser and embedding the font if the browser has that option, but that’s a whole ‘nother problem.

justin hileman said on 04/07 at 10:00 AM

I agree that it’s not the best solution. But using a heavy-handed Cufón or sIFR approach to deliver embedded fonts to everyone seems a bit like forcing [removed]hover emulation on all browsers just because IE 6 can’t hack it.

Maybe a three stage fallback:

First, check if they have the native font. If they do, render native. Alternatively, see if you can embed a font. If so, use this mechanism for font delivery. If all else fails, fall back to Cufón to get the job done.

Actually, thinking about it, it seems that you could assume everyone supports font embedding and just embed the fonts in your stylesheet. If embedding worked, the “native font detection” would come come back positive, right?

Doug Avery said on 04/07 at 10:06 AM

That’s an interesting idea, it would depend on how the detection worked, I guess. I’m not sure, but it seems like that would add to the delay before rendering, since the entire embedded font would need to load before the detection runs.

Olli said on 04/07 at 12:12 PM

Hey guys,

Just found the same topic being covered by Developer Kilian Valkhof: http://kilianvalkhof.com/2009/css-xhtml/combining-cufon-and-font-face/

;)

Cheers,
Olli

Doug Avery said on 04/07 at 01:20 PM

Nice find, Olli! Thanks! I also hadn’t seen the FontAvailable plugin.

mnik said on 04/09 at 12:08 PM

Great presentation. You might be interested in this site we launched last fall. 99% jQuery (the Venn diagram was done in Flash -damn you IE!).
http://www.sparkcapital.com

Doug Avery said on 04/13 at 08:07 AM

Thanks for the link, mnik, that site’s a lot of fun!

Commenting is not available in this weblog entry.

We're The Designers

at Viget Labs. We write about design news, trends, techniques, buildout, inspiration, CSS, and our projects.

What's a-twitter?

Follow us @VigetInspire for updates of the goings-on here or @Viget for more from all of the Viget crew. #thatisall

Recent Comments

@Yannick: Thank you! As for choosing Drupal for the calendar, that’s a question best suited for our partners at Lafayette College. From what I know, I don’t think WP was able to support...

Subscribe to Comments RSS RSS

Contact Us

Have any questions, comments, ideas, or secrets to share? Let us know.


What color is the sky?

Sorry, you need to have Javascript enabled to use this form. (Don't blame us, blame the spammers!) If you'd like to contact us, please visit our Contact page.