By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,788 Members | 1,115 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,788 IT Pros & Developers. It's quick & easy.

How to break long URL's?

P: n/a
Hi,

I'm currently having a problem where a long URL or a line of text with
no spaces will break the design of a webpage, http://
blog.seoptimise.com/2007/01/how-to-add-delicious-and-digg-blog-
rss.html is an example of this.

Does anyone know if it's possible to break this text into multiple
lines using CSS?

Thanks in advance,
Kev

Feb 15 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a
On 15 Feb, 07:06, "kevgibbo" <kevgi...@gmail.comwrote:
I'm currently having a problem where a long URL or a line of text with
no spaces will break the design of a webpage,
Why is a URL visible to the design of a web page? In most cases, the
URL should be in a href but there's no reason to use it as the visible
link text.

If it is deliberately visible (and there are good reasons to), then
just place it on its own line and give it some distinctive and
smallish font. For URLs of the moderate size you describe, then it's
no problem to fit them on a single line, so long as they start from
the beginning of it.

Huge URLs are a bad idea, usually unnecessary and should ideally be
avoided at source by just not needing them to be so long.
Does anyone know if it's possible to break this text into multiple
lines using CSS?
I'd embed <brand I'd do it by hand. The useful contexts for doing
this are few and really only within "tutorials" and meta-pages about
the web itself. For anything else, then embed the link rather than
stating it visibly.

(Copying URLs for airline booking sites so that you can email them to
your partner to book holidays! Aargh!)
Feb 15 '07 #2

P: n/a
Scripsit kevgibbo:
I'm currently having a problem where a long URL or a line of text with
no spaces will break the design of a webpage, http://
blog.seoptimise.com/2007/01/how-to-add-delicious-and-digg-blog-
rss.html is an example of this.
Most importantly, don't put URLs into the _content_ proper, only into
attribute values (such as href="...") where long URLs won't hurt.

Roughly speaking, URLs should appear in the content proper only when a page
_discusses URLs_. For example, if you wish to write a page how to refer to
some documents by their URLs in web authoring or in email messages or print
media, you may need some sample URLs, which might be rather long. Then the
prime problem is to _prevent_ browsers from breaking them!

The point is that a long URL usually doesn't hurt in the content unless it
appears in the middle of a text paragraph, where it should not appear, or
you have a rigid page layout, which you should not have.

But it _is_ harmful is a browser breaks a URL after a hyphen "-", as it may
well do. How will the reader know or guess whether the hyphen is part of the
URL or just introduced by hyphenation in word breaking? (Admittedly,
experienced users know that browsers don't hyphenate. But not all users are
experienced. Besides, very experienced users know that browsers may
hyphenate - when a hyphenation hint has been given using the soft hyphen.)
Does anyone know if it's possible to break this text into multiple
lines using CSS?
If you do need to include long URLs into the text of a document, wrap them
inside <nobr>...</nobrmarkup. You may add <wbrtags after points where a
line break is allowed, but then you should use some delimiters or otherwise
make it clear to the user what constitutes the URL. That's the practical
way, and you just have to tolerate people who (correctly) scream
"nonstandard markup!". CSS could in principle be used for preventing breaks,
since
<nobr>foo</nobr>
effectively corresponds to
<span style="white-space: nowrap">foo</span>
but I don't see much point there. I don't really want to use more
complicated code when nothing else is gained in practice than the risk that
my URLs are broken when CSS is off. So this is a job for HTML, not CSS.

In the CSS 3 drafts, there's the word-wrap property that could be used to
suggest that _any_ line break is allowed in a string, using word-wrap:
break-word. IE supports this. But it's really something to be avoided. It
would violate common sense, readability, and several standards and
recommendations to break a URL _arbitrarily_.

More info: http://www.cs.tut.fi/~jkorpela/html/nobr.html

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 15 '07 #3

P: n/a
On Feb 15, 2:06 am, "kevgibbo" <kevgi...@gmail.comwrote:
I'm currently having a problem where a long URL or a line of text with
no spaces will break the design of a webpage, http://
blog.seoptimise.com/2007/01/how-to-add-delicious-and-digg-blog-
rss.html is an example of this.
I'm not saying you *should* do this, as the other folks to reply have
pointed out reasons not to. But I have a couple of suggestions if you
want a wrappable URL (or other rediculously long "word" or content
with no spaces). Instead of inserting hyphens, how about the zero-
width non-joiner? (&zwnj;) Or, you could insert spaces, and class
the anchor or a span element "collapsespaces" and then use the
following CSS:

..collapsespaces {
word-spacing: -.33em;
}

Semantically, the spaces are still there, which is why zwnj is
probably a better idea. Also, you might have to tweak the specified
value depending on the font you're using, but most fonts' space
character has an advance width of very close to 1/3 EM.

I agree with the others who have replied to this thread that, in most
cases, a long URL should not appear in content. But I can imagine a
few situations when it might be of use, possibly even in a narrow but
still variable-width column of text that needs to stay narrow. Or
perhaps it's not a URL but a very long (possibly invented) word, or a
string of some specialized notation where spaces are sparse. It's for
these situations that my advice is intended.

--
Vid the Kid

Feb 15 '07 #4

P: n/a
Thanks for all of your help, I noticed this page has broke the URL
that I posted and seem to have done this using nowrap within the
stylesheet and inside <tdtags. Is this a good way to do it?

Cheers,
Kev
www.seoptimise.com

Feb 15 '07 #5

P: n/a
In article
<11**********************@v33g2000cwv.googlegroups .com>,
"kevgibbo" <ke******@gmail.comwrote:
Thanks for all of your help, I noticed this page has broke the URL
that I posted and seem to have done this using nowrap within the
stylesheet and inside <tdtags. Is this a good way to do it?
Its a different problem in email and newsgroup posts, best to
wrap urls in <in these cases...

--
dorayme
Feb 15 '07 #6

P: n/a
dorayme <do************@optusnet.com.auwrote in news:doraymeRidThis-
86*******************@news-vip.optusnet.com.au:
Its a different problem in email and newsgroup posts, best to
wrap urls in <in these cases...
OT alert:
For these situations I use tinyurl:

http://tinyurl.com/

(there's a tinyurl creator addon for FireFox: rightclick any page and
choose 'create tinyurl' to copy the created url to your clipboard)

Feb 15 '07 #7

P: n/a
Dirk wrote on 15 feb 2007 in comp.infosystems.www.authoring.stylesheets:
dorayme <do************@optusnet.com.auwrote in news:doraymeRidThis-
86*******************@news-vip.optusnet.com.au:
>Its a different problem in email and newsgroup posts, best to
wrap urls in <in these cases...

OT alert:
For these situations I use tinyurl:

http://tinyurl.com/

(there's a tinyurl creator addon for FireFox: rightclick any page and
choose 'create tinyurl' to copy the created url to your clipboard)
... or make a IE favelet called tiny.url:

[InternetShortcut]
URL=javascript:void(location.href='http://tinyurl.com/create.php?
url='+location.href)

[on one line!]

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 15 '07 #8

P: n/a
Scripsit Vid the Kid:
But I have a couple of suggestions if you
want a wrappable URL (or other rediculously long "word" or content
with no spaces). Instead of inserting hyphens, how about the zero-
width non-joiner? (&zwnj;)
Did _you_ actually try it? By definition, the zero width non-joiner prevents
joining and ligature behavior. It's not meant for line breaking control. It
is (by Unicode) in line breaking class CM, which pretty much means that it
is ignored in line breaking. Technically it _prevents_ line breaks in
certain contexts. Modern browsers seem to treat it that way. Older browser
may get wild, since they might not know about this character and might try
to display it and end up with displaying a symbol for a missing character.
Or, you could insert spaces,
A space within a URL is simply an error.
and class
the anchor or a span element "collapsespaces" and then use the
following CSS:

.collapsespaces {
word-spacing: -.33em;
}
And stay tuned to unpredictable results, since you cannot _know_ the width
of a space. Besides, the page would have a normal space when CSS is off.
Semantically, the spaces are still there, which is why zwnj is
probably a better idea.
Sorry, but they are both completely wrong ideas.
most fonts' space
character has an advance width of very close to 1/3 EM.
Little does it help to think that way, if the rendering is all messed up
when your guess is wrong.

Besides, your guess is _generally_ wrong. In the average, a space is 1/4 em
(.25em) wide. See e.g.
http://www.microsoft.com/typography/...ec/spaces.aspx
(or do some testing, using different fonts).

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 15 '07 #9

P: n/a
Thu, 15 Feb 2007 15:39:56 +0200 from Jukka K. Korpela
<jk******@cs.tut.fi>:
Most importantly, don't put URLs into the _content_ proper, only into
attribute values (such as href="...") where long URLs won't hurt.
The problem with that is when the user prints a document, the printed
copy has no indication what the URL is. (Lynx offers an option to do
it as a set of endnotes, but I don't know of another browser that
does.) Sometimes that doesn't matter, sometimes it does.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Feb 16 '07 #10

P: n/a
In article <MP************************@news.individual.net> ,
Stan Brown <th************@fastmail.fmwrote:
Thu, 15 Feb 2007 15:39:56 +0200 from Jukka K. Korpela
<jk******@cs.tut.fi>:
Most importantly, don't put URLs into the _content_ proper, only into
attribute values (such as href="...") where long URLs won't hurt.

The problem with that is when the user prints a document, the printed
copy has no indication what the URL is. (Lynx offers an option to do
it as a set of endnotes, but I don't know of another browser that
does.) Sometimes that doesn't matter, sometimes it does.
Good point I think. A reason then to have a print css sheet...

--
dorayme
Feb 16 '07 #11

P: n/a
On Thu, 15 Feb 2007, Vid the Kid wrote:
Instead of inserting hyphens, how about the zero-
width non-joiner? (&zwnj;)

Semantically, the spaces are still there, which is why zwnj is
probably a better idea.
Rubbish. The zero-width non-joiner (ZWNJ) exists to prevent
the joining of letters especially in the Arabic script and
in Indic scripts. Look at the source text of
http://www.unics.uni-hannover.de/nht...-alphabet.html
http://www.unics.uni-hannover.de/nht...onal-text.html
Feb 16 '07 #12

P: n/a
Scripsit dorayme:
In article <MP************************@news.individual.net> ,
Stan Brown <th************@fastmail.fmwrote:
>Thu, 15 Feb 2007 15:39:56 +0200 from Jukka K. Korpela
<jk******@cs.tut.fi>:
>>Most importantly, don't put URLs into the _content_ proper, only
into attribute values (such as href="...") where long URLs won't
hurt.

The problem with that is when the user prints a document, the printed
copy has no indication what the URL is. (Lynx offers an option to do
it as a set of endnotes, but I don't know of another browser that
does.) Sometimes that doesn't matter, sometimes it does.

Good point I think. A reason then to have a print css sheet...
Well, yes, you could have

@media print { a[href]:after
{ content: " <" attr(href) ">";
font-size: 90%; } }

But there are a few problems:
a) how to break long URLs (no way really here)
b) lack of support on IE
c) relative addresses - if href value is relative, attr(href) denotes it and
not the resolved absolute address.

Writing the address explicitly after a link and suppressing it on all media
except print works relatively well as such, but it's awkward to do and to
maintain. In that approach, however, you can use <wbrat will. The approach
might be feasible for some _selected_ important links.

Several browsers _have had_ options to print a list of links at the bottom
of a printed version, but apparently they were not considered as important
enough.

Most importantly, I'd say, the URL of the page itself gives access to
documents linked from it. The user can make the URL printed, or even write
it down, and the author should just try to make the URL as natural and
simple as possible. Even if it is slightly complex, it is more convenient to
use it to access the linked documents than to type the URLs of the linked
documents (which might very long and very messy "database URLs" for
example).

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 17 '07 #13

P: n/a
On Feb 15, 5:59 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fiwrote:
Scripsit Vid the Kid:
But I have a couple of suggestions if you
want a wrappable URL (or other rediculously long "word" or content
with no spaces). Instead of inserting hyphens, how about the zero-
width non-joiner? (&zwnj;)

Did _you_ actually try it? By definition, the zero width non-joiner prevents
joining and ligature behavior. It's not meant for line breaking control. It
is (by Unicode) in line breaking class CM, which pretty much means that it
is ignored in line breaking. Technically it _prevents_ line breaks in
certain contexts. Modern browsers seem to treat it that way. Older browser
may get wild, since they might not know about this character and might try
to display it and end up with displaying a symbol for a missing character.
So, then, *is* there a Unicode character defined to behave like a
space but without any advance width? I'd think that would be useful
in some situations...
Or, you could insert spaces,

A space within a URL is simply an error.
Not if it's intended for visual consumption only, and the space is
minimized in some way. But yes, semantically it is wrong, which I
noted, and it would cause problems trying to copy the URL (or other
long word or notation string) to the clipboard correctly.
most fonts' space
character has an advance width of very close to 1/3 EM.

Little does it help to think that way, if the rendering is all messed up
when your guess is wrong.

Besides, your guess is _generally_ wrong. In the average, a space is 1/4 em
(.25em) wide. See e.g.http://www.microsoft.com/typography/...ec/spaces.aspx
(or do some testing, using different fonts).
The 1/3 value did actually come from some testing (but only with a
couple fonts at bodytext size, so the margin for error was about the
difference between 1/3 and 1/4 EM) and I think I actually checked the
exact value for one font in a font editing program...
Sorry, but they are both completely wrong ideas.
Completely wrong? Well OK, one just doesn't work (bad assumption on
my part) and one works with limited reliability and is semantically
incorrect. But it would seem there's no right way to do what the OP
wants, and I was trying to be more helpful than to just say "don't do
it." Because I can think of some examples (explained in my earlier
post) where the need is justified.

--
Vid the Kid

Feb 17 '07 #14

P: n/a
On 2007-02-17, Vid the Kid <vi*******@gmail.comwrote:
[...]
So, then, *is* there a Unicode character defined to behave like a
space but without any advance width? I'd think that would be useful
in some situations...
Yes there is, called "ZWSP" (zero-width space), which is the character
U+200B or as a decimal entity ​ or use the nonstandard tag <wbr>.

I'm not keen on nonstandard tags myself but check
http://www.cs.tut.fi/~jkorpela/nobr.html#suggest
Or, you could insert spaces,

A space within a URL is simply an error.

Not if it's intended for visual consumption only, and the space is
minimized in some way. But yes, semantically it is wrong, which I
noted, and it would cause problems trying to copy the URL (or other
long word or notation string) to the clipboard correctly.
Wouldn't the clipboard end up containing the U+200B characters? Depends
on the OS perhaps. This would cause much confusion if pasted into a url
entry control in a browser-- the url would look right but be wrong.
Feb 18 '07 #15

P: n/a
Scripsit Vid the Kid:
>A space within a URL is simply an error.

Not if it's intended for visual consumption only,
A URL is a URL is a URL. An error is still an error, even if you make it
visible.
>Sorry, but they are both completely wrong ideas.

Completely wrong? Well OK, one just doesn't work (bad assumption on
my part) and one works with limited reliability and is semantically
incorrect.
So they are both completely wrong. The first one wasn't even tested by you,
and the second one "works" just to the extent that it misleads the author.
How much more wrong _could_ you be?
But it would seem there's no right way to do what the OP
wants,
How did you miss my <wbrpart?
and I was trying to be more helpful than to just say "don't do it."
The most helpful thing is "don't do it". The second-level advice is how to
do it in a way that works almost always and does no harm when it doesn't,
except that it upsets people who swear by "HTML standards" (even if they
don't actually know _the_ HTML standard, ISO HTML, the ridiculous exercise
in futility).

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 18 '07 #16

P: n/a
Sat, 17 Feb 2007 10:44:00 +0200 from Jukka K. Korpela
<jk******@cs.tut.fi>:
In article <MP************************@news.individual.net> ,
Stan Brown <th************@fastmail.fmwrote:
[on *not* putting URLs into content, only href attributes]
The problem with that is when the user prints a document, the printed
copy has no indication what the URL is. (Lynx offers an option to do
it as a set of endnotes, but I don't know of another browser that
does.) Sometimes that doesn't matter, sometimes it does.

Writing the address explicitly after a link and suppressing it on all media
except print works relatively well as such, but it's awkward to do and to
maintain. In that approach, however, you can use <wbrat will. The approach
might be feasible for some _selected_ important links.
Hmm -- I run all my content through a customized macro-processing AWK
script, so this wouldn't be too hard to do, via a macro for selected
links.
Most importantly, I'd say, the URL of the page itself gives access
to documents linked from it. ... Even if it is slightly complex, it
is more convenient to use it to access the linked documents than to
type the URLs of the linked documents (which might very long and
very messy "database URLs" for example).
Good point!

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Feb 18 '07 #17

P: n/a
Scripsit Stan Brown:
>Writing the address explicitly after a link and suppressing it on
all media except print works relatively well as such, but it's
awkward to do and to maintain. In that approach, however, you can
use <wbrat will. The approach might be feasible for some
_selected_ important links.

Hmm -- I run all my content through a customized macro-processing AWK
script, so this wouldn't be too hard to do, via a macro for selected
links.
I wrote that it's AWKward, didn't I? :-)

Seriously, it's certainly doable using suitable preprocessing techniques,
but that means it's probably too difficult to most authors.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Feb 18 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.