Matt Connolly wrote:
That's a great spec for constructing multi part messages, but it doesn't really go in to HTML at all.
see http://www.w3.org/TR/html4/ ;-)
Is there a standard, for example, for using content-inline-disposition links to use an attached image in the html document?
see 9.3 Example with relative URIs to embedded GIF pictures http://www.faqs.org/rfcs/rfc2557.html But there's a whole swarm of related RFCs on this subject Each tends to be fairly focussed on a particular subtopic - you have to do a lot of cross referencing to get the full picture
Does HTML email conform to HTML3 HTML4 XHTML1.0, etc?
Surely that depends on the doctype - it's up to the author. Mail clients don't provide very good support of the standards - but the standards do exist.
Anyway, I agree that the data should remain structured for as long possible. Perhaps drupal can detect if there's a string (or array of strings) then it's an old school email, or if it's a keyed array of attributes, then construct the multipart message, using drupal render to a default theme or theme function (perhaps specified by a '#theme' key).
that sounds good to me. To render the email will require different CSS Mail client rendering is back in the dark ages - <font> tags and tables for layout are far more common in this area (Bad - yuk - I know - but Drupal should not prevent it). To mitigate against the accessibility issues: sending multipart/alternative AND allowing the user the option of plain text only are both important. mailing to a $user could check the receiving preference - and strip out the formatting if required. -- Sean Burlington www.practicalweb.co.uk