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.<p>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.<p>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.<p>I'd recommend trying out <a href="http://glazman.org/JSCSSP/" rel="nofollow">http://glazman.org/JSCSSP/</a> or <a href="https://github.com/nzakas/parser-lib/tree/master/src/css" rel="nofollow">https://github.com/nzakas/parser-lib/tree/master/src/css</a> which Nicholas uses for CSSLint.
Do people use things like this?<p>I recently read Robert Bringhurst's excellent <i>Elements</i> <i>of</i> <i>Typographic</i> <i>Style</i>, but have no idea how to apply it to the web.<p>(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.")<p>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?<p>More generally, what does the current web typographer's toolbox look like at the moment?
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.<p>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 <i>none</i> or whatnot.<p>By all means, nice work, I just rarely work with pages where I know how the content will turn out.<p><i>Edit: Fixed a typo.</i>
Speaking of kerning, here's a simple CSS declaration for modern browsers:<p><pre><code> text-rendering: optimizeLegibility;
</code></pre>
... which will give you improved handling of kerning pairs and ligatures.<p>see: <a href="http://www.aestheticallyloyal.com/public/optimize-legibility/" rel="nofollow">http://www.aestheticallyloyal.com/public/optimize-legibility...</a>
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.<p>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.
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)<p>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...<p>Perhaps if there's a way to simplify the syntax or provide easy copy-paste examples, it'll remove the barrier to entry?<p>Still, applaud the work and the code looks great.
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?
I'm working on a fine-grained typography control JS library myself, very interesting work.<p>Designers/front-ends, what things would you like to control about your type now, that you can't yet?