On Fri, 2002-09-20 at 17:25, Will Newton wrote: > Writing in block paragraphs is: > a) Good practice in English > b) A lot easier than learning and using HTML correctly. Excellent point. Made in list format, not block :P And a good job it didn't include any one of '> ', ': ', '|', 'will:', or any of the other 'quote' mechanisms, because my e-mail client could have reflowed it in anyway. a) I've often seen points start like this, continuing onto the next line b) but having the second point broken in :( > > - 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. I mean: adding lists, right-formatting, perfect-justification, indenting, quoting, bullet points, etc. Anything basic rich text controls enable you to do - bold, italic, etc. > 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. Not at all. In HTML, "<p>This broken\n paragraph</p>" is exactly equivilent to "<p>This\n broken paragraph</p>". In text, the two are different. Text wrapping and quoting breaks layout, and makes e-mails hard to read. > Cutting and pasting is OK if you have rectangles a-la emacs. :) It's what > tabs were invented for. Cut out every cell individually - mmmm, yummy :) Do you mind if I send you some text spreadsheets I need in table cells? > > 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. You've just missed the point. Sure, for true collaboration you might want authorship and versioning, but people having to put up with text e-mail clients will quite happily use the digital equivilent of highlighting markers to make their changes. Works on paper, works in HTML, utterly impossible in text. > Well why use HTML if <p> and <br> will do it? ASCII 10 will do both their > jobs just fine. Because <p> and <br> are structure, \r and \n are content. See above broken paragraph example. You can wrap HTML exactly how you please and it still works, wonderful. > 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. Quite possibly. But the point is, we can do better :) > 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. You call it unnecessary, yet people still use it and go even further - emailing word documents around, all sorts. All because the basic e-mail client is not capable enough for the range of expression people need. > Cookies? In email? I think I need a lie down. Frames? Aaargh! :) Again, you've missed the point. You called the HTML parser complex - I pointed out a fully fleged browser fits on a single density floppy. A parsing library for a text-based e-mail client need only be a few Kb. > I would have far less problems with HTML if everyone used XHTML Agreed. The majority of the problem is due to poor implementations. > > That's an argument against proprietary monopolies, not a technical > > argument against a format. > > This particular format is IMO beyond redemption though. :) Bah. Anyone can be saved :) > > 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. The number of people who want to read the source are a complete minority however. People interested in how precisely efficient the markup is are dull bores, penny-wise pound-foolish. For the majority of users, this isn't an issue. > HTML is a big ugly beast to parse without introducing some form of insecurity > such as a buffer overflow. Cadangers. You can parse it with an event-firing state machine. Javascript problems, yes, privacy problems yes, these are all implementation issues. To say HTML causes buffer overflows is nonsense. Of course, we're not arguing about Javascript though - the DOM is the business of the implementation. Cheers, Alex 'Flamewar' Hudson.
Attachment:
signature.asc
Description: This is a digitally signed message part