In case you're unaware: Font Bomb is a (gimmicky) solution for literally "blowing up" text. Blast.js, in comparison, is a robust text parser for real-world typographic manipulation.
This is wonderful! I see immediate use cases for drop-in username highlighting, without additional templating or '<span>' + username + '</span>' spaghetti.
Big fan of your Velocity.JS, Julian. How does Blast.JS compare to Lettering.JS? (http://letteringjs.com/)
Edit: It's been awhile since I've looked at Lettering, but to answer my own question, Lettering only splits on individual letters, while Blast allows for user-definable splits.
Lettering.js has a slightly smaller footprint and aims to be a dead-simple "wrap spans around each letter/word in the HTML element I point you at." Accordingly, it discards your HTML then dumbly splits using spaces as delimiters. Because of this, you have to use Lettering.js in silo'd portions of your page where you don't mind losing HTML and event handlers. Further, its lack of UTF-8/multilingual text parsing means that it's only suitable for English, and only in controlled portions of your page where you already know exactly how text is written out.
Blast, in comparison, tries to be a "set it and forget it" library. Point it at anything, blast it apart, then even reverse what you've done ($el.blast(false);). You can apply it to user-generated text in real-time and not worry about a thing.
Perhaps most important, though, is that Blast.js features a sentence delimiter plus search, which Lettering.js does not.
This might be interesting to people who are into this library. I've been working on a JS library that allows for manipulation of CSS properties on a character by character or a word by word basis. You can even use math functions for interesting effects (like applying a Cos function to font size character by character). The library is finished (and there is even a simple GUI) though I'm still working on documentation and examples. You can check it out here: https://github.com/emluque/generativeText
Nice work. I'm also a fan of velocity.js (and I wrote liquid-fire to make it easier to use velocity in Ember apps).
My top use case for something like blast is applying typographic rules that aren't possible with CSS. Like adding extra letter-spacing to strings of all caps, and rendering "AM" and "PM" in small caps. I do several of these things already on an ad-hoc basis.
However, in the example on the main page when you choose sentences it thinks that "Blast.js" is a sentence with the beginning of another. I think that you should ignore a dot if it's there to declare a file extension.
Lettering.js recently merged some great accessibility code[1] that improves UX for screen readers by adding ARIA attributes. Each targeted element is given an aria-label with the original content, and each created span is marked with aria-hidden to avoid having the reader pause at every element. Would you consider implementing something similar for screen readers?
> 5. All Latin alphabet languages and UTF-8 characters are supported.
This claim really needs revising, only latin languages are supported, and the implementation doesn't use the Unicode boundary analysis algorithms. It certainly doesn't support the whole of Unicode as it first appears.
This is a nice effort but make it clear that it's Latin-only. Also, how well does it measure up to the Unicode UAX #29 grapheme/word/sentence break algorithms?
19 comments
[ 3.1 ms ] story [ 39.8 ms ] threadhttp://fontbomb.ilex.ca/
Edit: It's been awhile since I've looked at Lettering, but to answer my own question, Lettering only splits on individual letters, while Blast allows for user-definable splits.
Lettering.js has a slightly smaller footprint and aims to be a dead-simple "wrap spans around each letter/word in the HTML element I point you at." Accordingly, it discards your HTML then dumbly splits using spaces as delimiters. Because of this, you have to use Lettering.js in silo'd portions of your page where you don't mind losing HTML and event handlers. Further, its lack of UTF-8/multilingual text parsing means that it's only suitable for English, and only in controlled portions of your page where you already know exactly how text is written out.
Blast, in comparison, tries to be a "set it and forget it" library. Point it at anything, blast it apart, then even reverse what you've done ($el.blast(false);). You can apply it to user-generated text in real-time and not worry about a thing.
Perhaps most important, though, is that Blast.js features a sentence delimiter plus search, which Lettering.js does not.
My top use case for something like blast is applying typographic rules that aren't possible with CSS. Like adding extra letter-spacing to strings of all caps, and rendering "AM" and "PM" in small caps. I do several of these things already on an ad-hoc basis.
As for micro-typographic rules: You'll find that a simple way of accomplishing this is to use Blast's generateValueClass option.
However, in the example on the main page when you choose sentences it thinks that "Blast.js" is a sentence with the beginning of another. I think that you should ignore a dot if it's there to declare a file extension.
[1] https://github.com/davatron5000/Lettering.js/pull/51
This claim really needs revising, only latin languages are supported, and the implementation doesn't use the Unicode boundary analysis algorithms. It certainly doesn't support the whole of Unicode as it first appears.
This is a nice effort but make it clear that it's Latin-only. Also, how well does it measure up to the Unicode UAX #29 grapheme/word/sentence break algorithms?