10 ms·

Hyphenation in CSS

184 points by kawera 8y ago

quotemstr 8y ago
First impression: I like the nuanced control over where hyphenation happens, but can't help but wonder whether giving the browser control over the intraword hyphenation candidate points is a good idea. Don't we have soft hyphen characters in Unicode for exactly the purpose of letting authors precisely specify hyphenation candidate break locations?
- Carpetsmoker 8y ago
  It's U+00AD, or . While occasionally helpful, it's a complete pain to manually add though. Also I recently noticed Firefox seems to copy it, which is pretty annoying (didn't use to do that, I think).
  - quotemstr 8y ago
    Yeah. Removing this character when copying to the clipboard is definitely the right thing to do. Have you filed a bug?
    - mrob 8y ago
      It doesn't sound like a bug to me. If I copy and paste something I expect to get all the Unicode characters. Only the CSS should be stripped. If the browser silently deletes Unicode characters then it's certainly going to cause unexpected data loss in some cases. Firefox is doing the right thing.
      - quotemstr 8y ago
        I consider soft breaks to be metadata, not data. Dropping soft hyphens doesn't affect the meaning of text and so doesn't drop information that humans care about. If it's not data loss that copy and paste doesn't propagate bold and italic formatting, it's not data loss that it doesn't propagate soft hyphens. Not every Unicode code point conveys information that we need to preserve.
        mrob 8y ago
        It's not data loss if the bold or italic are in CSS or HTML tags, but if it's 𝐛𝐨𝐥𝐝 or 𝑖𝑡𝑎𝑙𝑖𝑐 like this (which I realize is not how Unicode is supposed to be used) then it's part of the text, just like soft hyphens.
        quotemstr 8y ago
        Soft hyphens only "part of the text" because the hyphens are represented using "in band signaling" instead of "out of band" signaling, as in proper bold and italic. It's still just information about the text, not the text itself.
        mrob 8y ago
        It's exactly because they're in-band signaling that they should be preserved. I don't expect copy and paste to change the sequence of Unicode code points. If the browser "helpfully" removes certain code points then it's more complexity I have to think about. The only change I'd consider acceptable would be changing to a specified Unicode normalization form. In this case the complexity already exists within Unicode, so the browser isn't making it worse.
- matt4077 8y ago
  How would this work? You cannot know the exact flow of text on each and every platform, so you would end up just manually specifying every possible hyphenation. That would seem to be a lot of work to create something that's almost definitely going to contain far more errors than a somewhat complete dictionary that ships with the browser.
  - quotemstr 8y ago
    What about words that the browser doesn't know about? While automatic hyphenation point insertion is convenient, I want to retain the ability to provide manual overrides.
  - frosted-flakes 8y ago
    Simple. Using a hyphenation dictionary, automatically insert soft hyphens at the optimal position in every word before delivery to the client. I haven't seen this done in practice, but I see no reason why it wouldn't work.
amelius 8y ago
A bit late. Why only now do we get support for this basic text formatting primitive?
- _fzslm 8y ago
  This has been supported since 2011.
  - Carpetsmoker 8y ago
    Only hyphenate: auto has, and only in Firefox. Chrome didn't add support until 2 years ago. In my experimentation hyphenate: auto doesn't give good results; you need all the other hyphenate rules to get that, which aren't widely supported yet.
    - chinathrow 8y ago
      Chrome on Linux and Windows has no support: https://caniuse.com/#search=hyphens https://caniuse.com/#search=hyphens Also from the article: "Safari, Firefox and Internet Explorer 9 upwards support automatic hyphenation, as does Chrome on Android and MacOS (but not yet on Windows or Linux)."
jacobolus 8y ago
So when are browsers going to abandon their greedy line breaking algorithm and implement Knuth/Plass or similar? In my opinion that is the single biggest problem with web typography, and has been for years. Significantly more important than auto hyphenation. This has been a solved problem for 40 years (or at least 10–15, if we need to worry about fast performance for interactive use on a desktop computer). Should be table stakes for any software rendering long blocks of text.
- chrisseaton 8y ago
  Knuth/Plass seems to regularly need user input to resolve issues, at least in the TeX implementation - if that’s inherent can it be used in a browser?
  - misterdoubt 8y ago
    For basic hyphenation of text paragraphs, it's been years since I felt the need to intervene in (La)Tex hyphenation. For typesetting more broadly, certainly. For making a clean right edge, no.
  - svat 8y ago
    User intervention is (occasionally) needed in TeX only at its default settings, which are optimized for “rather than typeset any paragraph with a too-loose line, just give up and warn me loudly so I can take a look”. This makes sense for Knuth and his original goal of producing books. But it's not inherent; a combination of \tolerance=9999 (the default is 200) and \emergencystretch=\maxdimen makes it so that TeX will try to produce the best paragraph possible without requiring the user to intervene and rewrite the words. (Another alternative is to increase the stretchability and shrinkability of the interword glue.) And there will be no overfull boxes unless of course there's a single unhyphenatable word that by itself is longer than the line width. (LaTeX has a shortcut called \sloppy for achieving basically this, but the name scares people who don't understand the TeX algorithm.) Sometimes I think this should be the default: definitely the worst typesetting I've seen is in documents produced by people who ignored all the overfull box warnings; even the greedy algorithm of Word etc would be vastly preferable to that.)
massivecali 8y ago
Does this impact screenreaders?
- frosted-flakes 8y ago
  No. Screen readers ignore CSS text transformations like this.
  - massivecali 8y ago
    Thanks, good to know.
frosted-flakes 8y ago
One problem for which there is no CSS solution yet is orphaned lines caused by floated images, when only the last line of a paragraph flows beneath the image. Particularly annoying with left-floated images in RTL text. I don't use floated images that often, but sometimes the design calls for it.
Theodores 8y ago
I imagine this can be combined with a media query so that you can use hyphenation differently on small screens when real estate might be lacking and the ragged edge takes up too much space. Time to experiment!
reaperducer 8y ago
Now if only there was a way to specify that paragraphs of text shouldn't leave an orphan word on the last line, I could use one CSS property to get the consultants off my back instead of having to preg_replace the last space in every paragraph with an  .
- TheRealPomax 8y ago
 You might at least be interested to know that you can also wrap those last(two or more) words in with the nobreak class using "white-space: nowrap;" so that your solution works across all languages, rather than just those where the non-breaking space doesn't looking horrendously out of place.
- deleted 8y ago
 [deleted]
undershirt 8y ago
Good to have this overview! I abandoned hyphenation in a project after seeing it behave so different from LaTeX’s. Looks like I missed some options. Related, I was looking at multi-column CSS for magazine or newspaper typesetting. The controls on column-breaking were not well supported, making it very difficult to not end up with ugly typography. Would love to see improvements there as well.
- erichurkman 8y ago
  If you want real typesetting via CSS, you can use PrinceXML. It does great hyphenation, column breaking, and has some extensions to CSS to allow similar controls as you'd get from LaTeX's column options. [0] https://www.princexml.com/doc/11/hyphenation/ https://www.princexml.com/doc/11/hyphenation/ [1] https://www.princexml.com/doc/11/floats/#float-extensions https://www.princexml.com/doc/11/floats/#float-extensions
  - undershirt 8y ago
    Oops, I meant newspaper-like layouts for browser pages. But cool, I like the specific extensions PrinceXML has for column control. thanks for the reference, will try it if i need this for printing
robbrown451 8y ago
I am fine with just considering hyphenation a thing of the past. Do we really think it adds value? I find it far easier to read text that doesn't break words in half. So what if the right margin is a bit raggedy.
- misterdoubt 8y ago
  It adds considerable value if the goal is not more than getting some words on the screen" but rather "how is the best way I can possibly present this textual document." Personally, I find a very small proportion of text to fall into the latter category. But for those that do, clean presentation is huge.
  - robbrown451 8y ago
    Could you give me an example of a type of document that falls into that latter category? Personally I don't think they make it look cleaner, but the opposite.
- TheRealPomax 8y ago
  Respectively: that's your perogative; yes; cool; typesetting matter, sometimes drastically, even if most of the time you don't even notice it. I have several "books" on the web, for which hyphenation is a godsend, especially as CSS is not just for that computer monitor you're staring at, but also for `media="print"`, which yes: matters even in 2019.
  - robbrown451 8y ago
    Ok, well I personally find them a bit jarring, after years of mostly reading on the web where they are extremely rare. I remember typing papers on manual typewriters and having to think about where to hyphenate (as well as just when to do a carriage return), and it was awful. Admittedly now it is more of an aspect of reading (since an algorithm can do the actual hyphenation), but still. I would prefer we just abandon it. Could explain why it matters more on a printed page that on a monitor? I don't see any relevant differences.
crazygringo 8y ago
Curious how automatic hyphenation works with ambiguous words? E.g. to pro-ject an image but to work on a proj-ect. [1] Documentation does seem to suggest that inserting a soft hyphen  at the correct point will serve as a hint that automatic hyphenation should obey. [2] Not that many people are going to remember to bother. But wondering if any browser's automatic hyphenation dictionaries attempt to perform any contextual analysis such as part-of-speech tagging to try to get it right in ambiguous cases? [1] https://www.merriam-webster.com/dictionary/project https://www.merriam-webster.com/dictionary/project [2] https://css-tricks.com/almanac/properties/h/hyphenate/ https://css-tricks.com/almanac/properties/h/hyphenate/
- function_seven 8y ago
  I never knew about the  entity, but now I won't forget it. It's a hyphen, but a shy one!
packet_nerd 8y ago
Somewhat related, but not the same thing; I'm curious when Firefox will finally get proper line breaking support for Burmese and related languages? Burmese doesn't have spaces between words, just between phrases and sentences. Breaking lines between sentences results in really ugly jagged paragraphs. (I've ended up inserting Unicode zero width spaces between each syllable to get line breaking to work consistently in projects I've worked on.) Checking just now on Windows 10, Firefox and Edge aren't doing it correctly but Chrome and IE are. Even Windows Notepad is getting it right.
- roca 8y ago
  File a Mozilla Bugzilla bug? Firefox is meant to use Uniscribe line breaking for complex scripts on Windows, which should handle this.
crazygringo 8y ago
In English at least, I don't think hyphenation is ever really going to take off on the web, because most body text on the web is in a wide column and left-justified, since screens are wider rather than taller (unlike books and newspapers). Hyphenation is by far most valuable in narrow columns and particularly columns that are justified, because it allows for far more even spacing between words/letters. (I wonder, for example, if the NYT would ever adopt hyphenation in the narrow article blurbs on its home page, which are in narrow columns in a grid, although not justified.) Still, it's a pretty cool tool to have for the occasions when you do want it. (And the author mentions how valuable it is in German, so other languages may need it more.)
- tantalor 8y ago
  > screens are wider rather than taller What about mobile web
  - duxup 8y ago
    True, although even mobile screens can hold pretty dense blocks of text.
  - crazygringo 8y ago
    Excellent point, totally escaped me. Yes, I would love to see hyphenation take off more when reading articles on phones!
- matt4077 8y ago
  Almost all screens are far too wide for a single column of text. Most publishers with long-form text currently opt for a fixed maximum width. Considering the magazine standard is and has long been columns, it's not implausible to consider this a result of the limitations of HTML and CSS. Until fairly recently (and I'm not sure about support across all browsers even today), multi-column layouts were almost impossible, at least without all sorts of crutches and JS. Or maybe multi-column layout was/is a crutch for printed media, where a 5:32 ratio would be rather impractical to handle on a moving subway? Either way, the standard of about 60-character column widths is almost definitely the most ergonomical. And at that width hyphenation is quite useful.
aleem 8y ago
 support has been around for at least a decade and it can be done server side with any logic. It's probably not needed today but when I first used it the logic was along the lines of adding it at the 5th 7th 9th characters provided there were at least 4 more characters after each or some such while being wary of hanging the last word etc. It's a soft hyphen meaning the browser will break if needed otherwise ignore it. It's an HTML feature rather than a CSS one which also has implications.
- cryo 8y ago
 Awesome, didn't know about that one. MDN has a good page to see it in action, as well as comparison with https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wb...
munificent 8y ago
Is there any data on whether hyphenation actually improves reading speed? My hunch is that the problem it mostly solves is packing a greater number of words on a fewer number of printed pages, thus saving the printer money. But my impression as a reader is that I stumble over hyphenated words much more often than I am distracted by a particularly ragged right edge or a big river in a justified paragraph.
- ivanhoe 8y ago
  I have no data on it, but I presume it depends on a language heavily. In languages like English where words are not that long it'd be very counter-intuitive that hyphenation could help with reading speed as we don't read individual letters, we read word by word. Splitting words in two parts can only slow down the reader. In languages like German with a lot of very long words built by combining a few simpler ones, I presume hyphenation can be important tool to avoid having big holes in the text that could make it hard for readers' eyes to follow the lines of text.
  - chronogram 8y ago
    > very long words, hyphenation important Oh don’t worry I prefer words like “Kindercarnavalsoptochtvoorbereidingswerkzaamhedencomitéleden” to be one thing so I can just gloss over the blob. Only have to read the blob once to recognise the shape and know what it refers to. With hyphenation it’s a different blob every time, so then I might spend time reading 60 letters. Hyphenation is for newspapers, where space is money.
    - int_19h 8y ago
      On a small screen - say, smartphone - it might not be an option.
    - Tomte 8y ago
      If you want to skip over the blob, sure. But if you want to read it, hyphenation makes it much easier. Because your claim that there would be a "different blob every time" is not false, but misleading. There are different blobs, but they are all ones that can berecognized by shape. Because such long words would certainly be split up between their constituent words, not between random places. This actually makes a hyphenated composite word easier to read than the very long non-hyphenated form.
syphilis2 8y ago
There's an ff ligature on the page that got hyphenated for me. ("differences" under section 1)
atomwaffel 8y ago
On a slightly related note, I find it incredible that the Kindle (and presumably other e-readers) still fail to support typographic standards that printed books have had for hundreds of years. It took them years to support hyphenation at all, and now that they do, the number of times I’ve turned a page only to find it completely blank but for the very last syllable of the very last word of the chapter is infuriating. I know it’s a small thing, but it instantly rips me out of the story and reminds me of the imperfections of the thing. For a single-purpose device by one of the world’s largest tech companies, that’s just not good enough.
- a13n 8y ago
  What do you expect it to do differently in that case?
  - dcuthbertson 8y ago
    How about proper widow/orphan control?
  - bhaak 8y ago
    This is a problem since printed books exist. There are lots of different options: https://en.wikipedia.org/wiki/Widows_and_orphans#Guidelines https://en.wikipedia.org/wiki/Widows_and_orphans#Guidelines The kindle also doesn't support proper kerning. Sorry if I told you that and you can't unsee it now. But you can install 3rd party reading software on jailbroken kindles like koreader that fixes some of the deficiencies.
    - gsnedders 8y ago
      And we have the orphans and widows properties in CSS that provide some control across fragments, though they're not supported in Firefox (or EdgeHTML, for however much longer that matters).
    - UsernameProxy 8y ago
      I was just trying to find _koreader_ on the Play Store, but am not having much luck. What's the actual name, please?
Udo_Schmitz 8y ago
>The language of a webpage should be set using the HTML lang attribute: <html lang="en"> And if I want to have more than one language on the same webpage?
- err4nt 8y ago
 > And if I want to have more than one language on the same webpage? Simple, add more than one lang="" attribute. You can add them to _any_ HTML tag. Learn more about lang in HTML here: https://html.spec.whatwg.org/#the-lang-and-xml:lang-attributes https://html.spec.whatwg.org/#the-lang-and-xml:lang-attribut... And it can be really useful for styling purposes too - you can use CSS to style writing direction, font, text rendering settings, even which types of quotation marks to use for each language you want to specify Learn more about :lang() in CSS here: https://drafts.csswg.org/selectors-4/#the-lang-pseudo https://drafts.csswg.org/selectors-4/#the-lang-pseudo Or see an example of how it can be put to use here: https://github.com/mozdevs/cssremedy/blob/master/quotes.css https://github.com/mozdevs/cssremedy/blob/master/quotes.css
 - Udo_Schmitz 8y ago
 > Simple, add more than one lang="" attribute. You can add them to _any_ HTML tag. Thanks! Very helpful and thoroughly referenced :)
coldtea 8y ago
>Automatic hyphenation on the web has been possible since 2011 and is now broadly supported. Safari, Firefox and Internet Explorer 9 upwards support automatic hyphenation, as does Chrome on Android and MacOS (but not yet on Windows or Linux). If Chrome doesn't do it on Windows, then it just as well might not exist. Chrome has ~80% of the users, and Windows has a 90% as well. So Chrome/Windows is the most important combo. I wouldn't call this state "broadly supported" in any way.

184 points by kawera 8y ago

First impression: I like the nuanced control over where hyphenation happens, but can't help but wonder whether giving the browser control over the intraword hyphenation candidate points is a good idea. Don't we have soft hyphen characters in Unicode for exactly the purpose of letting authors precisely specify hyphenation candidate break locations?

Carpetsmoker 8y ago
It's U+00AD, or . While occasionally helpful, it's a complete pain to manually add though. Also I recently noticed Firefox seems to copy it, which is pretty annoying (didn't use to do that, I think).
- quotemstr 8y ago
  Yeah. Removing this character when copying to the clipboard is definitely the right thing to do. Have you filed a bug?
  - mrob 8y ago
    It doesn't sound like a bug to me. If I copy and paste something I expect to get all the Unicode characters. Only the CSS should be stripped. If the browser silently deletes Unicode characters then it's certainly going to cause unexpected data loss in some cases. Firefox is doing the right thing.
    - quotemstr 8y ago
      I consider soft breaks to be metadata, not data. Dropping soft hyphens doesn't affect the meaning of text and so doesn't drop information that humans care about. If it's not data loss that copy and paste doesn't propagate bold and italic formatting, it's not data loss that it doesn't propagate soft hyphens. Not every Unicode code point conveys information that we need to preserve.
      - mrob 8y ago
        It's not data loss if the bold or italic are in CSS or HTML tags, but if it's 𝐛𝐨𝐥𝐝 or 𝑖𝑡𝑎𝑙𝑖𝑐 like this (which I realize is not how Unicode is supposed to be used) then it's part of the text, just like soft hyphens.
        quotemstr 8y ago
        Soft hyphens only "part of the text" because the hyphens are represented using "in band signaling" instead of "out of band" signaling, as in proper bold and italic. It's still just information about the text, not the text itself.
        mrob 8y ago
        It's exactly because they're in-band signaling that they should be preserved. I don't expect copy and paste to change the sequence of Unicode code points. If the browser "helpfully" removes certain code points then it's more complexity I have to think about. The only change I'd consider acceptable would be changing to a specified Unicode normalization form. In this case the complexity already exists within Unicode, so the browser isn't making it worse.
matt4077 8y ago
How would this work? You cannot know the exact flow of text on each and every platform, so you would end up just manually specifying every possible hyphenation. That would seem to be a lot of work to create something that's almost definitely going to contain far more errors than a somewhat complete dictionary that ships with the browser.
- quotemstr 8y ago
  What about words that the browser doesn't know about? While automatic hyphenation point insertion is convenient, I want to retain the ability to provide manual overrides.
- frosted-flakes 8y ago
  Simple. Using a hyphenation dictionary, automatically insert soft hyphens at the optimal position in every word before delivery to the client. I haven't seen this done in practice, but I see no reason why it wouldn't work.

amelius 8y ago

A bit late. Why only now do we get support for this basic text formatting primitive?

_fzslm 8y ago
This has been supported since 2011.
- Carpetsmoker 8y ago
  Only hyphenate: auto has, and only in Firefox. Chrome didn't add support until 2 years ago. In my experimentation hyphenate: auto doesn't give good results; you need all the other hyphenate rules to get that, which aren't widely supported yet.
  - chinathrow 8y ago
    Chrome on Linux and Windows has no support: https://caniuse.com/#search=hyphens https://caniuse.com/#search=hyphens Also from the article: "Safari, Firefox and Internet Explorer 9 upwards support automatic hyphenation, as does Chrome on Android and MacOS (but not yet on Windows or Linux)."

jacobolus 8y ago

So when are browsers going to abandon their greedy line breaking algorithm and implement Knuth/Plass or similar? In my opinion that is the single biggest problem with web typography, and has been for years. Significantly more important than auto hyphenation. This has been a solved problem for 40 years (or at least 10–15, if we need to worry about fast performance for interactive use on a desktop computer). Should be table stakes for any software rendering long blocks of text.

chrisseaton 8y ago
Knuth/Plass seems to regularly need user input to resolve issues, at least in the TeX implementation - if that’s inherent can it be used in a browser?
- misterdoubt 8y ago
  For basic hyphenation of text paragraphs, it's been years since I felt the need to intervene in (La)Tex hyphenation. For typesetting more broadly, certainly. For making a clean right edge, no.
- svat 8y ago
  User intervention is (occasionally) needed in TeX only at its default settings, which are optimized for “rather than typeset any paragraph with a too-loose line, just give up and warn me loudly so I can take a look”. This makes sense for Knuth and his original goal of producing books. But it's not inherent; a combination of \tolerance=9999 (the default is 200) and \emergencystretch=\maxdimen makes it so that TeX will try to produce the best paragraph possible without requiring the user to intervene and rewrite the words. (Another alternative is to increase the stretchability and shrinkability of the interword glue.) And there will be no overfull boxes unless of course there's a single unhyphenatable word that by itself is longer than the line width. (LaTeX has a shortcut called \sloppy for achieving basically this, but the name scares people who don't understand the TeX algorithm.) Sometimes I think this should be the default: definitely the worst typesetting I've seen is in documents produced by people who ignored all the overfull box warnings; even the greedy algorithm of Word etc would be vastly preferable to that.)

massivecali 8y ago

Does this impact screenreaders?

frosted-flakes 8y ago
No. Screen readers ignore CSS text transformations like this.
- massivecali 8y ago
  Thanks, good to know.

frosted-flakes 8y ago

One problem for which there is no CSS solution yet is orphaned lines caused by floated images, when only the last line of a paragraph flows beneath the image. Particularly annoying with left-floated images in RTL text. I don't use floated images that often, but sometimes the design calls for it.

Theodores 8y ago

I imagine this can be combined with a media query so that you can use hyphenation differently on small screens when real estate might be lacking and the ragged edge takes up too much space. Time to experiment!

reaperducer 8y ago

Now if only there was a way to specify that paragraphs of text shouldn't leave an orphan word on the last line, I could use one CSS property to get the consultants off my back instead of having to preg_replace the last space in every paragraph with an  .

TheRealPomax 8y ago
You might at least be interested to know that you can also wrap those last(two or more) words in with the nobreak class using "white-space: nowrap;" so that your solution works across all languages, rather than just those where the non-breaking space doesn't looking horrendously out of place.
deleted 8y ago
[deleted]

undershirt 8y ago

Good to have this overview! I abandoned hyphenation in a project after seeing it behave so different from LaTeX’s. Looks like I missed some options. Related, I was looking at multi-column CSS for magazine or newspaper typesetting. The controls on column-breaking were not well supported, making it very difficult to not end up with ugly typography. Would love to see improvements there as well.

erichurkman 8y ago
If you want real typesetting via CSS, you can use PrinceXML. It does great hyphenation, column breaking, and has some extensions to CSS to allow similar controls as you'd get from LaTeX's column options. [0] https://www.princexml.com/doc/11/hyphenation/ https://www.princexml.com/doc/11/hyphenation/ [1] https://www.princexml.com/doc/11/floats/#float-extensions https://www.princexml.com/doc/11/floats/#float-extensions
- undershirt 8y ago
  Oops, I meant newspaper-like layouts for browser pages. But cool, I like the specific extensions PrinceXML has for column control. thanks for the reference, will try it if i need this for printing

robbrown451 8y ago

I am fine with just considering hyphenation a thing of the past. Do we really think it adds value? I find it far easier to read text that doesn't break words in half. So what if the right margin is a bit raggedy.

misterdoubt 8y ago
It adds considerable value if the goal is not more than getting some words on the screen" but rather "how is the best way I can possibly present this textual document." Personally, I find a very small proportion of text to fall into the latter category. But for those that do, clean presentation is huge.
- robbrown451 8y ago
  Could you give me an example of a type of document that falls into that latter category? Personally I don't think they make it look cleaner, but the opposite.
TheRealPomax 8y ago
Respectively: that's your perogative; yes; cool; typesetting matter, sometimes drastically, even if most of the time you don't even notice it. I have several "books" on the web, for which hyphenation is a godsend, especially as CSS is not just for that computer monitor you're staring at, but also for `media="print"`, which yes: matters even in 2019.
- robbrown451 8y ago
  Ok, well I personally find them a bit jarring, after years of mostly reading on the web where they are extremely rare. I remember typing papers on manual typewriters and having to think about where to hyphenate (as well as just when to do a carriage return), and it was awful. Admittedly now it is more of an aspect of reading (since an algorithm can do the actual hyphenation), but still. I would prefer we just abandon it. Could explain why it matters more on a printed page that on a monitor? I don't see any relevant differences.

crazygringo 8y ago

Curious how automatic hyphenation works with ambiguous words? E.g. to pro-ject an image but to work on a proj-ect. [1] Documentation does seem to suggest that inserting a soft hyphen  at the correct point will serve as a hint that automatic hyphenation should obey. [2] Not that many people are going to remember to bother. But wondering if any browser's automatic hyphenation dictionaries attempt to perform any contextual analysis such as part-of-speech tagging to try to get it right in ambiguous cases? [1] https://www.merriam-webster.com/dictionary/project https://www.merriam-webster.com/dictionary/project [2] https://css-tricks.com/almanac/properties/h/hyphenate/ https://css-tricks.com/almanac/properties/h/hyphenate/

function_seven 8y ago
I never knew about the  entity, but now I won't forget it. It's a hyphen, but a shy one!

packet_nerd 8y ago

Somewhat related, but not the same thing; I'm curious when Firefox will finally get proper line breaking support for Burmese and related languages? Burmese doesn't have spaces between words, just between phrases and sentences. Breaking lines between sentences results in really ugly jagged paragraphs. (I've ended up inserting Unicode zero width spaces between each syllable to get line breaking to work consistently in projects I've worked on.) Checking just now on Windows 10, Firefox and Edge aren't doing it correctly but Chrome and IE are. Even Windows Notepad is getting it right.

roca 8y ago
File a Mozilla Bugzilla bug? Firefox is meant to use Uniscribe line breaking for complex scripts on Windows, which should handle this.

crazygringo 8y ago

In English at least, I don't think hyphenation is ever really going to take off on the web, because most body text on the web is in a wide column and left-justified, since screens are wider rather than taller (unlike books and newspapers). Hyphenation is by far most valuable in narrow columns and particularly columns that are justified, because it allows for far more even spacing between words/letters. (I wonder, for example, if the NYT would ever adopt hyphenation in the narrow article blurbs on its home page, which are in narrow columns in a grid, although not justified.) Still, it's a pretty cool tool to have for the occasions when you do want it. (And the author mentions how valuable it is in German, so other languages may need it more.)

tantalor 8y ago
> screens are wider rather than taller What about mobile web
- duxup 8y ago
  True, although even mobile screens can hold pretty dense blocks of text.
- crazygringo 8y ago
  Excellent point, totally escaped me. Yes, I would love to see hyphenation take off more when reading articles on phones!
matt4077 8y ago
Almost all screens are far too wide for a single column of text. Most publishers with long-form text currently opt for a fixed maximum width. Considering the magazine standard is and has long been columns, it's not implausible to consider this a result of the limitations of HTML and CSS. Until fairly recently (and I'm not sure about support across all browsers even today), multi-column layouts were almost impossible, at least without all sorts of crutches and JS. Or maybe multi-column layout was/is a crutch for printed media, where a 5:32 ratio would be rather impractical to handle on a moving subway? Either way, the standard of about 60-character column widths is almost definitely the most ergonomical. And at that width hyphenation is quite useful.

aleem 8y ago

 support has been around for at least a decade and it can be done server side with any logic. It's probably not needed today but when I first used it the logic was along the lines of adding it at the 5th 7th 9th characters provided there were at least 4 more characters after each  or some such while being wary of hanging the last word etc. It's a soft hyphen meaning the browser will break if needed otherwise ignore it. It's an HTML feature rather than a CSS one which also has implications.

cryo 8y ago
Awesome, didn't know about that one. MDN has a good page to see it in action, as well as comparison with https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wb...

munificent 8y ago

Is there any data on whether hyphenation actually improves reading speed? My hunch is that the problem it mostly solves is packing a greater number of words on a fewer number of printed pages, thus saving the printer money. But my impression as a reader is that I stumble over hyphenated words much more often than I am distracted by a particularly ragged right edge or a big river in a justified paragraph.

ivanhoe 8y ago
I have no data on it, but I presume it depends on a language heavily. In languages like English where words are not that long it'd be very counter-intuitive that hyphenation could help with reading speed as we don't read individual letters, we read word by word. Splitting words in two parts can only slow down the reader. In languages like German with a lot of very long words built by combining a few simpler ones, I presume hyphenation can be important tool to avoid having big holes in the text that could make it hard for readers' eyes to follow the lines of text.
- chronogram 8y ago
  > very long words, hyphenation important Oh don’t worry I prefer words like “Kindercarnavalsoptochtvoorbereidingswerkzaamhedencomitéleden” to be one thing so I can just gloss over the blob. Only have to read the blob once to recognise the shape and know what it refers to. With hyphenation it’s a different blob every time, so then I might spend time reading 60 letters. Hyphenation is for newspapers, where space is money.
  - int_19h 8y ago
    On a small screen - say, smartphone - it might not be an option.
  - Tomte 8y ago
    If you want to skip over the blob, sure. But if you want to read it, hyphenation makes it much easier. Because your claim that there would be a "different blob every time" is not false, but misleading. There are different blobs, but they are all ones that can berecognized by shape. Because such long words would certainly be split up between their constituent words, not between random places. This actually makes a hyphenated composite word easier to read than the very long non-hyphenated form.

syphilis2 8y ago

There's an ff ligature on the page that got hyphenated for me. ("differences" under section 1)

atomwaffel 8y ago

On a slightly related note, I find it incredible that the Kindle (and presumably other e-readers) still fail to support typographic standards that printed books have had for hundreds of years. It took them years to support hyphenation at all, and now that they do, the number of times I’ve turned a page only to find it completely blank but for the very last syllable of the very last word of the chapter is infuriating. I know it’s a small thing, but it instantly rips me out of the story and reminds me of the imperfections of the thing. For a single-purpose device by one of the world’s largest tech companies, that’s just not good enough.

a13n 8y ago
What do you expect it to do differently in that case?
- dcuthbertson 8y ago
  How about proper widow/orphan control?
- bhaak 8y ago
  This is a problem since printed books exist. There are lots of different options: https://en.wikipedia.org/wiki/Widows_and_orphans#Guidelines https://en.wikipedia.org/wiki/Widows_and_orphans#Guidelines The kindle also doesn't support proper kerning. Sorry if I told you that and you can't unsee it now. But you can install 3rd party reading software on jailbroken kindles like koreader that fixes some of the deficiencies.
  - gsnedders 8y ago
    And we have the orphans and widows properties in CSS that provide some control across fragments, though they're not supported in Firefox (or EdgeHTML, for however much longer that matters).
  - UsernameProxy 8y ago
    I was just trying to find _koreader_ on the Play Store, but am not having much luck. What's the actual name, please?

Udo_Schmitz 8y ago

>The language of a webpage should be set using the HTML lang attribute: <html lang="en"> And if I want to have more than one language on the same webpage?

err4nt 8y ago
> And if I want to have more than one language on the same webpage? Simple, add more than one lang="" attribute. You can add them to _any_ HTML tag. Learn more about lang in HTML here: https://html.spec.whatwg.org/#the-lang-and-xml:lang-attributes https://html.spec.whatwg.org/#the-lang-and-xml:lang-attribut... And it can be really useful for styling purposes too - you can use CSS to style writing direction, font, text rendering settings, even which types of quotation marks to use for each language you want to specify Learn more about :lang() in CSS here: https://drafts.csswg.org/selectors-4/#the-lang-pseudo https://drafts.csswg.org/selectors-4/#the-lang-pseudo Or see an example of how it can be put to use here: https://github.com/mozdevs/cssremedy/blob/master/quotes.css https://github.com/mozdevs/cssremedy/blob/master/quotes.css
- Udo_Schmitz 8y ago
  > Simple, add more than one lang="" attribute. You can add them to _any_ HTML tag. Thanks! Very helpful and thoroughly referenced :)

coldtea 8y ago

>Automatic hyphenation on the web has been possible since 2011 and is now broadly supported. Safari, Firefox and Internet Explorer 9 upwards support automatic hyphenation, as does Chrome on Android and MacOS (but not yet on Windows or Linux). If Chrome doesn't do it on Windows, then it just as well might not exist. Chrome has ~80% of the users, and Windows has a 90% as well. So Chrome/Windows is the most important combo. I wouldn't call this state "broadly supported" in any way.