Show HN: Kerning.js — Take control of your web typography | Hacker News Reader

Show HN: Kerning.js — Take control of your web typography

endtwist.github.com

154 pointsendtwist30 comments

This library is misusing vendor prefixes :(... -webkit-* should be an area for WebKit to define custom CSS property, not for this library to tag things "only if using WebKit". If WebKit eventually decides to experiment with a word-color CSS property this is just going to cause problems.

Instead, to fit with the standard way people define CSS properties, this library should be taking a prefix for itself, like -kerning-*, and then defining any of its extensions to CSS within that namespace: that way it is almost guaranteed to not cause problems going forward.

Nice work. I like how it all stays declarative in the CSS too.

I would recommend outsourcing your parsing though. It's a tough job and things like CSS hacks can really take your regexes for a loop.

I'd recommend trying out http://glazman.org/JSCSSP/ or https://github.com/nzakas/parser-lib/tree/master/src/css which Nicholas uses for CSSLint.

I evaluated JSCSSP (didn't know about Parser-lib), but was trying to keep the file size down to a minimum.

Though perhaps not the most robust, the library I'm using now (http://bililite.com/blog/2009/01/16/jquery-css-parser/) seems to work fine with all of what I've thrown at it. It is also, by far, the smallest of the three CSS parsing libraries (14kb vs JSCSSP's 165kb).

Do people use things like this?

I recently read Robert Bringhurst's excellent Elements of Typographic Style, but have no idea how to apply it to the web.

(There is an effort to translate the work at webtypography.net, but frankly, most of the sections are some equivalent of "you should do X, but X is not possible right now, but maybe with some CSS extension in the future X will be possible.")

It seems like maybe we have choice of fonts now (through TypeKit, Google Web Fonts). But kerning and justification seem to be mostly accomplished through these sorts of JavaScript hacks, and text figures seem outright impossible. What is a wannabe typographer supposed to do on the web with current tools? Are lettering.js, kerning.js, kern.js, linebreak.js and similar usable or just experiments?

More generally, what does the current web typographer's toolbox look like at the moment?

Don't use this for anything more then a playful lib. It's fun, and it's helpful for defining what browsers might want to do in the future, but its a toy, like a fisher price hammer.

Actually, there's no reason you can't use this on a real site. Sure, you don't want to use it on a long block of text, but it's great for headers and short copy. It doesn't break anything and the "fallback" if it doesn't work is just unkerned copy.

Yea, but there is flash of un-styled content. There is no way around it because the style has to be applied by the javascript. That is not production ready in my opinion. The way standards bodies work now though I think this a great way to demo what browsers should be able to do.

I should note this in the documentation, but if you add "visibility: hidden" to your content, it will automatically be set to "visibility: inherit" after it's ready.

You’re asking excellent questions.

Basically, your doubts are well founded: you don’t have very much reliable control over typography on the web.[0] Things like kerning.js are probably best regarded as admirable proofs of concept for future work.

You’re also right that webtypography.net is limited by our technology, but I think it’s also limited in its approach. ETS is a wonderful book,[1] but it’s really about print typography, and few of its practical guidelines are both possible and wise to apply directly to the web.

TypeKit is pretty good. Google Web Fonts is kind of a disaster from a fine typography viewpoint. Some of the fonts are nice for headlines, but last time I checked there isn’t a single text typeface which is reasonably attractive, kerned well, and has a real italic. Not one. There are some good decorative faces in there, but no drop-in Verdana replacement.

And text figures? Pffft. Small caps? Double pffft.

Here are some things that you have control over and are worth worrying about if you’re interested in web typography, in no particular order:

— Get past ASCII. Use real dashes, quotes, and apostrophes. Don’t put too much trust in automatic curly-izers, even when attached to reputable projects like Markdown.[2] And so on.

— Design on a grid. Set CSS’s line-height property by hand, or you’ll have interfering vertical rhythms. I like to set h1-6’s line-height to an even multiple of the base, but some people would consider this overkill. Set the sup and sub element’s line-heights to 0px or else they’ll screw with the leading. And so on.

— Think about how people actually read on screens. For example, on my screen, reading on full #ffffff is slightly uncomfortable after a while. People with wide screens will get ridiculously long lines if you don’t set a width to something sane like 60em. And so on.

0. Before someone says that this is a good thing because content and presentation should be separate, let me point out that we’re talking about presentation defaults here. No one wants to force everyone to see (or be screen-read) exactly the same thing. If we had some support for things like kerning in CSS, they would stay in CSS and be expected to degrade gracefully.

1. So good that I recommend it as an example of manual-writing to people with no interest in typography.

2. I’ve written about the problem of automatically curling apostrophes at http://rheme.net/apostrophes . In short, it’s hard to have a simple and fast algorithm that corrects the apostrophes/quotes in both:

    She said "I like rock 'n' roll".

and

    He said "I have a 'friend' who does too".

This is the kind of thing that only people who care about it will care about.

I recently read Robert Bringhurst's excellent Elements of Typographic Style, but have no idea how to apply it to the web.

You may find this interesting: http://webtypography.net/toc/

So, just to get this right; to use this script, you'd have to know your content, right down to how many words each text element contains and so forth? The exception being the pairings and repeats. If you already know your content that well (ie. it's static and not any form of user input), you could just add some extra inline elements to your markup, I mean, you're already heavily customizing the text elements.

This is perhaps more elegant, but it makes your CSS too tightly bound to your content. Add a word in the markup, and you'll have to update your CSS as well, with a none or whatnot.

By all means, nice work, I just rarely work with pages where I know how the content will turn out.

Edit: Fixed a typo.

my thoughts, some of the examples are way more elegantly solved using markup than with complex CSS rules. That is not to say that you cannot do that with this library: just define a few extra classes and wrap the individual words, letters etc. in spans or something. I think they just went a little overboard with their examples.

Speaking of kerning, here's a simple CSS declaration for modern browsers:

    text-rendering: optimizeLegibility;

... which will give you improved handling of kerning pairs and ligatures.

see: http://www.aestheticallyloyal.com/public/optimize-legibility...

Completely broken in Firefox, takes ages to load in Chrome. Can't imagine why anyone sane would want to use this library if the cost is so severe.

Doing it declaratively through css is nice, but it would be nicer if it used vendor prefixes correctly to avoid namespace collisions instead of misusing them the way it does.

What's the performance penalty for wrapping every character in a span? Is it meant for titles only (honest question)?

Pretty sure everything about this library is terrible for performance. I cringe to say this, but I might even recommend using images of text over this.

So, to style the 235th word in a text, I'd have to do #main { -letter-size: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .... 0.5em; }

Why wouldn't I simply wrap it in a span, then it even works on browser with JS switched off. Uh, and once I have to edit the copy and add a single word somewhere, everything breaks.

Is there some reason you wouldn't just put it in a span and style that? Just because you CAN specifically target the 235th word in a text doesn't mean that you have to, or that you necessarily should.

I can think of a few instances where I could have used the ability to target a specific letter in the past, specifically as it relates to logotypes or branding, but none that involved targeting the 235th letter.

Does wrapping everything in spans and divs impede SEO in any way?

i.e. Google aside, does Bing and other crawlers interpret:

Perfect

To be the same as:

perfect.

Also...

SPANNITY SPANNNN SPANNITY SPANNNN

Google's crawlers don't really interpret JS, so they won't see all the extra span tags that this script applies. In other words, Google should interpret the header on the demo page as:

    <header>  
        <h1>Kerning.js</h1>  
        <h2>Take control of your web typography.</h2>  
    </header>

Check out http://stackoverflow.com/questions/2061844/does-googles-craw... for the usual caveats.

Search engines certainly should interpret it that way, but I think the point was to question whether they all (for someone value of "all") really do do it that way in practice.

Great library, great work - kudos to you for tackling a very tricky subject (I'm staying well away from CSS parsing and typography ... for now)

My only concern is whether this is (in startup lingo) a painkiller or a vitamin - as in, this is really nice to have, if you're that worried about kerning, but perhaps not enough of a pain-point for designers and developers to warrant learning a new set of nested and prefixed CSS rules, just to do something that's possible to hack together on a case-by-case basis with something like lettering.js...

Perhaps if there's a way to simplify the syntax or provide easy copy-paste examples, it'll remove the barrier to entry?

Still, applaud the work and the code looks great.

Not very cross-browser, is it? Even the page itself lays out entirely wrong on Opera.

I'm not surprised it doesn't work in Opera, and I wouldn't hold it against the library. I don't (personally) know a single user of opera or developer who tests on it. This is a shame, but somewhere along the line, opera dropped the ball and fell into obscurity.

Apparently doesn't work with no-script, even when allowing the whole page. I suppose there is some cross scripting going on? Or is it because my iceweasel 3.5.16 from Debian-stable is too old?

While pretty, this really messes up screen readers: as each letter gets wrapped in a span, the letters are read out one at a time.

How does this differ from http://www.kernjs.com/ ?

How are they similar? That link goes to a bookmarklet that lets you drag letters apart to produce a stylesheet adding extra margins to those letters. This story's link goes to a JavaScript library that provides a dozen new CSS rules for selecting and transforming words and letter spacing, rotation, color...

In this way "kerning.js" doesn't seem to be the most descriptive name for this project. Everything but the first example is not related to kerning, just typography. My first thought, when I read the title of this post, was "but we already have kernjs..."

I'm working on a fine-grained typography control JS library myself, very interesting work.

Designers/front-ends, what things would you like to control about your type now, that you can't yet?

Reply on news.ycombinator.com