Formatted Email Composition OPERA

Formatted Email Composition
Introduction

Opera does not support the composition of HTML email. Many Opera users request this feature and Opera has repeatedly stated that they will not support it.

This is a shame, as support for basic formatting would be very useful. One only has to pick up a newspaper or magazine (or surf the web!) to see the benefits of formatting and styling. Even my pencilled Post-It notes, for those most transient of messages, benefit from bold (over-writing), underlining and the odd change of colour.
My View

You can probably infer from the introduction that I support the composition of emails that include styling and formatting. It is then somewhat contradictory that I do not support the concept of HTML email composition, rather I support HTML compatible email composition.

Note also that I am referring to the composition of email. I do not consider newsgroup postings emails - they should always be plain text.
HTML

HTML is a very large and complicated markup language. It is also obviously very popular. Of all the systems proposed for use by email clients to display formatted and styled emails, HTML is almost certainly the most popularly-implemented (note that I don't have any sort of statistics to back that up).

Clearly, any email composition tool intended for creating formatted and styled emails would be stupid not to be compatible with an HTML-based display system.

HTML is too big to be considered in its entirety to be used in emails, however, all that is really needed is to use a much smaller subset that is still compatible.
HTML Compatible?

HTML has lots of features. Not all of them are suitable for emails; only a subset is useful for emails. When considering which tags would be suitable, I considered the user interface for the Wordpad program bundled with all Windows 95 (and later) systems.

Note, of course, that all this is only my opinion. Note also that when looking at my example tags below, if something isn't shown, then you can assume I don't think it should be part of an HTML email.
Font selection - Fonts are not portable between different systems. While "Arial" exists on Windows systems, it's "Helvetica" on Macintoshes and who knows what on other systems. The best solution is to do what CSS does - use generic font families: "serif", "sans-serif", "monospace", "cursive", and "fantasy".
Font size - People expect to specify font size in points. The 1..7 font sizes of HTML aren't flexible enough. CSS does provide the required flexibility, so it's CSS for the font selection.
Bold, Italic, Underline
Colour
Left/centre/right/full justification
Lists

The tags to use must be compatible with existing HTML usage. For each tag listed below, I've also included the complete set of attributes that should be supported (the class attribute is not shown, but should be supported).

, ,

,
,
1. 
   
   There are also a couple of other tags for some basic functionality:
   
   - Note no height/width attributes; the image will always be attached to the email and therefore stored locally for quick reading of its size
   

   - This is for handling quoted messages
   
   It may not be immediately obvious what's missing (i.e. not supported by my proposed set of tags): scripts, tables and embedded objects are probably the standout "missing" features.
   
   Scripts are bad for obvious reasons. Tables are bad due to the complexity they introduce to the composition system. Embedded objects are bad due to the object-dependent requirements setting up their parameters, etc.
   
   Also missing is the entire section - it's not needed. Neither are the and tags - they're implied by the content type.
   Deprecated Tags?
   
   Yes, tags like are deprecated (not recommended for use). Instead, style sheets are recommended for use. However, this advice applies to web pages, not emails. Emails are transient, short-lived messages. They generally aren't edited or updated. What's good for web pages is not necessarily good for emails.
   CSS
   
   CSS should be supported to allow the creation of "template" designs. However, it does add to the size of the emails, and therefore should be in addition to the more compact HTML formatting tags.
   
   For complexity reasons, CSS would not be editable - only pre-built template designs should be able to be selected.
   A Complex Composer?
   
   One of the objections to Opera incorporating formatted email composition is the assumption that such a composer would be big and complicated. I consider this to be an invalid assumption.
   
   The most complicated part of a composer would be the renderer. Opera already has a renderer - the Opera web browser itself! Therefore, the renderer adds zero to the size of Opera.
   
   The next most complicated part of a composer is taking user input and turning it into an internal document representation. One of the primary design goals of Opera7 was to support DHTML. This is where a document is dynamically modified and the changes updated on the screen as they occur. That sounds to me an awful lot like just the thing needed to support an editor - and it's already there. All email (even plain text) is already internally converted by Opera to XML. Size added to Opera: zero.
   
   What an Opera composer would need to do is maintain a cursor position, and control what tags go where. Sure, there's some work involved, but nowhere near as much as some people make out. Most of it has already been done and is already in Opera.
   
   Here is a page that describes a DHTML system developed by IBM.
   
   This board has a WYSIWYG editor, however it isn't cross-platform and doesn't work with Opera.
   People Want Formatted Email
   
   This is not debatable - it is a fact. Whether or not they should have it is debatable - hence this page!
   
   If someone wants something enough, they will get it. People who really want formatted emails will discard Opera and switch to something that does have it - like Microsoft Word (or Outlook).
   
   I know that if Opera were to implement a formatted email composer they would do a good job that would minimize the impact it had on email bulk. Given a choice between that and people potentially using Word as their emailer, I know what I would prefer!
   
   I think the web is a much better place with Opera around. We shouldn't be giving people excuses to use something else.
   Size of Messages
   
   Some people object to HTML email because it more than doubles the size of their emails. This is true, and there is no escaping that problem while remaining backward compatible with email clients that are only capable of displaying plain-text emails. It would be true for any method that provides formatted emails. The size increase is for backward compatibility, not because it's HTML.
   
   So, some people object to it because they don't like bloated emails filling their mail box. The question they should be asking is "What impact will Opera providing such a facility have on my mailbox?" Realistically, the answer has to be "Next to nothing." or even "It may make it smaller!"
   
   It will not affect the amount of HTML spam that is received. Spammers are mostly using Outlook Express, or Outlook or similar.
   
   However, consider people who email you. Some of them will not be using Opera because it does not support formatted emails. They will be using some other email client that almost certainly is creating oversized and blown-out emails. If those people could be convinced to switch to Opera because M2 supported formatted emails, your total mail traffic may actually decrease.
   VALID»
   
   Last updated: 2005-07-12. Copyright © 1999-2007.
   Entire site : This page and sub-pages : This page only
   
   
   Top of Page : Site Map : Help