HTML.co.uk

Whether you hate or love HTML email, in your inbox today chances are good that one of your messages was written in it. There is lot of reasons to avoid HTML email and writing HTML emails.

Testing email is almost impossible.

Some people still read the mails in the text mode even if the clients support HTML:

You may consider these people are extremely techno phobic, but many a people do not prefer HTML and they tend to read emails in the text mode.

Emails of HTML are flagged as spam:
Amount of HTML is used by spam assassins and other spam brokers in Email messages as an indication to know whether the email is a spam or not. HTML is used because spammers have discovered that HTML emails are quite quicker than the average emails and it is much more efficient in generating click than a simple text.

Styled emails get better results:

Emails styled with fancy text and images can be pleasing to read than a plain text. So the people who read your emails which are styled will respond or take quicker action seeing your message.

Emails of HTML can be a security risk:
Emails of HTML enable hateful senders to insert Trojans and other hateful entities into an email messages. Some clients will mechanically open images and attachments inserted in HTML emails, by doing so your system will be infected without taking ay action other than downloading the Email.

Emails of HTML are longer to download:

WebPages are slightly different than Emails, in that most people won’t wait for one email message to download. For your recipients it can be frustrating if one of the messages is so large that it stops rest of their Emails.

Writing HTML Email is fun:

Email of HTML is fun to write just like writing WebPages. Time can be spend time by designing how your messages will come crosswise.

HTML email can generate privacy issues:

If you read an HTML email, you have viewed the images and the fact the Email was opened and is recorded.

Many of the email clients don’t reliably support CSS:

This is mostly a matter for the web designers who are learning to write standard HTML for their WebPages. When they put same design in their WebPages their clients will choke. CSS is not a well supported with email clients except for basic styles like italics, colours and bold.

Many clients of email default to HTML email:

Clients like AOL and outlook express use HTML email as their default, to provide their users with embedded images and text formatting. It is very much complicated to turn off HTML as their default.

Some individuals really hate HTML:

There are some people, who really hate using HTML and they will delete those messages which are unread.

Some individuals really love HTML:

Some people love t use HTML because they like the plain text and in this there will be no images it will be lot easier for the user to read it.

Although Java scripts are known to be an exceptional and proprietary element but still it can cause a major problem for the HTML email. The major reasons for this is that there are a wide variety of email clients, updates, browsers, service packs and security settings thereby making it difficult predicting the behavior of the java script against any given email client. It’s quite surprising that Java scripts are actually capable of disabling any kind of active scripting that would be contained in the email document. Therefore it is always advisable to always test the java script that you would be interested in including in your email.

All the email clients are actually not capable of handling the java scripts. And in fact, most of the web based systems are known to disable the script by default just for preventing any kind of malicious code from getting executed in the system. Although you can make use of Java based navigation forms but that is also possible only with the email clients which are not web based. This is because most of the java script navigation forms do not work with maximum number of web based email clients. It is a very important point to note that almost all the web based email browsers are FORMS themselves and always make use of Java script in some way or the other. Therefore, it is very important that the script is always safe so that it doesn’t really interfere with any of their products.

These days Flash has been greatly used in the emails for actually impressing the clients, news letter subscribers or for that matter the prospects. As a matter of fact email HTML browsers are just no in no way equal to their web browsers. The complexity is further increased because of the settings, versions, preferences, third party applications and the security settings. Always remember to avoid the use of flash as far as possible in your HTML email unless and until you are absolutely sure that the email client that is being used by your recipient client is actually capable of handling the Flash content. Further, you should only think of sending the Flash content only to those clients who have actually requested for it or with whom you have certain marketing relationship.

And in case you have no other option but to send the Flash content via email then there are certain important considerations to be made in order to avoid any kind of problems. Firstly one should never try controlling the Flash content by making use of active scripting. Secondly, it is very important that one should try and consider the option of sending links. It has been most commonly seen that the majority of the web based clients are actually capable of stripping the flash content. Therefore it is always better to attach or a send a link instead of actually including the content in the email itself. This way you can have the option of playing around with a lot of limitations that are imposed b y the browsers and the email clients. And last but not the least always ensure that your files should be controlled by a trigger, an onClick or any other event but should not immediately start playing. The main reason for this is to give the user or the recipient time to open to the flash content whenever ready instead of a surprise and thereby causing unnecessary problems.

Don’t you think so that it would be really great to have a hypertext system on the PDAs? If you were actually able to enter a meeting in your calendar, and linking that to the address of the meeting in your address book, additionally linking it to your meeting notes, and further with the email that you had received about the meeting. As a matter of fact the display on the PDAs is way too small to actually enable the switching between the windows therefore it is not really easy to swap between the windows and view the different events like the notes, address or the email. In fact, you have to first open the window and find the event in your calendar and then find the address in your address book and then further find the notes in the notebook and then finally locating the email in your email program.

Therefore, it is very important to have PDA’s that have enabled hypertext. As we know that PDA’s like Nino and Palm are becoming popular by day and is infact becoming an important day to day tool. As a matter of fact you would find a lot of web browsers that come especially for your PDAs. Putting the PDAs on the web is one important task and further it is more important to hypertext enable the applications that are used on the PDAs such as calendar, to do list, address book, email and notes.

All the different activities that are performed by you are all interconnected. Addresses are connected to the events, notes further to the To Do list which is further connected to the entries in your calendar and emails are connected to the persons, their birthdays, and anniversaries and so on. But once these applications are put on to the digital form the device is just not able to read them and therefore it becomes literally impossible to travel between the applications and thereby creating the links and the shortcuts that actually exist in the real world.

The main issue that arises is that the PDAs first have very small memory and also have very limited screen space. Usually when the PDAs are synchronized with the information on the desktops and what is important is to save these links on the PDAs. And another important issue to be considered is to have the browsers that are compatible with all the different PDAs that are available in the market.

If you are using palm for your implementations, it has the inbuilt features like the Phone Lookup Function wherein you can look up for the person in the address book from almost all the applications except for the Email. Although this is an amazing feature but still has certain limitations to it. You are only able to perform the function that is just listed which means just retrieving the information about the person. But just in case it if there are any kind of changes in the personal information about the person, it is not further updated in all the applications if done in one.

Another approach for integrating the core PDA applications would be creating true web based applications that have the applications and also be able to synchronize with the PDAs. The main benefit with this approach would be that it would work or be compatible with any device that supports the web browsers.

I think most of us are aware about the most common problem of designing HTML email using CSS. Almost all web designers who have tried recreating a sophisticated and descent HTML email design using the cascading style sheets have always had a bitter taste of disappointment, either in the form of a pronouncement by the email administrator that they don’t support CSS, or inexplicable mangling by email clients.

I am neither contradicting my earlier statement nor am I wrong when I say that your HTML email can still be deployed using CSS. Though all the attributes will not be invited to the party but still some will surely work flawlessly. Email as we all know is the best and the most commonly used method of communicating. The better displayed and explained your message the more people are likely to read and get benefitted from it. Styled emails with the use of different colors and highlighting make the message readable and understandable with much ease.

Whenever an email that is designed using an external style sheet is blasted to various clients version 6.0 of AOL will invariably bounce back or reject the email. If at all, the code of the mail is analyzed the results will definitely be more than surprising. The main reason for the entire problem of bouncing back or rejecting or not supporting is that the HTML code is not what we had sent, but is definitely the most unexpected i.e. a mixed breed code and proprietary tags. The reason for this unexpected behavior is that each email has its own way of rendering the code, methods of handling CSS and unique bugs and quirks.

Each problem always has a solution following it. When two body tags are displayed on the HTML email, then the simple solution to the problem is enveloping entire content of the email in a div tag and further applying the intended body attribute to the div. At times it happens that certain clients are not able to render any kind of style what so ever when they receive the mail. They are just able to see the plain text. But if the source code is analyzed it will not show any kind of discrepancy. The main reason for this is that the dots preceding the names of the styles were getting stripped resulting in feature instead of .feature, which is absolutely meaningless. The only solution to this problem is to begin a feature with a letter instead of a dot. This may sound a little weird, but it really works and is compliant as well.

Different people use different style sheets thereby there is a common problem of sender’s cascaded style sheet over ruling the receiver’s style sheet thereby altering the element definitions and pseudo classes. The solution is customizing every definition so as to accommodate links in both the documents. Although there are many such problems relating to various attributes, but these are the most common ones.