Comments on The Look That Says Book

46 Reader Comments

Back to the Article
  1. I thought that readability suffered when using justification as opposed to a ragged margin; are there any studies that confirm this or otherwise?

    Copy & paste the code below to embed this comment.
  2. Clever though this may be, I can’t think why you would want to do it. Force justified text is much less readable than ragged, and causes problems for people with visual difficulties and learning difficulties in terms of comprehension.

    Force justified text is used purely for economic reasons, ie fitting as much text in as possible, very important when paper was a very expensive commodity. Stick to ragged text - it’s better all round.

    Copy & paste the code below to embed this comment.
  3. I think this is the case when using standard CSS justification because the browser does not automatically hyphenate text. This introduces undesirable gaps between words. The article discusses adding hyphenation points which eliminate gaps and ensure readability, just as in print.

    Copy & paste the code below to embed this comment.
  4. I think it’s brilliant that ALA exists to bring content like this. It’s not the kind of subject that will be brought up regularly on most mainstream web-centric websites.

    Working in book publishing, I can see that it’s extremely important to have decent H&J in HTML. More so for eBooks than for web content.

    I think traditional publishers are going to be putting a lot of pressure on eBook producers to keep them as close as possible to the printed books, so whether ragged-right or justified is better on the eyes is a moot point. What’s important is that we can provide an eBook experience which matches (and hopefully exceeds) the paper-based experience.

    Copy & paste the code below to embed this comment.
  5. As I explained to Richard before this article was published, he did *not* make the case that Web typography will in any respect be improved by any of the following:

    * justification
    * hyphenation
    * pollution of source text with unnecessary soft hyphens
    * reliance of source text on JavaScript libraries just to restore essential functions like copy and paste or find

    The indisputable fact remains that hyphenation is taken care of at the *last* stage of layout or rendering *by the layout or rendering engine*. Your page-layout program hyphenates for you. Only if the program makes a mistake do you fix it, and even then you have to be vigilant that later edits do not reverse the original need for the fix. In the E-book case, the E-book reader does the hyphenation. Such purely automated hyphenation will be only marginally better than none.

    In case this is not clear, no, at no time ever should or must or do humans enter thousands of soft-hyphen characters on the off chance software will use them. *Software does the hyphenation*; humans fix its errors — ideally humans who know what they’re doing.

    There very much *is* a substitute for H&J and we’re using it right now. It is called unhyphenated flush-left text. Richard may not want to read a printed novel typeset that way, but everyone except him and a couple of other people with not enough knowledge of the topic seem quite happy with its use on real Web sites. The Web, for the umpteenth time, is not print, nor is it hot-metal type.

    The proposition that Web authors pollute their source text with soft hyphens, which the article admits irreversibly alters that text and makes certain formerly-easy tasks impossible, is much worse than advocating presentational markup like FONT and CENTER (and BLOCKQUOTE to indent) because at least the latter leaves your copy more or less alone. It is just nuts to then state “The bottom line is that browsers — rightly or wrongly — don’t strip out the soft hyphens automatically on copy.”

    Optional returns are as old as WordPerfect 5.1 and are another thing the rendering engine has to handle.

    Web pages are not continuously changing their set width. Your width vs. my width may be two different things, as might a cellphone’s and an iPad’s and a 30-inch display’s, but that is not the same as the article’s implied condition of continuously variable column width happening before our very eyes, like a snake undulating on the waves.

    The Gutenberg history is as irrelevant as the history of print typography. We are not typesetting for print.

    Richard cannot actually prove that “The vast majority of books and magazines are typeset using hyphenation and justification” for the simple reason Richard has not examined “the vast majority” of them.

    The article’s use of the U.S. Constitution as “neutral, generic” body copy is actively offensive to foreign nationals.

    The article falls prey to an error I associate with American Web developers that “special” characters have to be entered using entities of one form or another. They don’t. Not even soft hyphens do.

    The entire concept is *completely wrong* and this article’s endless contortions make that even more apparent.

    What’s next? Instructing us to pollute our text with f-ligatures?

    The solution to full-justified text on electronic displays is not to use it.

    Is this the least factually defensible article ever to run in A List Apart?

    Copy & paste the code below to embed this comment.
  6. First may I say that I found your article informative (I didn’t know that anyone had tried to implement hyphenation in HTML before) and timely, because of the dubious decision to use HTML for electronic books, and the generally appalling typography that has resulted from this. I fully support what you are trying to achieve.

    However the ‘gotchas’ with find, copy and paste would seem to rule this out for the web without the goodwill of the major browser vendors, but I don’t see why it shouldn’t be used for iPhone and iPad ebooks where there may be no need to allow the user to to manipulate the text. I must say I’m thinking of going into that area and will consider it.

    A few niggles:
    1. The link to the hyphenator example doesn’t work. The correct url is: 2.2.0/WorkingExample.html
    2. Hyphenating ‘equal’ as you have done is not good typographic practice - it looks terrible. Throw your hyphenation dictionary away and get a better one. Any reader who does not know about automatic hyphenation will hardly be convinced by this. Leave the US Constitution be, and choose a text that illustrates your case better.
    3. It’s easy to make the mistake, but looks bad in an article on typography.
    “The soft hyphen is a character in the font with it’s own Unicode designation.” Spot the incorrect apostrophe.
    4. And please let your writing justify good typography. I can’t believe that educated people can write “going forward” when they mean “in future”.

    Copy & paste the code below to embed this comment.
  7. I’m not sure the hyphen was introduced into press printing to preserve the overall look of the text.  It was introduced to save space & time.

    Inserting the characters into the frame and discovering the last word was too long to fit the line just took too much time to undo (or continually counting ahead to avoid it).  Adding spacers to fit the printing frame would require more spaces (the typesetter would probably run-out) and also waste more space.

    This quickly became standard practice and ‘readability’ only resulted because these days everyone learns to read text in this style, although modern press isn’t following this approach as strictly: This weeks TV guide magazine (What’s On TV) is completely non-hyphenated, today’s Metro newspaper uses a mix.  Bulletproof Web Design has a ragged edge AND hyphenation (uh?).  The Design Of Everyday Things is ‘properly’ hyphenated. - That’s all I’ve got at my desk…

    Copy & paste the code below to embed this comment.
  8. Very interesting article philosophically, but from a pragmatic point of view, I doubt it’s worth it. Yes, it makes text a bit more readable (which is debatable, as you can easily see from the comments) and a bit more beautiful, but with the cost of around 80 extra KB on the page, which is not trivial (ok, it might get down to 50-60 when minified, but still…)

    Copy & paste the code below to embed this comment.
  9. My question is why are we trying to set type standards on the web based off of print principles? Many ideas do translate from print to web, but from what I read justification of text is not one of them. As Liam Cromar and Mactonex say, most advice on the web typography seems to explicitly state that justification of text lowers readability and accessibility. I do not want to attack anyone, but as a beginning student in web design I’d like some clarity in advice on typography. Really appreciate an answer on this one…

    Copy & paste the code below to embed this comment.
  10. bq. The article’s use of the U.S. Constitution as “neutral, generic” body copy is actively offensive to foreign nationals.

    Not to this foreign national. You can’t prove that for the simple reason that you haven’t asked “foreign nationals”.

    Copy & paste the code below to embed this comment.
  11. A tool used in the editing process converted forward slashes to Unicode characters, breaking the link to the hyphenator. The link has now been corrected. Our thanks to those readers who noticed and called it to our attention.

    Also, a shameful misuse of “it’s” has been corrected.

    Copy & paste the code below to embed this comment.
  12. This proposed solution does not address the complexity of hyphenation rules. Generally, only the latter portion of a word should be hyphenated, and you don’t want to create very short hyphenation stubs. “Ad-vertising” should not be hyphenated—better to bump the two “ad” characters to the next line. But “Adver-tising” is an acceptable division of the word at the end of the line. (See rule 4 at Blindly hyphenating on syllable divisions will result in a poorly-hyphenated document. Rather than make the document appear professionally typeset, it will instead appear to be h+j by an amateur who’s trying too hard to be sophisticated, sort of like someone who pretentiously uses “I” when “me” would, in fact, be the correct pronoun.

    I agree with many posters that h+j is of questionable benefit in many situations. However, there are times where I would like to use it, so I would like to see a browser-based solution in the future. Perhaps if CSS text-justify automatically invoked an intelligent hyphenation engine, that would work; or perhaps we proopose adding in a CSS hyphenation property to the CSSx spec.

    I also agree that this proposed solution is too kludgy. Too many dependencies; our applications and pages are already becoming overladen with JavaScript and CSS.

    Copy & paste the code below to embed this comment.
  13. The first thing that came to my mind for practical use was not to hyphenate body text (jagged right is just fine for me, personally). Instead, I could see this being useful for really long names and titles for objects that appear in a tight grid.

    Rather than a long name or word breaking out of the grid and crashing with the object beside, it would be much better if a browser could just apply a hyphen somewhere between “St. Petersburg/Clearwater"if needed. Hiding the hyphen if there is enough space.

    Server side applications could handle this too, but perhaps a server side application could intelligently apply ­ to long titles and words, while leaving other critical information alone. This is just the thought process I have when it comes to imagining how to implement this where I work.


    Copy & paste the code below to embed this comment.
  14. This proposed solution does not address the complexity of hyphenation rules.

    It does a better job of doing so than you might think. Hyphenator.js doesn’t just hyphenate on syllable divisions, it is based on an algorithm derived from extensive study of the hyphenation points listed in dictionaries, which, according to its author (Frank Liang), finds 89% of the allowed hyphenation points, with no false positives.

    Copy & paste the code below to embed this comment.
  15. pakjeem said:
    >  our applications and pages are already
    >  becoming overladen with JavaScript and CSS.

    thank you!  i was hoping someone would say that.

    combined with all the other gotchas involved here
    —copy problems, and search glitches (which _are_
    a “deal-killer” for me, as an end-user, richard, and
    tell me, does “deal killer” have a hyphen in it, or not?)
    —let’s just ignore these obsessive-compulsives, ok?

    my goodness, they’d have us jump through all kinds of
    hoops, just so the right-margin will be perfectly straight.

    besides, there’s a better solution.  i won’t give it away in
    a comment, but if “a list apart” wants an article from me,
    i’d be happy to write it up.


    Copy & paste the code below to embed this comment.
  16. First, Richard, your example of hyphenated and justified text was really pretty awful - two hyphens on successive lines, quite awful word spacing on some lines. You did the case for hyphenation more harm than good.
    Second, justified text - with word-spacing on successive lines varying only within tight limits - is the best and most relaxing text to read. It suits the way the human visual system - eye, optic nerve, and brain - works. See some very early posts on my blog for much more detail:
    and also my paper, The Magic of Reading , at:
    Please excuse this broken website if you go there. It was optimized for IE when I worked at Microsoft and I haven’t updated it, now I work all the time on FF on the Mac.
    The only way to achieve that is through good hyphenation, dictionary-based not algorithmic.
    Throwing discretionary hyphens into all text is a pretty inelegant solution.
    Hyphenator.js works pretty well but does introduce lag into the system. And it has dictionaries for only three or four languages (or did the last time I looked).The browsers should implement dictionary-based hyphenation. Then they could hyphenate, space the lines properly and then render them.
    It’s not rocket-science. Desktop publishing apps have been doing this for decades.

    Copy & paste the code below to embed this comment.
  17. I’m using it on my blog at

    It’s not an astounding improvement, but it big to me, and I like the site much better with it. Much more pleasing on the eye.

    Copy & paste the code below to embed this comment.
  18. From Erik Spiekermann’s Typo Tips (

    “6. Not Justified
    Avoid flush settings! Most applications create justified text by hideously stretching and squishing words and spaces. Note that it takes many hours of tedious work to typeset justified text that is truly well-proportioned and legible. For this reason, professionals prefer to use ragged-right composition, either with or without hyphenation, depending on how much line-length variation they wish to allow. This gives the text a more harmonious appearance and makes it easier to read, since all wordspaces have the same width.”

    If ragged right is more legible for print, why wouldn’t it be more legible online, too? Justified text is nice looking in the abstract, as it’s a nice block, but it’s often a pain to read. And note that Spiekermann says that it takes hours to properly justify text. It can take hours to properly set ragged right text in a book. Why are we trying to replicate that workflow online? What user of a corporate CMS is going to take the time to properly hyphenate everything?

    And while I’m ranting, what is up with the ever-growing pile of javascript plug-ins we’re being told we should have on our sites? What happened to streamlined, simple development?

    Copy & paste the code below to embed this comment.
  19. One thing I noticed right away is that hyphenation really hampers the readability of a text the bigger the line-length gets. Stopping halfway a word to travel all the way back to the left and pick up is pretty bothersome. As it is hard to predict how wide a text area will be (and how far the eyes will travel), this sounds like a less than ideal solution for large chunks of electronic text.

    Copy & paste the code below to embed this comment.
  20. bq. Second, justified text — with word-spacing on successive lines varying only within tight limits — is the best and most relaxing text to read

    Bill, although I agree that going the Javascript route to do H&J is not A Good Thing, I tend to question the very principle of doing H&J on a systematic basis. Do you have any pointers (I mean, peer reviewed papers) that demonstrate that justified text is the “best and most relaxing” ?

    To me this seems counter-intuitive, except perhaps for specific widths, because I feel it harder to bring my gaze back to the correct line after an EOL when the text is justified. It is also the opinion of Edward Tufte, among others, if I am not mistaken. When the text is justified, it becomes a block of indistinguishable lines, and it takes more time to find which one you were reading, and which is the next, if your attention drops for an instant.

    Copy & paste the code below to embed this comment.
  21. H&J without carefully considered H&J rules (like those found in inDesign) seems a pointless endeavor. I shudder to think of the less typographic-savvy web designers who will interpret, “We can hyphenate!” as “We can justify!”, producing web pages full of rivers.

    *Let’s not forget*: Ragged text columns don’t have to be hard-set. They can hyphenate as well, to create a more even edge. _This_ is where the focus should be right now.

    Copy & paste the code below to embed this comment.
  22. Hi

    Thanks to Richard Fink and ALA for this article and for the pointer to my Hyphenator.js poject. As its developer I’d like to share my thoughts, too.

    And special thanks to all those critic voices, too. I think those are the most important! I’m currently getting lots of mails and requests about my project.
    There are many good ideas about how to improve Hyphenator.js and I will implement most of them in the coming weeks. Hyphenator.js is a growing project that I’m maintaining in my spare time (@Bill Hill: There’s currently support for over 30 languages, more to come!).
    Just one appeal: RTFM! You’ll save my time and for many things there’s already a solution.

    @those being doubtful about readability of hyphenated text
    IMO this highly depends on literacy of the reader. Reading lots of books is getting used to hyphenated words since most books are set with H&J. (Want a prove? Go to the library!) Personally I’m a fast, experienced reader and capturing a hyphenated word isn’t that difficult to me. Together with the context the first syllables are enough to guess the whole word. So hyphenation gives me a valuable hint about being on the right line when my eyeballs jump to the next line (unliterally spoken ;-)
    True, hyphenation may be not that easy to read for less experienced or handycapped readers and reading webpages is generally not the same as reading printed text. But what about eBooks? What about optional hyphenation?
    This article does not say you should do hyphenation in every text. It says: “it can be part of your work”. I.e. you can use it now, if you feel like or your customers make you using it.

    @those saying unhyphenated flush-left text is a good alternative
    This my be true for english texts with short words on average. It isn’t true for other languages with longer words. In German there are lots of very long compound words:
    adjudication of the federal administrative court (en)
    Bundesverwaltungsgerichtsentscheid (de)
    I recently read this word in an article on the front page of; it didn’t fit the layout!

    @those complaining about the size of the hyphenator script
    I completely agree. It’s too large (largest part are the hyphenation patterns). But lets take this ALA-article as an example. The JPEG on top of it (the one with the sliced carrots) is about 45KB. It looks nice but it not relevant to the the content, too”¦
    The script and the the patterns are cached if you set it up correctly and can be reused on every page of your website.

    @those who don’t trust automatic hyphenation
    I’m using a quite old and sophisticated algorithm originating in TeX. To compute the patterns a list of hyphenated word is used. The better this list the better the patterns, the better are the results of hyphenation. There’s ongoing work on a list for german patterns ( but afaik not for english”¦

    @those who say “this should be done by the browser”
    Definitely. I hope that once upon a time a browser will fix it’s text layout engine and do hyphenation (according to CSS 3). Until then Hyphenator.js is just a crutch.

    Finally: I was quite surprised by some very determinating declararions in the discussion above. Nobody drives you into using Hyphenator.js and piling up scripts on your website. We’re not as free in all our decisions as we may think but in this case we are very free. Hyphenator.js is just an option and it may be valuable for some cases and completely disappropriate for others. But I think it’s great to have this option.

    Kindly, Mathias

    Copy & paste the code below to embed this comment.
  23. I think we all can agree that when you have text automatically justified you should also have it hyphenated, even if it’s automatic and less than perfect. (That’s where the _current_ rule comes from: “don’t justify text on the Web!”) If you use (automatic) hyphenation you don’t necessarily need justification. The benefits are still there, especially in languages with average word length higher than in English. People also seem to forget or ignore that you can configure client- and server-side hyphenators to your likings, i.e. minimum characters to keep on line and push to nex, maximum number of consecutive lines hyphenated, exceptional words etc.

    Javascript solutions, of course, are not solutions but hacks. They’re fine as user-side workarounds (bookmarklet, plugin/addon), but, in general, shouldn’t be provided by site owners, at least not enabled by default.

    Some commenter suggested to propose additions to CSS. This has, unsurprisingly, been done long ago. It was even mentioned in the article, but hardly (re Prince), and currently resides in “Generated Content and Paged Media”: but will be moved to a “more appropriate module”:

    Copy & paste the code below to embed this comment.
  24. Just thought I’d mention that viewing the Heart of Darkness example in Opera on Windows, there’s an odd question-mark character that precedes every em dash.

    Copy & paste the code below to embed this comment.
  25. As an author of an article on “Antidisestablishmentarianism”: may have discovered, text benefits from hyphenation and justification — whether justified or ragged. Like using <table> and float:, the solutions in the article are workarounds to fundamental layout problems better solved by browser developers working with good specifications.

    If reading on electronic devices is going become as easy and elegant as print, browsers and e-readers need to have built-in sophisticated hyphenation and justification routines which are applied at the point of use, along with better handling of soft-hyphen and fixed codes so that they don’t pollute what the viewer receives.

    And once hyphenation is sorted, can we move onto good kerning and tracking and correct handling of ligatures, please?

    Reading on the web is like riding a unicycle or flying a biplane. We do it for the experience not the ride.

    Copy & paste the code below to embed this comment.
  26. For accessibility’s sake, there needs to be an “off” button from the site visitor’s end.

    I’ll also agree that too many Web pages suffer from JavaScript bloat.  On a Windows embedded system, I see pages that take minutes to load, or even sometimes to scroll.

    Copy & paste the code below to embed this comment.
  27. In no way does force justified hyphenated text make the text easier to read — in fact it is just the opposite.

    I regularly work with people who have visual difficulties, learning difficulties and who are reading text that is not in their first language. I can guarantee you that most of them find force justified hyphenated text more difficult to read and understand. It’s rarely necessary in print and totally unnecccessary on the web.

    Setting text this way is an anachronism and it would be a terrible shame to see it spread on the web.

    Copy & paste the code below to embed this comment.
  28. I don’t know why I have to keep reminding Richard that shoving U.S. legislative documents down our throats as “neutral, generic”Â examples offends people who aren’t American. We never declared independence, hence don’t have a Declaration of Independence.

    I guess this is one of those times when it’s pointless to argue with Americans about their view that everybody fundamentally is one.

    Copy & paste the code below to embed this comment.
  29. Your comment shows that you haven’t yet understood the web. Whereas in print the content and its presentation is often one big unity (the book, the newspaper), there’s a three layered model on the web:

    # content — well structured HTML (w/o any styling)
    # presentation — default or user defined CSS that styles the HTML
    # behaviour — how the user can interact with layer 1 and 2: JavaScript and server side languages

    If a webdesigner decides to not respect this model, it’s his fault and he hadn’t understood the web, either!

    As it comes to accessibility and reception of text a website is well done — among may other important things — when it is receptionable when CSS and JavaScript (Layers 2 and 3) are turned off.
    H&J belongs to layer 2 only (it’s done by JavaScript in the case of Hyphenator.js because layer 3 is the place to change layer 2, but in case of native Hyphenation support layer 3 isn’t involved any more).

    There are interfaces for every user to change layer 2 (user defined stylesheets and extensions) and layer 3 (Bookmarklets and extensions). So if one doesn’t like how the context is presented he can change its presentation and its behaviour. (BTW: it’s exactly what I am doing with Hyphenator.js: it hyphenates every webpage for me, because I don’t like text layouts with ugly rags).

    It’s not a shame that there’s H&J for the web. If this would be the case then it is also a shame that there’s color (color-blindness) and sound (deafness) and many other things.

    I thing that you’re wrong.

    (But it’s a shame that people still don’t know about the model described above and still don’t know how to use and adapt the web for their needs!)

    Copy & paste the code below to embed this comment.
  30. Thank you for your article. I am going start using it in all of my my new website projects!

    Copy & paste the code below to embed this comment.
  31. Practically using hyphens on the web are still in early stage. For example, we designers have to avoid 3 word-break hyphens for 3 consecutive lines within the same paragraph. To be able to avoid this, we need a sultriness adjustment.

    We can’t wait for controlling content on the web the same way we do on print, though.

    Copy & paste the code below to embed this comment.
  32. I have implemented Hyphenator before on a website using the JS library. But personally I do not believe that this is the best way to implement hyphenation for the Web.

    Loading the JS library with every new web page creates quite a heavy load and takes time. And this also means that hyphenation is only available on website that actively offer it.

    Using it as a bookmarklet makes hyphenation available on any website that the user desires to have it to improve readability by his own judgement. Much better because it gives users a choice. But still you actively need to click that button for each new page which renders again then. What a waste of time!

    My conclusion is that the browser should add such functionality - preferable as an add-on - and make it configurable. One option could be to hyphenate all web pages by default. Another option would be to only hyphenate the current page on demand by clicking a button. But then the add-on could ask if you want to remember that website and set it individual default to hyphenate every time. That would be choice plus ease of use.

    Now we would need to find someone able and willing to write such an add-on to make us happy.

    Copy & paste the code below to embed this comment.
  33. When discussing whether ragged or justified style is better readable, I would like to remind everybody that many other languages than English - especially German and Finnish - have extremely long words. Using narrow columns (often seen with image captions as well) without hyphenation you often end up with just one word per line and large holes.

    Copy & paste the code below to embed this comment.
  34. There is also another alternative to using ­ entity - <wbr > tag.

    More info can be found here:

    Copy & paste the code below to embed this comment.
  35. interesting article. i haven’t finished it though but i think this one really helps alot.

    Copy & paste the code below to embed this comment.
  36. When I started reading this article, I thought, “Cool!” By the time I finished it and read the comments, I was swayed that this is an interesting tech-demo, but not good practice.

    I can see how there would be special cases that might merit, like Heribert Wettels mentioned. However, I think the right answer is to avoid creating such tight spots in the design phase, thinking globally long before you’re putting in content.

    Copy & paste the code below to embed this comment.
  37. The author takes umbrage at javascript workarounds being labelled “hacks”, but that’s exactly what they are.

    hyphenator.js is a hack, because it uses javascript to provide a feature that should be implemented natively in the browser. It’s a stop-gap measure, just like using javascript to fix poor CSS support in old browsers (max-width, fixed positioning, etc.).

    The point about labelling something “hacky” is to draw attention to the costs of using it. In the case of hyphenator.js, you’re adding javascript to make H+J work. The cost is additional complexity (maintenance), the nasty bug in find-on-page, and performance.

    Remember that javascript is a blocking download, so the cost of javascript in kB cannot be directly compared to an image. Anything that interferes with the display of text content should be subjected to a harsh performance assessment, because a delay in supplying the text greatly affects the perceived responsiveness of the page.

    hyphenator.js is an impressive project. The typophile in me longs to use it. But the pragmatic website owner in me says that the objective cost greatly outweighs the small, subjective benefit.

    In other words, it’s just too hacky for my taste. Brilliant, but hacky.

    Copy & paste the code below to embed this comment.
  38. 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.
  39. 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.
  40. 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.
  41. 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.
  42. 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.
  43. Sorry, commenting is closed on this article.