If you ever have trouble tracking down what element is causing overflow, add this rule in the browser inspector:
* { outline: thin solid red }
This makes the bounding boxes of every single element visible. Very helpful.
The author mentioned using work-break: break-word. I have an open question on that rule: Is there any reason not to set it on the body on most sites? I’ve gone on quests to remove scrolling from user-entered content, and I end up setting word-break in a ton of different places. I’m not sure of the trade-offs of just setting it globally.
There’s also a nonstandard(?) CSS property to enable hyphenation; back in the day only WebKit supported it, but it might be more standard now. Sorry, I don’t remember the exact name.
At one point long ago my blog had a layout where each post was one column of text, with the latest post on the left and older posts extending rightwards. I thought it worked well; you could scroll left-right to look at different posts’ titles and ledes, then downwards to keep reading a post. It was a PITA to implement, but that was with mid-00s tech and I’ve never felt really competent at CSS. I didn’t have a smartphone at the time, but it should have been readable on one.
It’s been a standard for quite a while already. Firefox supported the unprefixed version of that property for five years already, on all platforms; Chrome was limited to macOS and Android until this year. See https://caniuse.com/css-hyphens
I’ve been using it on my site for a couple of years already, with a @supports (hyphens: auto) check to fall back to left align in browsers that don’t support it.
I generally recommend against hyphens in many cases related to the web. The engines just aren’t as good in the browser as ones designed for print like Scribus or InDesign. In print you wouldn’t want orphans (a broken or single word as the first part of a new lines). For aesthetics, you wouldn’t want more than 3-4 lines in a row with hyphens. You would want letter-spacing to be a range so the engine could squeeze words here and there to avoid hyphenations (this really matters with text-align: justify where you’ll get sizeable rivers in your document). You would want hanging-punctuation (available in Webkit) so the hyphens don’t jut the text inwards to much for better perceived visual balance. With these limitations in the current state of web typography, it generally looks nicer to just leave the defaults for justification and hyphens.
Ideal scroll direction is contextual. A phone held upright and scrolled with the thumb of that hand needs vertical scrolling. Horizontal scrolling works better for a tablet held landscape on your lap and swiped with a free hand.
Some thoughts on horizontal overflow:
If you ever have trouble tracking down what element is causing overflow, add this rule in the browser inspector:
This makes the bounding boxes of every single element visible. Very helpful.
The author mentioned using
work-break: break-word. I have an open question on that rule: Is there any reason not to set it on the body on most sites? I’ve gone on quests to remove scrolling from user-entered content, and I end up settingword-breakin a ton of different places. I’m not sure of the trade-offs of just setting it globally.Some googling reveals that
break-wordis not CJK-aware, but I’m no expert myself. I only publish English content, so this is fine for me :)There’s also a nonstandard(?) CSS property to enable hyphenation; back in the day only WebKit supported it, but it might be more standard now. Sorry, I don’t remember the exact name.
At one point long ago my blog had a layout where each post was one column of text, with the latest post on the left and older posts extending rightwards. I thought it worked well; you could scroll left-right to look at different posts’ titles and ledes, then downwards to keep reading a post. It was a PITA to implement, but that was with mid-00s tech and I’ve never felt really competent at CSS. I didn’t have a smartphone at the time, but it should have been readable on one.
It’s been a standard for quite a while already. Firefox supported the unprefixed version of that property for five years already, on all platforms; Chrome was limited to macOS and Android until this year. See https://caniuse.com/css-hyphens
I’ve been using it on my site for a couple of years already, with a
@supports (hyphens: auto)check to fall back to left align in browsers that don’t support it.I generally recommend against hyphens in many cases related to the web. The engines just aren’t as good in the browser as ones designed for print like Scribus or InDesign. In print you wouldn’t want orphans (a broken or single word as the first part of a new lines). For aesthetics, you wouldn’t want more than 3-4 lines in a row with hyphens. You would want
letter-spacingto be a range so the engine could squeeze words here and there to avoid hyphenations (this really matters withtext-align: justifywhere you’ll get sizeable rivers in your document). You would wanthanging-punctuation(available in Webkit) so the hyphens don’t jut the text inwards to much for better perceived visual balance. With these limitations in the current state of web typography, it generally looks nicer to just leave the defaults for justification and hyphens.Ideal scroll direction is contextual. A phone held upright and scrolled with the thumb of that hand needs vertical scrolling. Horizontal scrolling works better for a tablet held landscape on your lap and swiped with a free hand.