4/8 John Ashcroft, Work Safe:
http://www.wonkette.com/images/work%20safe.jpg
\_ Depends on what resolution you view it at.
\_ NWS version: http://www.pmbrowser.info/hublog/images/gashcroft.jpg
\_ what's up with putting urls/img in < > lately?
\_ There's some RFC that says that URIs are supposed to be
enclosed in angle brackets in plaintext media. It's not a
new development; never seen email addresses in angle brackets
back in the days of yore?
\_ Days of yore meant using !s instead of @s.
\_ The suggestion, if that's what it says, is misguided.
\_ why? it lets you put URLs into sentences without having
to worry about the punctuation screwing them up. -tom
\_ Please provide an example of a URL in a sentence
where punctuation screws things up.
\_ "Go to link:google.com/."
"The requested URL /. was not found on this server."
\_ If the terminating period is a representative
example, then I prefer the non < > URLs.
I guess you could say that's just my opinion.
\_ You've also got quotes, commas, slashes,
apostrophes, parentheses and others. I
do think the astute reader can do just
fine without brackets.
\_ I would go as far to say that only the
class of "moronic" users would have
trouble with non-bracketed URLs, and
actually bracketed URLs might give them
a similar level of problems. The
class of "moronic" users should
eventually learn not to copy the
terminating period.
\_ How about URLs containing spaces?
\_ Use %20. (You don't see URLs
with spaces for this reason)
\_ Sometimes people just click on the
link in their email app without first
copying. So it's up to the email app
to include or exclude the terminating
period.
\_ (1) We are talking about the motd,
I believe
(2) E-mails apps I've seen ignore
the period, comma, semi-colon
\_ period is a valid character in
a URL; brackets are not. What
reason is there to *not* use
brackets? -tom
\_ IMO, they're superfluous.
\_ how can it be
superfluous to separate
intended URL characters
from valid characters
which are not intended to
be part of the URL? You
think email and terminal
programs should just
guess which characters
are part of the URL?
Why not tell them? -tom
E-mail programs I've seen don't have problems _/
ignoring trailing punctuation in the URL.
\_ you haven't seen them all--I've seen errors of\
various kinds, in various programs. And it's
*incorrect* to ignore trailing punctuation; URLs
with trailing punctuation are valid. -tom
\_ In this case, I side with the "incorrect"
approach being the better one. It happens
all the time with English usage; what's incorrect
becomes accepted. Most text-based e-mail
newsletters I've received for several years
don't use < > brackets, which lends support
to the "widespread practice" argument.
In any case, I also found
out that Outlook supports < > when the URL
has spaces (even though there's an RFC which
says space chracters should be encoded as %20
in the URL), so that's neat.
\_ This is the motd. We are not subject to RFCs. We can
barely get people to indent.
Aiee! Chaos! _/|\_ nowhere did I ever say I was trying to get other people
| on the motd to use angle brackets. I'm only justifying
Whee! my own usage.
\ this is a great thread! / \
/-----------------------/ motd became -> \ ^ ^ |
\--------| self-aware and /\ \__/ /
| tries to mimic \ \____/
| that scene in \
/--------------/ "The Abyss" \
| \
\-------------------> Follow the magic dancing penis pigeon! |
\_____/ |
http://csua.com/feed/