My take on "Responsive Line Breaks"

It is this tweet from Mathias Bynens that made me look into an article titled Responsive Line Breaks.

Looks like “responsive <br>” is the new <wbr>: mths.be/bir(Details on <wbr> can be found here: whatwg.org/html/text-leve….)

— Mathias Bynens (@mathias) August 9, 2012

Dan Mall‘s technique

The idea behind Dan’s article is to create a line break at a specific position within the string when the viewport is less than a certain width.

Let’s check the markup and CSS Dan uses for this trick:

Markup

<h1>
    You don’t understand! I coulda had class.
    <br class="rwd-break">I coulda been a contender.
</h1>
    

Which renders as:

You don’t understand! I coulda had class.
I coulda been a contender.
    

CSS

@media screen and (min-width: 768px){
   .rwd-break { display: none; }
}
    

If the viewport is 768 pixels wide or larger, the <br> is "removed" which results in the following:

You don’t understand! I coulda had class. I coulda been a contender.
    

In short, the line break is toggled by swapping the style of the <br> in the markup, from display:none to display:block. This switch happens when the viewport is greater than 767 pixels or smaller than 768 pixels (768px is an arbitrary value).

Note: I used a similar technique myself years ago, when working on Yahoo! Site Solution templates. But at the time some browsers didn’t play ball with display:none and I had to rely on float:left for those. So keep this in mind if you’re targeting old browsers.

Limitations and other concerns

I see a few issues with this approach:

Semantics

As Mathias suggested, <br> may not be the most appropriate element for this. A <br> forces a line break, whereas a <wbr> allows a line break; which is what this technique tries to do.

Progressive enhancement

This technique goes against the basic as it is built on markup that creates a display authors want to emulate as a "fallback" (it should be the other way around).

Break point

Using a hard coded value for break point is not scalable. Besides, the wrapping could be triggered by parameters other than the viewport width. I’m thinking of user’s settings (font-size) and internationalization which makes the breakpoint value a moving target.

Solving all problems at once(?)

In WebKit, one can address all issues and concerns by marrying <wbr> with white-space:nowrap.

Markup

<h1>
    You don’t understand! I coulda had class.
    <wbr>I coulda been a contender.
</h1>
    

Which renders as:

You don’t understand! I coulda had class. I coulda been a contender.
    

CSS

@media screen and (-webkit-min-device-pixel-ratio:0) and (min-width:400px) {
    h1 {
        white-space: nowrap;
    }
}
    

This media query is to make sure we allow wrapping in any viewport smaller than 400 pixels, where I believe techniques like these have less value. So we still have the exact same rendering:

You don’t understand! I coulda had class. I coulda been a contender.
    

The magic will happen whenever wrapping is triggered. Either because of the width of the viewport, localization of the string, or font-size value. In short, there is no break point per se.

Cross-browsers solution

I’ve been using a different method for a while, but it is much less semantic as it requires to wrap part of the string inside a span (or else). That element styled with nowrap forces the whole chunk to drop on a second line at once – whenever the parent container is not wide enough to accommodate the string in its entirety. There is no need for an arbitrary "break-point", media query or anything. And because of its simplicity, it works across browsers, including oldIE…

Check the Demo.