Add a word-wrap to .comment-content about _s

[mfields]

I will usually add something like:

.comment-content a {
    word-wrap: break-word;
}

How does everyone else address this issue?

[iamtakashi]

@mfields, that's how I do too. I think it's a good idea to add this to _s as long as it's only for anchors.

[philiparthurmoore]

@iamtakashi:

as long as it's only for anchors.

Any reason not to extend it out to the entire comment content area as @zhirkovski has proposed?

[ashfame]

+1 for @philiparthurmoore's question, why not extend it to comment content area as well?

[monkviper]

Agree with @mfields

[philiparthurmoore]

I prefer @zhirkovski's approach here. There's no guarantee that site owners and commenters will enter long URLs and wrap them in anchors properly in comment content, and even in cases where WordPress may automatically detect plain text URLs and turn them into links, we cannot be sure that comments will always be free of typos or missing spaces. I see no reason not to get a bit less specific with the rule.

[philiparthurmoore]

It may also be worth adding a few extra rules in addition to the ones proposed:

-webkit-hyphens: auto;
-moz-hyphens: auto;
hyphens: auto;
word-wrap: break-word;

Thinking more about this, beyond this specific Issue, I raised a point with Twenty Twelve about long URLs in site content that makes me think _s should in general have all of its bases covered for .site-content article, .widget-area .widget, and (possibly) .comment-content. These are the three most vulnerable areas to long URLs breaking stuff, especially in small viewports, and we can't rely on proper anchors being set by users to account for instances of super-long plain text URLs, which I don't consider to be edge cases at all.

[mfields]

A couple of reasons for more specific styles in comments:

• Raw urls entered in the comment text are automatically wrapped in anchor text via the make_clickable fliter.
• Anchors are likely to be styled differently than surrounding text either color, text-decoration, font-stuffs, etc plus the generally have a hover/active/focus state style. It is easier to see that an anchor has been wrapped because of these styles.
• Minimizing the scope of the selector to anchor-only could avoid potential conflicts with yet to be seen bugginess.
• Comment content is not preview-able like post content and is generally written by visitors that comment and then leave.
• I generally do not like break word especially when textual content is involved. I do not consider super-long anchors to be readable as they are generally comprised of metric ton of crypitc query parameters. Breaking something that is not intended to be read seems better than breaking something that is.

[iamtakashi]

When I come across this issue, it's mostly happening on URLs and I'm not 100% certain if there is unknown issue caused by applying this with a broad scope.

I also think we should take care of hyphenation too if we were applying this to the container, but as mfields says and for the same reason, I personally don't like using break-word for other textual content.

[philiparthurmoore]

FWIW, I don't really like this very much either. I'm with both @mfields and @iamtakashi in sentiment but in practice I've run across cases (especially on small viewports) where even moderately sized URLs or text (not crazy-long URLs) breaks layouts, so I tend to be a bit sensitive and overcautious.

[philiparthurmoore]

I've been thinking more about this—and a few annoying cases of hyphenation messing things up on WordPress.com (Firefox and Safari) came up recently—and I'm going to have to pull a flip-flop and completely get on board with @mfields and @iamtakashi here, voting for a more specific selector (in this case, a).

We've seen a couple of examples of hyphenation causing ugly results in not specific enough widget areas, for example:

Some words work well, for example "Smooth":

But some words look pretty bad, for example "brotherhood":

So, I don't think we should completely abandon hyphenation or word breaking (I think they serve a pretty nice purpose), but I also admit to being a bit scared to make the rules so broad.

I think @mfields gives a solid suggestion:

.comment-content a {
    word-wrap: break-word;
}

Hangs head in shame

Finally Seeing The Light,
Waffles

[philiparthurmoore]

Thinking even more about this, the reason I keep going back and forth with this issue is because of stuff like this website's comment area: http://pipress.vo3.net/?p=6.

If you look at that site in a "normal" browser (it's using Twenty Twelve), the comments on the page will look fine, but if you view it on an iPhone, the comments destroy the layout because there's no word breaking for non-linked URLs (basically just long text):

I'm sensitive about this because I tend to browse casually on my iPhone a lot, viewing sites in a smaller viewport and finding myself annoyed beyond measure when a layout looks broken because of long text.

As to whether or not we get overly aggressive in _s is up for discussion, of course, but in my personal work (and even the stuff I do on .com) I think I'm going to be a bit more cautious, at least in smaller views. It seems like at least once a week or every few days I'm running into layouts looking terrible on smaller views due to long text (or moderately sized text in nested comments or slim areas, not just URLs), and the above rules (more general, less specific) are the only way I've been able to deal with it in a sane manner.

[mfields]

@philiparthurmoore I can see what you mean by the screenshot. Two things come to mind:

• Twenty Twelve is allotting 50% of available screen width for comment content which adds to this problem.
• The url has somehow bypassed the make-clickable filter. Do you know how this might happen?

[philiparthurmoore]

@mfields

The url has somehow bypassed the make-clickable filter. Do you know how this might happen?

I do not.

I've recently performed a few tests against WordPress 3.5-RC5 and the only instances that fail are when a space between preceding text and URLs is missing, not including colons.