JW eMail stack: Non-breakable urls in email body forces column to go wide

(Greg Schneck) #1

This is not really a RW or eMail stack issue but I’m hoping someone has a simple solution to this. I have a two column email defined (a main body and “sidebar”). The main body is twice as wide as the sidebar.

The problem:
Our opt-in mail list is for reports that contain lot’s of web references (citing source material). A lot of times the url’s have enough non-breakable characters that the line won’t fit the column width and the body is forced wider than defined, taking width from the sidebar which I don’t want. (ie: The non-breakable url is longer than the col width.)

These reports are provided to me by the client, so I’m not entering original text… They are rather long and some contain many urls.

Other than manually breaking the offending url onto two lines, is there a simpler solution to this problem?

(Doug Bennett) #2

If you had a sample would help.

If you have a class or id you could try:

    .theClass {
    word-wrap: break-word;

(Isaiah Carew) #3

The problem is that most normal text has words and the default behavior for a web browser is to display words unbroken.

So if you have something that’s not really a real word (like a really long email address) then the web browser just displays it on one line – and forcing the line to be as long as it needs to.

But those things are changeable in CSS. For this tiny bit of your page you’d to modify the rule, you’d like it to just break the “word” up anywhere and wrap it to the size column or screen or whatever.

If the code in question is your own, then you can add a bit of HTMLCSS to it to change the “word-break” property. It looks like this:

(this example will also not display well here on the forum – you’ll have to copy and past this to Coda or some other HTML editor to see it in action)

<span style='word-break:break-all'>ThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddressThisIsAReallyLongEmailAddress@gmail.com</span>

If it’s a 3rd party stack and your use-case is the common one (like this is supposed to be an email field and long emails are expected) then the 3rd party developer should probably add that CSS to the field.

On the other hand, if you’re (ab)using this field in a not-very-usual way – entering in a giant bit of text/code where it doesn’t really belong – then you might just be out of luck. You can’t just go willy nilly applying the “break-all” style to everything – it would make the rest of your page look crazy. If that’s the case, then I’d recommend putting it inside of column and setting a fixed size on that column – at least temporarily while you work on the page.

(Greg Schneck) #4

Thanks @teefers and @Isaiah

Sadly, there is no unique class on the urls and that’s the only place I would want to use “break-word.” That seems to eliminate any css solution. For now I think my solution is to use “search/replace” in the original text given me to add wordbreak opportunity code:


That seems to be one solution to prevent long urls from over-running a container. At least it’s worked in a couple of tests. I have to take the text into BBedit anyway to convert smart quotes.

If I’m missing something on the CSS side let me know! Over the years I’ve done both - pasting the Pages text into a standard Text stack (don’t shoot me! I know, I know, not the best solution) and I’ve also copied the Pages text into TextEdit then saved as Inlined HTML. This HTML is then taken to BBedit and quotes “straightened.” But this approach retains the original Pages Bold and Italic formatting for me but gives me usable HTML.

(Isaiah Carew) #5

I suspect there are other solutions – unfortunately it really depends on what you’re doing, what sort of stack you’re using, where it is, etc. etc.

In other words: to help more specifically I would need a lot more specific info.

The Edit-Mode display doesn’t need to be display this text at all – and when it does, it can display it in a variety of interesting ways.
There’s lots of flexibility to Edit Mode. And a 3rd party stack can customize that display to exactly fit the need of the stack – without affecting the actual output content of the page.
To accommodate the huge variety of stacks that there are pretty much everything is flexible.

(Greg Schneck) #6

Thanks for the suggestions. Isaiah, as info only, this is in Joe Workmans email Text stack. I’m seeing that there are a number of differences between the RW Preview and the actual email result. But to be clear, the problem is simply too long a string of non-breakable characters so it’s not really the stacks fault. Obviously I had this same issue when building emails in drop and drag email editors too. aWeber, Constant Contact, etc.

This worked in the eMail text stack Preview but sadly, it DID NOT work in an actual test email. The url’s did not break.

.wrapper {
word-break: break-character;

(Greg Schneck) #7

Interesting… the JW eMail Inliner stack strips out <wbr>, that’s why it works in Preview but not the real email. An inliner I found at MailChimp leaves the <wbr> in the code.

(Joe Workman) #8

WBR is not supported in email clients. This is why it gets stripped. Remember that HTML for email is very different than HTML for websites.

(Greg Schneck) #9

@joeworkman Thanks for that response! Any ideas on how to make a very long link (url) break in client apps using your eMail text stack? There are no “standard” breakable characters in the problem links/urls.

(Jannis from inStacks Software) #10

Why aren’t you displaying just a link text, without displaying the long URL? I guess nobody will type the long URL into the browser by himself?

(Robert Ziebol 🖖🏼) #11

Could you use a URL shortener? - You answered my question below. I understand

(Greg Schneck) #12

These are reference type emails that go out and they contain lot’s of quotes and the client prefers the actual url to be there for citations and reference. Because of the citations I am directed to publish cited links just as the client provides. Please know that I do provide a text link for non-cited material.

In many cases, it would even be better for us if the client app DID NOT turn citation urls into active links. Some links are dead but they need to be there for citing/historical purposes.

I have discussed this issue with the Client and many website citations have been dropped if they are “dead” but not all. I know that citing a dead link is pointless but that is what the client wants so readers at least know the quote is just not being pulled from thin air. If anyone has any suggestions on this issue I’d be glad to listen.

(Mathew Mitchell) #13

Greg: OMG, I can feel your pain! Yikes.

Let me get this right: the client wants to use dead links so the reader KNOWS the quote is not being pulled from thin air? But it’s dead? As I reader I would absolutely think they are pulling things from thin air in such a case. (Actually I’d just think such a person is simply lying.) Using dead links would seem to undermine their credibility more than anything else. Why can’t they say, in essence, quote used from “such and such” originally but the post/page has been pulled down?

I know this doesn’t help you much, but this auto-ranks as crazy story of the day.

(Greg Schneck) #14

Surprise - Library of Congress blog article cites two good reasons for retaining broken links… Wikipedia makes a case that broken links have a purpose… they just need to be labeled as such.

Think about another example we are more used to. A particular printed book may be cited in another book but we know that the cited book will go out of print. Yet, probably, the citation will NOT be removed in any revision. It’s the same concept. But the “problem” is that there is no such thing as a “link” that is “merely a reference” and not a link.

(Mathew Mitchell) #15

Well that makes sense. As long as it’s clearly labelled as a broken link then there’s full disclosure.

(Robert Ziebol 🖖🏼) #16

Could you use an image of the link?!

(Greg Schneck) #17

I suppose a case could be made that a text link would still show the complete url in the new window if clicked on, but we also have a very large number of people who print the reports using a “print” button for printer freindly printing. I believe that only the text portion of the url is shown when printed. (In fact, we highly encourage people to print the reports for distribution.)

(Greg Schneck) #18

That’s a thought zeebe but I really don’t want to get into capturing link images…

(Greg Schneck) #19

Oh… and somehow I got off track here… MOST links are good links! So really I’m back to:
how do I make a good link break when it contains no breakable characters?"
How do I get email clients to break on any char (or word, including backslash) in links only?

(Greg Schneck) #20

One Solution:
Here’s what I’ll have to do for now… Copy the text of the whole long link, Manually break the link (good or bad) to two lines, make each line a text link using the whole link for the url of both “half” lines…

btw… css solutions I’ve tried work in RW preview, mail app preview (sending web app), but not in final actual email client.