About “Caring about OpenType features”

Today I published Caring about OpenType features, a new Typekit Practice lesson. I am listed as the author, but I had tons of help. I have been trying to get this lesson right for more than a year. There’s plenty I could improve, but we’re off to a good start.

Thank you to Jason Santa Maria, for the inspiration to focus. This lesson concentrates on specific typographic jobs, in order to narrow the scope of applicable features. In so doing, the value of OpenType features is clearer.

Thanks to Matt Ephraim, Wenting Zhang, Bram Stein, Jake Giltsoff, and Sally Kerrigan for working directly with me on the nuts and bolts. (Let’s celebrate when we get together in January.)

Thank you to the type designers who make OpenType features part of their typefaces, at times adding tremendous value and advancing the state of the art in useful and experimental ways.

Thanks to the designers and engineers on the Adobe Type and Typekit teams, who answered my questions about how OpenType features work.

Here’s why publishing this lesson was hard, and took a while:

1. OpenType features need to be present to work. (Surprise!) Figuring out which features are in which fonts is a hassle. Thanks to Gregor Kaplan for lots of work earlier this year to expose feature tags in the Typekit kit editor and make OpenType features available in any subset.
2. Using OpenType features in CSS, and getting the syntax right, is complicated at the moment. I had to understand that and write about it somewhere so I could leave those technical details out of this lesson. Thanks to Liz Galle, Jake, Sally, and Bram for working with me on that help documentation.
3. Not all browsers support all OpenType features. Even if a browser “supports” the CSS font-feature-settings property, it may not support all values. Thanks to Bram for making The State of Web Type. That information needed to exist for this lesson to happen.
4. We designed the UI for toggling these features on and off. That was fun. Consider this a first iteration. I hope this contributes to our industry’s discussion about designing better OpenType feature user interfaces. Thanks to Jake for designing this with me (and for the SVG magic — look at that little rotating gear!). Thanks to Ivan Bettger, Christopher Slye, and Paul Hunt for their critical eyes.
5. Developing this myself, in spaghetti JavaScript, would have been a nightmare. Thanks to Brent Getlin and Matthew Rechs for bringing in Wenting. Thanks to Wen and Matt for implementing a nice, clean code framework for Practice lesson examples. Thanks to Bram for continually working to optimize the site.
6. Knowing that OpenType features are actually working in a reader’s browser is really important when you’re trying to explain what features are and why they matter. Thanks to Bram and Miguel Sousa for working on a new JavaScript library called “TryOpenType” (we’re hoping to open source this). It gauges browser support, like The State of Web Type, to help us respond in cases where OpenType features don’t work. View the lesson in Safari to see what I mean.
7. This Practice lesson introduces a new “Send to CodePen” button. However you decide to manipulate the examples, you can pick up where you leave off over at CodePen. Thanks to Bram for making this work, and thanks to the CodePen team for this great feature.

Phew. I probably missed somebody. Many thanks. I loooove working on Practice. I hope you love reading it and trying the examples. Thanks for practicing with me.