It has been advocated many times that tables shouldn’t be use in HTML for layout purposes. I have been using CSS to construct my pages since it was introduced to me in a web design contest in las vegas.

To prevent bad CSS implementations to read the stylesheet, just call it through < style type="text/css" > @import url('your-stylesheet-url‘); < /style >

check out this good development link.

An XHTML document is validated against a Document Type Definition.

 Visit this page to validate a URI
An XHTML document is validated against a Document Type Definition (DTD). Before an XHTML file can be properly validated, a correct DTD must be added as the first line of the file.

The Strict DTD includes elements and attributes that have not been deprecated or do not appear in framesets:

!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"

The Transitional DTD includes everything in the strict DTD plus deprecated elements and attributes:

!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"

The Frameset DTD includes everything in the transitional DTD plus frames as well:

!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"

The 3 Document Type Definitions

• DTD specifies the syntax of a web page in SGML.
• DTD is used by SGML applications, such as HTML, to specify rules that apply to the markup of documents of a particular type, including a set of element and entity declarations.
• XHTML is specified in an SGML document type definition or ‘DTD’.
• An XHTML DTD describes in precise, computer-readable language, the allowed syntax and grammar of XHTML markup.

There are currently 3 XHTML document types:

• STRICT
• TRANSITIONAL
• FRAMESET

> !DOCTYPE TVSCHEDULE [

> !ELEMENT TVSCHEDULE (CHANNEL+)<
> !ELEMENT CHANNEL (BANNER,DAY+)<
> !ELEMENT BANNER (#PCDATA)<
> !ELEMENT DAY (DATE,(HOLIDAY|PROGRAMSLOT+)+)<
> !ELEMENT HOLIDAY (#PCDATA)><
> !ELEMENT DATE (#PCDATA)<
> !ELEMENT PROGRAMSLOT (TIME,TITLE,DESCRIPTION?)<
> !ELEMENT TIME (#PCDATA)<
> !ELEMENT TITLE (#PCDATA)<
> !ELEMENT DESCRIPTION (#PCDATA)<
> !ATTLIST TVSCHEDULE NAME CDATA #REQUIRED<
> !ATTLIST CHANNEL CHAN CDATA #REQUIRED<
> !ATTLIST PROGRAMSLOT VTR CDATA #IMPLIED<
> !ATTLIST TITLE RATING CDATA #IMPLIED<
> !ATTLIST TITLE LANGUAGE CDATA #IMPLIED <

> !ENTITY COPYRIGHT "Copyright 1998 Vervet Logic Press" <
]<

so you can send emails great…

so you have a loyal list of emails to blast your message to GREAT !

so how do you cater to everyone and make a compelling argument for your product and/or service? You make your emails rich text MHTML formatted.
This empowers your message with aggregate HTML objects…
essentially think as this as embedding into a email message “file”.
Multipurpose Internet Mail Extension HTML (MHTML) format .MHT & .MHTML

Here is real good documentation on [ email formatting standards ]

Sending of HTML-formatted messages is based on the assumption that an HTML documents, together with in-line objects like images, applets and frames, can be copied into a MIME message. Such copying may require rewriting of URIs containing references between the different message parts. The MHTML standard [MHTML] has been carefully prepared to allow existing web pages to be copied without such rewriting, through the use of the Content-Location MIME content heading field.

• NO relative URIs as parameters for objects & applets
• Use only absolute URIs, preferably of the CID type
  these are more easily identifiable
• Understand conformances
  Content-Types :: Text/HTML, Image/GIF, Text/plain
  charset=US-ASCII
  boundary=”YOUR FRIENDLY NAME OF BOUNDARY”
  MIME ::
  multipart /related; /mixed; & /alternative;
• Stack like so /alternative surrounds the /related, /related is one alternative and /mixed as the other.
  
• Do not ever assume that HTML-capable user agents will display the Content-Description header.
• 12pt font size is median target for users reading email for avg. screen resolutions and common eyesight

• content-location ::= "Content-Location:" ( absoluteURI | relativeURI)
  content-base ::= "Content-Base:" absoluteURI

• The URI of an MHTML aggregate is not the same as the URI of its root.
• Every email should include : Sender’s Company, web address
  & physical address or phone number
  & use a individual’s name or Department Name with email
• Employ effective teaser copy within the subject line
• Create a dedicated directory for all your email assets
• keep emails fixed to width of no more than 650 pixels
  
• average preview pane is 300-500 pixels high 1st FOLD
  Make sure you include any important bits of your email in this area. First impressions count. but dont go past 2000 px long.
• I did some research comparing Outlook, Hotmail, and Gmail (interface similar to Yahoo/most web-based email clients provided by ISPs) and how much of a message was visible at 800×600 and 1024×768.What I decided on is a 530 width b/c that is visible in all scenarios. 530px wide for AOLAs for height, you have between 250-370pixels before the fold, so I try and get as much important/compelling info in that space so readers will be interested in scrolling down.
• The average email viewer can see 60 characters in his subject line
•