The Importance of Manually Breaking Lines of Text | Hacker News Reader

The Importance of Manually Breaking Lines of Text

maxsavin.com

24 pointsmaxsavin43 comments

This is terrible advice and is a massive hack as well as being a terrible misuse of hr element.

Also I'm not sure I want to take advice on how to lay out my content from someone who claims to be a designer but has his content in such a limited space (less than 40% of my screen space on a 15 inch monitor) and all the way to the left.

Text is easier to read when narrow. Agree on the centering.. working on some solutions for it. I only had ~1h to put into the site.

Text is annoying to read when it's too narrow, yours is too narrow. Bumping it up from 500px to 800px makes it look less sparse and is still readable.

For the centering, margin: 0 auto; on .textWrapper is an improvement.

Goes against the MD style of the homepage.. trying to find another solution.

Making the content 800px wide and setting the margin the same way looked perfectly fine on both the blog post and the home page, much better than all the way to the left and smaller.

> Text is easier to read when narrow.

Have you A/B tested that?

This is such a bad idea that I had to comment here:

1. Doesn't scale. You do not want to hand pick text all over your site/web-app. 2. It's not semantic. 3. It's very confusing to new people who looks at your code. 4. If you ever change a single char in that sentence, you will have to re-break it yourself.

Thanks for commenting. It's a great idea from a design and readability perspective. It sounds like you do not like my implementation - you could be right. Here is another way of doing it.. maybe I'll update the post late:

with the appropriate @media query.

It's obviously not for every situation. But for landing and marketing pages, headlines, etc, I'd go as far as to say it's absolutely essential.

I've also done simply:

First line Second line

Make em block level in css, collapsing to display:inline at small sizes. (Can even set the size with a specific class, bootstrap-style).

Yeah that works, but it creates a lot of code. <hr> is just 4 characters, and reminds me a lot of , so its easy to read. Once you adapt your perspective to it, it becomes really awesome.

<hr> is a poor choice from an accessibility perspective. You should use a instead.

This really only seems to work if you know the exact pixel width of the text in question. This would happen if you don't know the font being rendered or actual text in advance, which are both common occurrences in web development.

Nah, you just don't need to know the exact pixel width.

For this example, you just need to know that the full sentence is likely to break some place on a large screen, and that the half-sentences are likely to fit without breaking on certain size screens.

Maybe you need the boundaries of likely maximum and minimum pixel widths, you certainly don't need to know the exact pixel width.

This is more of a finishing touch, rather than something you would do initially.

I'm talking about a deployed production app also.

Css has font fall-backs for a reason, and if you ever use them, that means you don't know which font is actually being rendered. Which is not to mention platform differences for rendering even the same fonts.

And if any part of the text is variable, which is pretty much the basis for web apps, then you have another problem.

It would be pretty great if there was something like that you could use for this scenario.

Sure you can certainly run into that issue in some cases, that's where your judgement as a developer should kick in.

Why not just use a BR and set its "display" to "none" at the appropriate breakpoint(s)? Why abuse HR in this way?

You can't do display none for BR element. But even if you could, you wouldn't want to overwrite it for the entire website. Also, the HR element is a very old, largely unused, and styleable, so its a good candidate for this.

"display: none;" works just fine for BRs!

Sure, you don't want to override it for the entire web site, but if you're being specific enough about showing/hiding line breaks at certain breakpoints, then I don't see why you can't just specify with the class of the container (or whatever) which particular BR you want to hide in a given context.

You also may want the flexibility of both. For example:

Headline The quick brown fox jumped<hr> over the lazy dog.

And the code is clear and easy to read.

Hmm.. good point, it wasn't working when I tried it. But I still prefer to include it on a high level into my CSS frameworks. Set it, forget it, and use freely.

At least a few people on HN use Lynx - they won't like you much for this!

Why on earth would you use Lynx?

Because you are blind?

Lynx and Dillo are very fast. Also lightweight.

Not sure if "largely unused" is right. I use them all the time, and have seen them in pretty common use around the place.

Ah, I think you are in a minority. Or maybe I'm very opinionated :)

This is a great technique and I've been using it on projects for over a year now. This is the first time I'm seeing anybody else write about it or use the technique!

One question for the author: Why repurpose a Horizontal Rule <hr> when HTML has a perfectly functional Line Break tag ?

You can use @media queries to set display: none; on tags and then those tags have no effect, and then you get to decide when they kick in.

This is a great idea, but ignoring the built-in line break to repurpose and restyle the horizontal rule tag seems like an arbitrary choice for implementing the technique.

Thanks for the positive feedback! My reasons are: 1) You still want to have the option of a "hard" BR 2) I want to set the HR as a high level class, so I can use it freely through whatever I'm working on.

For example:

Headline

The quick brown fox jumped <hr>

over the lazy dog.

You 100% want the line break after the headline, and want to set an optional one in the subtext.

I like it because its very clean to look at, but you can also create a responsive class like <div class="desktop-breakline"></div>

If you're going as verbose as using a class, just put the class on the br tag.

Headline The quick brown fox jumped over the lazy dog.

This is what I did originally,

But now I'd rather just use the media query to only affect the inside of the H1 or other container where the line break appears.

Another consideration I didn't see in the article that I train the people updating the marketing copy: put your white space before the line break. When it's all inline it will display as one line, but you don't want to have a space after the line break at the start of the new line. programmers may be conscientious of where the white space is but its a real eye-opener for marketing-types who only pay attention to the content, not the space around it!

Sounds more like CSS needs a way to set Widows and Orphans control. Just like it has lacked hyphenation for quite a while. Does anyone know if such a thing has been discussed?

This is a rehash of a much more fleshed-out idea from here: http://blogs.adobe.com/webplatform/2013/01/30/balancing-text...

They even wrote a jQuery plugin to implement the described behavior: https://github.com/adobe-webplatform/balance-text

"""

> This page cannot be displayed because your computer is currently

> offline

"It looks pretty ugly - I hope you can understand why." """

But its not. When I see that, my eye is immediately drawn to the word that is on its own: offline. And what is the most salient piece of info in that error message? The fact that my computer is offline.

http://en.wikipedia.org/wiki/Widows_and_orphans

http://m.imgur.com/LIbRZaR

The Importance of Manually Breaking Lines of

Text.

If you need this level of control, use a PDF. This is not what html/css/javascript is for.

<hr /> for validity in both XHTML and HTML4

Updated

Who uses XHTML or HTML4?

I like this idea, thanks.

Welcome :)

Reply on news.ycombinator.com