The Look That Says Book

by Richard Fink

46 Reader Comments

Back to the Article
  1. Wonderful article. There is a lot of annoyingly repetitive stuff in this thread, and some complete falsehoods.

    @Mike Hopley: JavaScript does not have to be a “blocking download.” This is why tools like YSlow’s analyzer recommend putting it at the end of your code. There are even tools out there that will compress, cache, and reposition your JS automatically.

    @Everybody who wants the world to know the web is not print: We are in a post-web-is-not-print world now. The web is the new print. If you don’t want to come along for the ride, you don’t have to use tools like those mentioned in the article.

    I used to be one of those “The web is not print” people, until I realized it made me instantly recognizable as someone who designed “like a web designer.” We need to push the body of web design work forward, not coddle it.

    I applaud Mathias for his work in pushing the cutting edge forward a bit more. I work next to a print designer of 25 years, and knowing about this sort of tool helps me bring her visual language to the web. It’s worth the effort.

    Copy & paste the code below to embed this comment.
  2. Sure. But if you put hyphenator.js at the end of your code, you will get a jarring “flash” when the hyphenation kicks in.

    You can’t have it both ways. Either you take the performance hit, or you live with the FOUC-like effect. Or you could just stick to ragged-right.

    It’s much the same problem as using @font-face: either you delay the text, or you get a flash of restyling when the font file arrives. For custom fonts, perhaps it’s worthwhile (at least for some designs). But for justified text?

    Copy & paste the code below to embed this comment.
  3. If you leave the word-breaking and hyphenation entities in your copy for html-formatted email (and they may look like word spaces after you’ve cleaned the text), they will cause problems for inline conversion offered by services such as Premailer <>. Be sure to strip them!

    Copy & paste the code below to embed this comment.
  4. To all:
    Thanks for the frank, sometimes passionate comments.
    I wrote this article in the spirit of “hey, take a look at this, what do you think?” and you’ve certainly let me and ALA’s readers know your mind. (And if bowerbird wants to let us all in on his secret sauce for better H&J, I’m all ears.)
    One thing in particular that I’d like to point out is that HTML is not only the future of ebooks, it’s the future of print, too. At least that’s what I see with my binoculars on, and pretty clearly, too.
    If I may make a suggestion: try viewing the quick’n’dirty desktop browser example from the article in Print Preview. (However you might feel about IE, it happens to have a good Print Preview mode.)
    It looks like a book. And if I were to include a print style sheet, I wouldn’t be locked into the pixel grid and I could make use of the high res environment of print just as easily as any PDF. Add a dash of web fonts and anything InDesign can do, I can do in the browser. (In fact, I’ve issued a private face-off challenge to an experienced book designer of my acquaintance and I’m hoping he sends me a few pages by years end so I can try my hand at duplicating them – with every typographical nuance intact – in browser rendered HTML.)

    Simply put: as a web author, H&J is a design option I want. I don’t care if it’s unnecessary. I don’t care if some people like it or don’t like it. I want the option. I want my H&J.

    Personally, I happen to like H&J onscreen for long passages of text, especially narrative. I also like it on reading devices like the iPad where the viewing distance is more intimate.
    But that’s my druthers and it would take special circumstances for me to consider imposing H&J as the default.

    With regards to using the soft-hyphen and javascript to get H&J today:
     Everything has its advantages and disadvantages.
    Let me say that again:
     Everything has its advantages and disadvantages.

    Hyphenator.js is what it is and I haven’t heard anybody argue that it isn’t the best we can do for H&J for now.
    Hacky, shmacky, whacky or not.
    I certainly do admire Mathias Nater’s effort and will be using it on occasion, absolutely. I have no doubt the implementation will improve. Getting some more eyeballs on it was a spur, for sure, and – the way I see it – a part of what ALA is all about.
    ‘Til later…

    Copy & paste the code below to embed this comment.
  5. I happen to like justified text, even without hyphenation. I’m not sure how it harms readability, for English text, if the width of the text is sufficient. For narrow columns: yeah, it produces weird spacing between words. But for wide blocks of text, it just looks so much nicer at a glance, and you don’t really notice the spacing issue (rarely is it more than a few extra pixels per space) when reading.

    That said, I still don’t think automatic hyphenation is something I’m going to implement on my own site.

    Also, the Declaration of Independence is clearly not a “U.S. legislative document”. Even if it was, what could possibly be offensive about it? The quasi-religious mention of a creator? Or just the fact that it was written by Americans?

    Copy & paste the code below to embed this comment.
  6. In a world of social networking, cms and other user generated text, I am wondering how relevant this topic is.
    Interesting article, though.

    Copy & paste the code below to embed this comment.