Slashdot Mirror

You're just being silly, honestly.

no, you're just being stupid and short-sighted.

the point of email is communication. - communication with all readers, not just those who happen to be using the same software as you.

HTML in email is fucked up and stupid for the same reason that MS Word documents in email are fucked up and stupid, or why writing your email in LaTeX would also be fucked up and stupid.

plain text works with all mail clients. HTML doesn't. XML doesn't. LaTeX doesn't.

and when morons of your ilk switch to BLINGML 2015 and you're an old loser stuck on boring old XML or ancient HTML you might begin to understand why dropping backwards compatibility for the sake of following fads is cretinous.

And HTML isn't? It's practically XML.

HTML is NOT XML. it looks superficially similar but it's not even close to XML.

you can pipe html or xml easily enough. you can't can't do anything useful with that, though, unless you write an xml or html parser (or use an existing one). which magnifies a simple Q&D one-liner into a small-scale development project.

So I'll use a <pre> tag, for fuck's sake. Every email reader I've ever seen supports it.

you obviously haven't seen many, then. mutt doesn't. elm doesn't. pine doesn't. none of the non-html MUAs support it.

and if you're goint to argue that they'll just render the html tags as plain text in the body - well, they might. if your sending email client is broken and doesn't use the correct mime-type for the body attachment, they will. and even then <em>html</em> tags <blink>scattered>/blink> throughout the <i>text</i> make the text <blink>unreadable</blink>

3. <80 columns (72-78 is typical) is the standard for email.

Again, according to whom?

RFCs 822, 2822, and 5322 to start with.

you know, those unimportant little documents that define the standard for Internet Message Format.

here's a site that summarises and discusses them:

http://mailformat.dan.info/body/linelength.html

I wrote an email parser about five years ago, and I can tell you that there is a good compromise to the problem you describe in the email standards implemented by virtually all mail clients (MUAs).

The header "format=flowed" lets you send text/plain messages that look great whether you are reading it with telnet or pine or with Thunderbird or any other modern MUA. The main rfc for email, RFC 2822, explains that the sending MUA should, but is not required to, break up paragraphs into lines of less than 78 characters terminated by a carriage return/line feed. If you specify the "format=flowed" header described in RFC 2646, you allow the receiving client to rewrap the email according to the receiving user's preference. Typically modern MUAs will rewrap format-flowed plaintext email to the window size.

The specification states that lines ending with a space and then a CLRF are to be treated as part of a single paragraph that can be rewrapped. Hard breaks are then done by terminating the line with a simple CLRF with no preceding space.

Most modern MUAs that I have dealt with can (and typically by default) send format-flowed email that has the standard line breaks every 78 characters for the benefit of clients that cannot rewrap, and contain contextual clues for newer mail clients to seamlessly reformat the message body. For example, Apple's Mail.app by default sends multi-part MIME messages, one part containing the rich text email and the other part containing format=flowed text/plain. No matter what email client the recipient is using, at least one of those options will look acceptable.

You can find a pretty good write-up of this at Dan's Mail Format Site.

I have legitimate sites in .info domains.

I was wrong, but still provided an example elsewhere in this thread that I think should be valid that is also ambigious. I went to http://webtips.dan.info/nesting.html to get straightened out. But still, with optional closing tags on some elements, things still get impractical.

Pardon me for going completely off-topic, but this is a pet peeve of mine.

Why do people continually insist on trying to control the viewing experience of the visitor to their website? A lot of these bother me, but the most egredious one is people who hard code pixel widths in their table tags. http://webtips.dan.info/tables.html (that's just one page, there are many others) It's annoying. Why should I be punished for having a lot of screen real estate? If you must use a table, and until support for CSS3 tables are supported widely we'll be using them a lot, ignore the width setting, or set it to 100%. Only if your design is multi-column should you use defined widths for the tables. All added together they should equal 100%. Heck you shouldn't be using tables anyway. Use CSS instead. http://www.meyerweb.com/ is a good site for learning CSS. But for those lazy web programmers that insist on using tables to control the width of the content rendering,

javascript:(function (){t=document.getElementsByTagName(%22table%22);fo r(x=0;t[x];x++){if(t[x].width.indexOf(%22%%22)==-1 )t[x].removeAttribute(%22width%22);}t=document.get ElementsByTagName(%22td%22);for(x=0;t[x];x++){if(t [x].width.indexOf(%22%%22)==-1)t[x].removeAttribut e(%22width%22);}t=document.getElementsByTagName(%2 2th%22);for(x=0;t[x];x++){if(t[x].width.indexOf(%2 2%%22)==-1)t[x].removeAttribute(%22width%22);}t=do cument.getElementsByTagName(%22col%22);for(x=0;t[x ];x++){if(t[x].width.indexOf(%22%%22)==-1)t[x].rem oveAttribute(%22width%22);}})();

will set the table widths to 100%. This javascript function doesn't work to well on multi table design or CSS width controlling madness, but every little bit helps. Remove the /. embedded spaces in the javascript function and paste it into a new Firefox bookmark. Then click on that bookmark whenever a site is controlling the viewing experience oh so helpfully. /sarcasm (last part).

-FlynnMP3

All of the seven new TLDs are living, though none have really taken off much.

I'm using some myself:
http://www.dan.info/
http://dan.tobias.name/

The linked article seems to be having some character set conversion problems... its opening paragraph says "An alleged high-tech roulette scam that saw three people walk out of a London casino with y1.3 million recently sounds too implausible even for a movie plot", with an accented "y" where there apparently should have been a British pound sign.

The site developers aren't very well-versed on character encoding standards, obviously, as also shown from their use of the bogus numeric reference &#149; (characters from 128 through 159 are actually control characters in the Unicode set, regardless of what Microsoft thinks).

More info:
http://webtips.dan.info/char.html
http://mailformat.dan.info/body/charsets.html

The linked article seems to be having some character set conversion problems... its opening paragraph says "An alleged high-tech roulette scam that saw three people walk out of a London casino with y1.3 million recently sounds too implausible even for a movie plot", with an accented "y" where there apparently should have been a British pound sign.

The site developers aren't very well-versed on character encoding standards, obviously, as also shown from their use of the bogus numeric reference &#149; (characters from 128 through 159 are actually control characters in the Unicode set, regardless of what Microsoft thinks).

More info:
http://webtips.dan.info/char.html
http://mailformat.dan.info/body/charsets.html

Extracts:

A new top-level domain doesn't really exist on the Internet until it is added to the root servers, so that any system anywhere on the net that is seeking that domain can find out from the root where the specific DNS servers for that domain lie.....

the operators of the root servers have a great deal of political power over the domain name system. Presently, these servers are operated by Verisign, but their policies are determined by ICANN, the organization set up to administer Internet naming and numbering schemes. Since ICANN has attracted a great deal of criticism (much of it highly deserved) for its biases towards large impersonal bureaucracies and against individual Internet users, various people have come up with the idea of "fighting back" against ICANN by setting up alternate roots.....

Setting up an alternate root turns out to be a very simple matter. The Internet has always been sort of a "do-it-yourself" thing, not centrally controlled or administered like a proprietary online service.....

a naming or addressing system only makes sense if everybody uses it consistently. If every telephone company had a different idea of how the country and area codes ought to be allocated, so that if your long distance service was with AT&T, "1-212" would reach New York City, but with Sprint the same prefix would reach Los Angeles, then telephone numbers would be in a state of chaos....

Moderate this comment
Negative: Offtopic Flamebait Troll Redundant
Positive: Insightful Interesting Informative Funny

As I've been saying for a long time, these scams would be less effective for the scammers, and legitimate sites would be more resistant to them, if companies would stick to using logical subdomains of their main domain for everything they do, instead of using silly marketing-gimmick domains all the time (ebaymotors.com, yahoogroups.com, ad nauseam). They could then tell the public "Don't trust any site that doesn't have a domain ending in .ebay.com; all official Ebay sites use that address."