Re: [Sheflug] HTML mail (was Re: Linux)

[Will Newton <xxxxx [at] xxxxxxxxxxxxxxxxxxxx>]

On Friday 20 Sep 2002 4:50 pm, Alex Hudson wrote:

> Except, you can't do it. By the nature of ascii text, the formatting is
> inextricably linked to the content - change the content, and you change
> the formatting. The machine cannot know whether or not the change makes
> sense unless you write in block paragraphs.
> - Not everyone writes in block paragraphs;

Writing in block paragraphs is:
a) Good practice in English
b) A lot easier than learning and using HTML correctly.

> - occasionally people insert stuff other than text, such as 'ascii art'
> in an attempt to work around the limitations of ascii.

HTML does not solve this, unless you mean adding image links which is another 
can of worms.

Heck, it's hard enough to even get a mono-spaced font to work in most 
browsers.

> Not client gets it right 100% of the time though. They're all 95% hacks,
> which break down on complex e-mails - precisely those which you need
> the feature most for! Very annoying. I can re-format basic e-mails by
> hand, like this one. Complex ones I can't, too time consuming, that's
> where I need the machine to get it right.

No client will ever please all of the people all of the time, it's often an 
aesthetic judgement. But to call a quoting algorithm a hack in the same 
breath as HTML is perhaps over-stating the case.

> What a hack. Cutting and pasting is miserably broken, so I cannot edit
> that data - it's just there, in stone, forever, unless I muster the
> willpower to spend time to craft it into shape.

Cutting and pasting is OK if you have rectangles a-la emacs. :) It's what 
tabs were invented for.

> Etc. Highlighting, track changes. You can't do that with text.

Neither can you do it properly with HTML. You can use colouring like that, 
but what if author A wants to use red for his headings etc. You also do not 
have any versioning, and I would not want to diff HTML. Again a case of HTML 
being shoe-horned into a job it isn't really up to.

> Define 'hard'. You can get away with one that understands '<p>' and
> '<br>' alone (I know someone who wrote one for the BBC micro doing
> just that!), and both tags will do roughly the same thing ;)

Well why use HTML if <p> and <br> will do it? ASCII 10 will do both their 
jobs just fine.

> Straw man. You can't do that with text e-mail either. And while we're on
> the subject of links, it's bloody text that has inflicted us with the
> "Wrath[1] of[2] Footnotes[3]". We have <a> tags for this, they are very
> standard and easy to implement.

Links are a good thing, but I think you will find it was inflicted by the 
invention of the printing press more than anything else. But my point 
remains, HTML is not a great leap for HTML. It adds a big heap of cruft that 
is perhaps not necessary, and not much that would be really useful.

> It needs a parser, granted. How complicated it needs to be depends on
> the client. A text client need not interpret much more than line
> breaks and links, and you can get a full text-based web browser,
> including cookies, mouse support, frames, tables, under 700k. If
> you're using Emacs, it's all built in anyway :D

Cookies? In email? I think I need a lie down. Frames? Aaargh! :)
I would have far less problems with HTML if everyone used XHTML and it was 
deemed a valid response to just spit out an error on mal-formed HTML, but 
until it is HTML parsers will remain gross hairballs.

> > people are coralled into using, so no client can ever really claim to
> > "read HTML email" apart from Outlook which dictates to everyone else.
>
> That's an argument against proprietary monopolies, not a technical
> argument against a format.

This particular format is IMO beyond redemption though. :)

> Granted, but then, that is the nature of structured documents.

I would contend that some are easier than others. e.g. I can quite easily 
read a lot of LaTeX, but troff rots the brain.

> Easy allegations, not ones that can be founded in reality though. HTML
> itself is not bloated, massive text formatting of an email might be.
> HTML is not insecure, although a particular implementation might be.

HTML is a big ugly beast to parse without introducing some form of insecurity 
such as a buffer overflow. And when the forces of darkness (Outlook) start 
putting Javascript in emails you may as well start offering free telnet 
accounts.

___________________________________________________________________

Sheffield Linux User's Group -
http://www.sheflug.co.uk/mailfaq.html

  GNU the choice of a complete generation.