I haven't looked at drupal 7 yet, so I'm throwing this out there for discussion. The D6 mail api seems like it's pretty much designed for plain text emails, however, a module's implementation of hook_mail can clearly set the headers of the mail to "Content-Type: text/html; charset=utf-8" and send rich text. For example, I'm looking at using "forward" module for the "email this page" link on a node, and the "simplenews" module, which uses "mimemail" to send rich emails, including attachments. Both "forward" and "mimemail" modules create a html header. The problem occurs when a module implements "drupal_mail_wrapper()" to build a html header when hook_mail has already done that - you can easily end up with bodies like: <!doctype... <-- from drupal_mail_wrapper() <html> <head>...</head> <body><div.... <!doctype. <-- from hook_mail() <html> <head> ... etc. Because there are two opportunities to create the html "head" for the message: in hook_mail and drupal_mail_wrapper. I'm throwing this out there for discussion, I think that the hook_mail should construct the message in a similar fashion to the Form API, specifying a theme for rendering the body part of the message (ie what goes in the <body> tag) and anything special that needs to go in the head as attributes. That way the message can be constructed only once. Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages. Thoughts? Matt
+1 I strongly would love to have D7 send HTML e-mails. At least 20 modules will benefit from this step. Omar Matt Connolly wrote:
I haven't looked at drupal 7 yet, so I'm throwing this out there for discussion.
The D6 mail api seems like it's pretty much designed for plain text emails, however, a module's implementation of hook_mail can clearly set the headers of the mail to "Content-Type: text/html; charset=utf-8" and send rich text.
For example, I'm looking at using "forward" module for the "email this page" link on a node, and the "simplenews" module, which uses "mimemail" to send rich emails, including attachments. Both "forward" and "mimemail" modules create a html header.
The problem occurs when a module implements "drupal_mail_wrapper()" to build a html header when hook_mail has already done that - you can easily end up with bodies like:
<!doctype... <-- from drupal_mail_wrapper() <html> <head>...</head> <body><div.... <!doctype. <-- from hook_mail() <html> <head> ... etc.
Because there are two opportunities to create the html "head" for the message: in hook_mail and drupal_mail_wrapper.
I'm throwing this out there for discussion, I think that the hook_mail should construct the message in a similar fashion to the Form API, specifying a theme for rendering the body part of the message (ie what goes in the <body> tag) and anything special that needs to go in the head as attributes.
That way the message can be constructed only once.
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
I tried it but nothing... Where on the database can I delete the module references? Will it work? Thank's -----Mensaje original----- De: development-bounces@drupal.org [mailto:development-bounces@drupal.org] En nombre de Omar Abdel-Wahab Enviado el: dimecres, 16 / juliol / 2008 11:23 Para: development@drupal.org Asunto: Re: [development] HTML emails +1 I strongly would love to have D7 send HTML e-mails. At least 20 modules will benefit from this step. Omar Matt Connolly wrote:
I haven't looked at drupal 7 yet, so I'm throwing this out there for discussion.
The D6 mail api seems like it's pretty much designed for plain text emails, however, a module's implementation of hook_mail can clearly set the headers of the mail to "Content-Type: text/html; charset=utf-8" and send rich text.
For example, I'm looking at using "forward" module for the "email this page" link on a node, and the "simplenews" module, which uses "mimemail" to send rich emails, including attachments. Both "forward" and "mimemail" modules create a html header.
The problem occurs when a module implements "drupal_mail_wrapper()" to build a html header when hook_mail has already done that - you can easily end up with bodies like:
<!doctype... <-- from drupal_mail_wrapper() <html> <head>...</head> <body><div.... <!doctype. <-- from hook_mail() <html> <head> ... etc.
Because there are two opportunities to create the html "head" for the message: in hook_mail and drupal_mail_wrapper.
I'm throwing this out there for discussion, I think that the hook_mail should construct the message in a similar fashion to the Form API, specifying a theme for rendering the body part of the message (ie what goes in the <body> tag) and anything special that needs to go in the head as attributes.
That way the message can be constructed only once.
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
__________ Información de NOD32, revisión 3270 (20080715) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com
Sorry, I'd replyed incorrect mail... -----Mensaje original----- De: development-bounces@drupal.org [mailto:development-bounces@drupal.org] En nombre de marolijo - Pol Maresma Enviado el: dimecres, 16 / juliol / 2008 11:36 Para: development@drupal.org Asunto: Re: [development] HTML emails I tried it but nothing... Where on the database can I delete the module references? Will it work? Thank's -----Mensaje original----- De: development-bounces@drupal.org [mailto:development-bounces@drupal.org] En nombre de Omar Abdel-Wahab Enviado el: dimecres, 16 / juliol / 2008 11:23 Para: development@drupal.org Asunto: Re: [development] HTML emails +1 I strongly would love to have D7 send HTML e-mails. At least 20 modules will benefit from this step. Omar Matt Connolly wrote:
I haven't looked at drupal 7 yet, so I'm throwing this out there for discussion.
The D6 mail api seems like it's pretty much designed for plain text emails, however, a module's implementation of hook_mail can clearly set the headers of the mail to "Content-Type: text/html; charset=utf-8" and send rich text.
For example, I'm looking at using "forward" module for the "email this page" link on a node, and the "simplenews" module, which uses "mimemail" to send rich emails, including attachments. Both "forward" and "mimemail" modules create a html header.
The problem occurs when a module implements "drupal_mail_wrapper()" to build a html header when hook_mail has already done that - you can easily end up with bodies like:
<!doctype... <-- from drupal_mail_wrapper() <html> <head>...</head> <body><div.... <!doctype. <-- from hook_mail() <html> <head> ... etc.
Because there are two opportunities to create the html "head" for the message: in hook_mail and drupal_mail_wrapper.
I'm throwing this out there for discussion, I think that the hook_mail should construct the message in a similar fashion to the Form API, specifying a theme for rendering the body part of the message (ie what goes in the <body> tag) and anything special that needs to go in the head as attributes.
That way the message can be constructed only once.
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
__________ Información de NOD32, revisión 3270 (20080715) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com __________ Información de NOD32, revisión 3270 (20080715) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com
There's a patch here that's not had much attention for over a year but would provide better support in core: http://drupal.org/node/28604 You should also look at http://drupal.org/project/mimemail Nat On Wed, Jul 16, 2008 at 10:22 AM, Omar Abdel-Wahab wrote:
+1
I strongly would love to have D7 send HTML e-mails.
At least 20 modules will benefit from this step.
Omar
Matt Connolly wrote:
I haven't looked at drupal 7 yet, so I'm throwing this out there for discussion.
The D6 mail api seems like it's pretty much designed for plain text emails, however, a module's implementation of hook_mail can clearly set the headers of the mail to "Content-Type: text/html; charset=utf-8" and send rich text.
For example, I'm looking at using "forward" module for the "email this page" link on a node, and the "simplenews" module, which uses "mimemail" to send rich emails, including attachments. Both "forward" and "mimemail" modules create a html header.
The problem occurs when a module implements "drupal_mail_wrapper()" to build a html header when hook_mail has already done that - you can easily end up with bodies like:
<!doctype... <-- from drupal_mail_wrapper() <html> <head>...</head> <body><div.... <!doctype. <-- from hook_mail() <html> <head> ... etc.
Because there are two opportunities to create the html "head" for the message: in hook_mail and drupal_mail_wrapper.
I'm throwing this out there for discussion, I think that the hook_mail should construct the message in a similar fashion to the Form API, specifying a theme for rendering the body part of the message (ie what goes in the <body> tag) and anything special that needs to go in the head as attributes.
That way the message can be constructed only once.
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
Yes, I am trying to use "mimemail", just ported the code to Drupal 6 yesterday. The problem is that other modules that don't use mimemail duplicate some of its functionality, which makes sense when the module is not present. At the moment, I'm manually re-theming the other modules to not create "<html><head>" stuff to play nice with mimemail. Ideally, though, you could set html head elements in an array in a similar fashion to for FORM API so that mimemail (or any HTML aware drupal mail module) could interpret and include in the constructed email message in the correct place. ie: returning a structured array instead of a flat string. Although this may be contrary to how theme functions work... It makes sense to me that modules should only create the content that goes in a <DIV> tag, just like building a block on the page. However, many modules call drupal_add_css or drupal_add_js which ultimately gets added to the page when it's rendered. I think email generation should have the same ability to include CSS files (which should go in the <HEAD> tag, not a <DIV>) I notice that mimemail does in fact get the CSS files from drupal and the current theme (in the absence of a mail.css file) so you can simply call drupal_add_cs() from a theme function that generates email.... just confusing if you're generating an email, and then a resulting page at the same time..... -Matt On 16/07/2008, at 10:46 AM, Nathaniel Catchpole wrote:
There's a patch here that's not had much attention for over a year but would provide better support in core: http://drupal.org/node/28604
You should also look at http://drupal.org/project/mimemail
Nat
On Wed, Jul 16, 2008 at 10:22 AM, Omar Abdel-Wahab wrote: +1
I strongly would love to have D7 send HTML e-mails.
At least 20 modules will benefit from this step.
Omar
Matt Connolly wrote: I haven't looked at drupal 7 yet, so I'm throwing this out there for discussion.
The D6 mail api seems like it's pretty much designed for plain text emails, however, a module's implementation of hook_mail can clearly set the headers of the mail to "Content-Type: text/html; charset=utf-8" and send rich text.
For example, I'm looking at using "forward" module for the "email this page" link on a node, and the "simplenews" module, which uses "mimemail" to send rich emails, including attachments. Both "forward" and "mimemail" modules create a html header.
The problem occurs when a module implements "drupal_mail_wrapper()" to build a html header when hook_mail has already done that - you can easily end up with bodies like:
<!doctype... <-- from drupal_mail_wrapper() <html> <head>...</head> <body><div.... <!doctype. <-- from hook_mail() <html> <head> ... etc.
Because there are two opportunities to create the html "head" for the message: in hook_mail and drupal_mail_wrapper.
I'm throwing this out there for discussion, I think that the hook_mail should construct the message in a similar fashion to the Form API, specifying a theme for rendering the body part of the message (ie what goes in the <body> tag) and anything special that needs to go in the head as attributes.
That way the message can be constructed only once.
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
A problem with HTML mails and CSS is that they don't render the same in all mail clients. I have searched a way to convert CSS page into pure HTML (without CSS) before sending it, but I didn't found any way to do so. Maybe something like http://wiki.tcl.tk/12383 but for PHP would make sent mails look better. On Wed, Jul 16, 2008 at 12:32 PM, Matt Connolly <matt@cabinetuk.com> wrote:
Yes, I am trying to use "mimemail", just ported the code to Drupal 6 yesterday. The problem is that other modules that don't use mimemail duplicate some of its functionality, which makes sense when the module is not present. At the moment, I'm manually re-theming the other modules to not create "<html><head>" stuff to play nice with mimemail. Ideally, though, you could set html head elements in an array in a similar fashion to for FORM API so that mimemail (or any HTML aware drupal mail module) could interpret and include in the constructed email message in the correct place. ie: returning a structured array instead of a flat string. Although this may be contrary to how theme functions work...
It makes sense to me that modules should only create the content that goes in a <DIV> tag, just like building a block on the page. However, many modules call drupal_add_css or drupal_add_js which ultimately gets added to the page when it's rendered. I think email generation should have the same ability to include CSS files (which should go in the <HEAD> tag, not a <DIV>) I notice that mimemail does in fact get the CSS files from drupal and the current theme (in the absence of a mail.css file) so you can simply call drupal_add_cs() from a theme function that generates email.... just confusing if you're generating an email, and then a resulting page at the same time.....
-Matt
On 16/07/2008, at 10:46 AM, Nathaniel Catchpole wrote:
There's a patch here that's not had much attention for over a year but would provide better support in core: http://drupal.org/node/28604
You should also look at http://drupal.org/project/mimemail
Nat
On Wed, Jul 16, 2008 at 10:22 AM, Omar Abdel-Wahab wrote:
+1
I strongly would love to have D7 send HTML e-mails.
At least 20 modules will benefit from this step.
Omar
Matt Connolly wrote:
I haven't looked at drupal 7 yet, so I'm throwing this out there for discussion.
The D6 mail api seems like it's pretty much designed for plain text emails, however, a module's implementation of hook_mail can clearly set the headers of the mail to "Content-Type: text/html; charset=utf-8" and send rich text.
For example, I'm looking at using "forward" module for the "email this page" link on a node, and the "simplenews" module, which uses "mimemail" to send rich emails, including attachments. Both "forward" and "mimemail" modules create a html header.
The problem occurs when a module implements "drupal_mail_wrapper()" to build a html header when hook_mail has already done that - you can easily end up with bodies like:
<!doctype... <-- from drupal_mail_wrapper() <html> <head>...</head> <body><div.... <!doctype. <-- from hook_mail() <html> <head> ... etc.
Because there are two opportunities to create the html "head" for the message: in hook_mail and drupal_mail_wrapper.
I'm throwing this out there for discussion, I think that the hook_mail should construct the message in a similar fashion to the Form API, specifying a theme for rendering the body part of the message (ie what goes in the <body> tag) and anything special that needs to go in the head as attributes.
That way the message can be constructed only once.
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
-- *La vida és com una moneda, la pots gastar en el que vulguis però només una vegada. *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les il·lusions. *Als llocs desconeguts només s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient.
On Jul 16, 2008, at 5:32 AM, Matt Connolly wrote:
At the moment, I'm manually re-theming the other modules to not create "<html><head>" stuff to play nice with mimemail.
If there's a generalizeable way to do this, I'd be a huge fan of its implementation. Please see http://drupal.org/node/ 121849#comment-915935 for a description of how messages are themed and how to override them. The goal here was to have something that looks consistent without creating a giant themeing task for admins and users; and without any knowledge or assumptions of how a site is themed. By default, Mime Mail includes copies of your CSS information inside of your message's <head> section. In many cases this looks pretty great, but it can lead to some darn large messages. Also, as indicated here, several mail clients don't read the CSS information in the head section. Mostly, this just means gmail and hotmail - see http://www.campaignmonitor.com/css/ It would be super-awesome if someone could help this module - for everyone - by a) attempting to reduce the overall size of included CSS content and b) attempt to migrate some element and style definitions into the body of the message to combat the "gmail problem" Thanks, Allie Micka Advantage Labs, Inc.
On Wed, 16 Jul 2008 12:22:49 +0300 Omar Abdel-Wahab <owahab@owahab.com> wrote:
+1
I strongly would love to have D7 send HTML e-mails.
At least 20 modules will benefit from this step.
What would be really lovely would be support both. The only way I've found to turn HTML into "formatted" text was to pipe HTML through w3m. Not a scalable solution. I haven't found any library that could render HTML to text in a decent way. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Thank's! Solved updating to the new beta version and recreating manually the tables. -----Mensaje original----- De: development-bounces@drupal.org [mailto:development-bounces@drupal.org] En nombre de Ivan Sergio Borgonovo Enviado el: dimecres, 16 / juliol / 2008 12:04 Para: development@drupal.org Asunto: Re: [development] HTML emails On Wed, 16 Jul 2008 12:22:49 +0300 Omar Abdel-Wahab <owahab@owahab.com> wrote:
+1
I strongly would love to have D7 send HTML e-mails.
At least 20 modules will benefit from this step.
What would be really lovely would be support both. The only way I've found to turn HTML into "formatted" text was to pipe HTML through w3m. Not a scalable solution. I haven't found any library that could render HTML to text in a decent way. -- Ivan Sergio Borgonovo http://www.webthatworks.it __________ Informacisn de NOD32, revisisn 3270 (20080715) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com
On Wed, 16 Jul 2008 10:12:33 +0100, Matt Connolly <matt@cabinetuk.com> wrote:
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
I am going to take the luddite position. Consider yourself warned. :-) HTML email is not, as far as I am aware, an actual standard. It is a de facto convention for a hack of the SMTP protocol using a tool that was never built for it. It also breaks nearly every convention of email usage (at least as far as replies are involved), and wastes gobs and gobs of bandwidth, especially for the increasing number of people on mobile devices. It serves no purpose except to send spam (both legit and not, I am going to call all marketing emails spam even if they are solicited as a debate tactic), which means it is filtered out by mail servers more frequently. They are also a wonderful attack vector for viruses and trojans. As a result, many many email clients don't render HTML email by default, showing a blob of unrecognizable HTML instead. Some moronic mail senders send out HTML emails that have no plaintext version, which makes them unreadable to many people (who do not, in fact, accept HTML email). As others have mentioned, support for anything pos t-HTML 3.2 in email varies widely, and you can't exactly do client targeting over email. Why should we encourage that? As far as I'm concerned, we shouldn't. That said, there may well be advantages to switching to drupal_render() for email messages. I am in general a big fan of structured data remaining structured for as long as possible. The benefit, however, would not be for HTML mail but for, say, easier email attachments. That such a move would make it easier to send HTML email as well, well, that's a side effect I suppose we can live with. </rant> --Larry Garfield
On Wed, 16 Jul 2008 9:59:01 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
That said, there may well be advantages to switching to drupal_render() for email messages. I am in general a big fan of structured data remaining structured for as long as possible. The
I really really would like to avoid HTML emails and I agree with most of your points and they are enough to hate html emails. Anyway it is a very frequently requested feature. I know consistency of rendering of HTML is a hell... but it is still a very frequent request we have to live with. We have a rendering engine that is specialised to render HTML. Even if mobile devices are getting more and more popular, they are getting more and more able to render html as it is. Template system makes much easier to delegate design tasks to non programmers compared to XLS/XML/whatever and building up a more flexible rendering engine may take a long time... why not just provide a way to build up structured emails (attachment, auto inclusion of CSS etc...) and something that just do html2text? BTW I didn't find html2text up to the task. w3m provided the best results in the tools I've used... but there is no w3m library that I know that can be easily integrated in php. Rewriting a text browser in php doesn't look to be easy. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Larry Garfield schrieb:
I am going to take the luddite position. Consider yourself warned. :-)
Thanks (for your position, not the warning). Plaintext should be the default and HTML _could_ be an option. If HTML is used, it should contain a plaintext version. Eric
Eric-Alexander Schaefer wrote:
Larry Garfield schrieb:
I am going to take the luddite position. Consider yourself warned. :-)
Thanks (for your position, not the warning). Plaintext should be the default and HTML _could_ be an option. If HTML is used, it should contain a plaintext version.
It MUST contain a plaintext version (per RFC 2119 [1]) [1] http://tools.ietf.org/html/rfc2119
Eric
-- Benjamin Lewis Fedora Ambassador ben.lewis@benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118
On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote:
Eric-Alexander Schaefer wrote:
Larry Garfield schrieb:
I am going to take the luddite position. Consider yourself warned. :-)
Thanks (for your position, not the warning). Plaintext should be the default and HTML _could_ be an option. If HTML is used, it should contain a plaintext version.
It MUST contain a plaintext version (per RFC 2119 [1])
You're making the naive assumption that people actually follow that requirement. :-) LOTS of email floating about the Net, both legit and spam/trojans, contains HTML and no body. And sending the message twice (plain and HTML) is a slap in the face to anyone on low bandwidth. drupal_render() for mail does have potential advantages. That it may make it easier for *contribs* to send HTML email is a downside I am willing to accept. -- Larry Garfield larry@garfieldtech.com
I'd go for allowing users to choose the e-mail format they prefer to receive in their account screen. Omar Larry Garfield wrote:
On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote:
Eric-Alexander Schaefer wrote:
Larry Garfield schrieb:
I am going to take the luddite position. Consider yourself warned. :-) Thanks (for your position, not the warning). Plaintext should be the default and HTML _could_ be an option. If HTML is used, it should contain a plaintext version. It MUST contain a plaintext version (per RFC 2119 [1])
You're making the naive assumption that people actually follow that requirement. :-) LOTS of email floating about the Net, both legit and spam/trojans, contains HTML and no body. And sending the message twice (plain and HTML) is a slap in the face to anyone on low bandwidth.
drupal_render() for mail does have potential advantages. That it may make it easier for *contribs* to send HTML email is a downside I am willing to accept.
On Wed, Jul 16, 2008 at 6:59 PM, Larry Garfield <larry@garfieldtech.com> wrote:
On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote:
Eric-Alexander Schaefer wrote:
Larry Garfield schrieb:
I am going to take the luddite position. Consider yourself warned. :-)
Thanks (for your position, not the warning). Plaintext should be the default and HTML _could_ be an option. If HTML is used, it should contain a plaintext version.
It MUST contain a plaintext version (per RFC 2119 [1])
You're making the naive assumption that people actually follow that requirement. :-) LOTS of email floating about the Net, both legit and spam/trojans, contains HTML and no body. And sending the message twice (plain and HTML) is a slap in the face to anyone on low bandwidth.
-- Larry Garfield larry@garfieldtech.com
Urban legends aside, actually it is not a naive assumption, it's a valid one and the referenced RFC is a good starting point for anyone wanting to develop a valid message format. The vast majority of spam filters will in fact block as spam malformed messages. A message is considered malformed if it only has HTML content and no text component. The percentage in gross terms of malformed messages (particularly deliberate spam) is fairly low to the overall percentage of email. We block approximately 85-90% of the incoming email where I work as spam and of that 85-90% less than 2% is triggered as malformed. It is a mid-sized environment with about 30 million messages in the last month. In the early days of spam (where simple word filters roamed free as the tool of choice), malformed messages were not tested for and as a result spammers used that technique for a while. While sending HTML messages is in fact harder on low bandwidth recipients, HTML messages are a fact of life and there is a portion of a given customer base that does in fact want to use it.
Steven Peck wrote:
On Wed, Jul 16, 2008 at 6:59 PM, Larry Garfield <larry@garfieldtech.com> wrote:
On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote:
Eric-Alexander Schaefer wrote:
Larry Garfield schrieb:
I am going to take the luddite position. Consider yourself warned. :-) Thanks (for your position, not the warning). Plaintext should be the default and HTML _could_ be an option. If HTML is used, it should contain a plaintext version. It MUST contain a plaintext version (per RFC 2119 [1])
[1] http://tools.ietf.org/html/rfc2119 You're making the naive assumption that people actually follow that requirement. :-) LOTS of email floating about the Net, both legit and spam/trojans, contains HTML and no body. And sending the message twice (plain and HTML) is a slap in the face to anyone on low bandwidth.
-- Larry Garfield larry@garfieldtech.com
Urban legends aside, actually it is not a naive assumption, it's a valid one and the referenced RFC is a good starting point for anyone wanting to develop a valid message format. The vast majority of spam filters will in fact block as spam malformed messages. A message is considered malformed if it only has HTML content and no text component. The percentage in gross terms of malformed messages
I also hate it when I receive messages that say something like: "You need to upgrade your mail client to see HTML messages" That is not, imho, a good enough text component and it would be really good if this could _also_ be avoided.
(particularly deliberate spam) is fairly low to the overall percentage of email. We block approximately 85-90% of the incoming email where I work as spam and of that 85-90% less than 2% is triggered as malformed. It is a mid-sized environment with about 30 million messages in the last month. In the early days of spam (where simple word filters roamed free as the tool of choice), malformed messages were not tested for and as a result spammers used that technique for a while.
Exactly, so it is absolutely paramount that we output well-formed messages.
While sending HTML messages is in fact harder on low bandwidth recipients, HTML messages are a fact of life and there is a portion of a given customer base that does in fact want to use it.
-- Benjamin Lewis Fedora Ambassador ben.lewis@benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118
That said, there may well be advantages to switching to drupal_render() for email messages.
+1 Also, I think it's more than appropriate to keep HTML-formatting and Mime machinations out of core. However, Drupal can't go around assuming that messages *won't* be HTML until it's ready to send them out, and then do its html-to-text conversion then. Thanks! Allie Micka Advantage Labs, Inc.
Larry Garfield wrote:
On Wed, 16 Jul 2008 10:12:33 +0100, Matt Connolly <matt@cabinetuk.com> wrote:
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Matt
I am going to take the luddite position. Consider yourself warned. :-)
HTML email is not, as far as I am aware, an actual standard.
Well there's this http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html and there's the fact that over half of emails sent are html formatted ;-)
Why should we encourage that? As far as I'm concerned, we shouldn't.
That said, there may well be advantages to switching to drupal_render() for email messages. I am in general a big fan of structured data remaining structured for as long as possible. The benefit, however, would not be for HTML mail but for, say, easier email attachments. That such a move would make it easier to send HTML email as well, well, that's a side effect I suppose we can live with.
I have just been working on an email that I need Drupal to send which include both tabular data and a graph In Drupal 5 the mimemail module worked a treat for this. Yes I had to work at getting the formatting to work consistently - but then what's new - it's just another dimension to cross browser support. It would be really useful to have the ability to more easily send formatted mail - the more ways too cleanly hook into Drupal's email sending process the better. I don't like HTML email - but I don't dictate my preferences to clients. If they want formatted email with company logos and and 3 pages of legal disclaimers - I may try to inform them of alternatives - but if its what they want and they're paying - it's what I'll provide. -- Sean Burlington www.practicalweb.co.uk
That's a great spec for constructing multi part messages, but it doesn't really go in to HTML at all. Is there a standard, for example, for using content-inline-disposition links to use an attached image in the html document? Does HTML email conform to HTML3 HTML4 XHTML1.0, etc? 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). -Matt On 20/07/2008, at 8:15 PM, Sean Burlington wrote:
Well there's this
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
and there's the fact that over half of emails sent are html formatted
;-)
Why should we encourage that? As far as I'm concerned, we shouldn't. That said, there may well be advantages to switching to drupal_render() for email messages. I am in general a big fan of structured data remaining structured for as long as possible. The benefit, however, would not be for HTML mail but for, say, easier email attachments. That such a move would make it easier to send HTML email as well, well, that's a side effect I suppose we can live with.
I have just been working on an email that I need Drupal to send which include both tabular data and a graph
In Drupal 5 the mimemail module worked a treat for this.
Yes I had to work at getting the formatting to work consistently - but then what's new - it's just another dimension to cross browser support.
It would be really useful to have the ability to more easily send formatted mail - the more ways too cleanly hook into Drupal's email sending process the better.
I don't like HTML email - but I don't dictate my preferences to clients.
If they want formatted email with company logos and and 3 pages of legal disclaimers - I may try to inform them of alternatives - but if its what they want and they're paying - it's what I'll provide.
--
Sean Burlington
www.practicalweb.co.uk
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
On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly <matt@cabinetuk.com> wrote:
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Have you even tried to make an HTML email look the same in multiple email clients? That stuff is impossible... and forget it if you want colored anchors or css support consistently. Heck they don't even send mime attachments consistently... They all do something close to spec... and lets not even get into the quirks of various webmail clients and the pluthera of different versions of MS Outlook in the wild and still supported by MS. You basically have a minimum of 8 different applications that handle HTML slightly differently. There are also major variations per version... If you thought cross browser support was annoying you haven't seen anything yet... apple: mac mail windows: outlook 8 -> present, including express variations. // each outlook seems to use a different combination renderer and mime library. linux: evolution cross platform: eudora mac, eudora pc, thunderbird web: gmail, windows live/hotmail, yahoo but using drupal_render ++ .darrel.
Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven:
On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly <matt@cabinetuk.com> wrote:
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Have you even tried to make an HTML email look the same in multiple email clients? That stuff is impossible... and forget it if you want colored anchors or css support consistently. Heck they don't even send mime attachments consistently... They all do something close to spec... and lets not even get into the quirks of various webmail clients and the pluthera of different versions of MS Outlook in the wild and still supported by MS.
It isn't impossible! Just use CSS and make sure you have a wrapper div around your HTML- layout, styled with the CSS. The only thing that breaks your e-mails along the different e-mail clients is when you add styling to the <body>...</body> of your HTML e- mail. Stefan
On Wed, 2008-07-16 at 18:44 +0200, Stefan Nagtegaal wrote:
Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven:
On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly <matt@cabinetuk.com> wrote:
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Have you even tried to make an HTML email look the same in multiple email clients? That stuff is impossible... and forget it if you want colored anchors or css support consistently. Heck they don't even send mime attachments consistently... They all do something close to spec... and lets not even get into the quirks of various webmail clients and the pluthera of different versions of MS Outlook in the wild and still supported by MS.
It isn't impossible! Just use CSS and make sure you have a wrapper div around your HTML-layout, styled with the CSS. The only thing that breaks your e-mails along the different e-mail clients is when you add styling to the <body>...</body> of your HTML e-mail.
Some current email clients support HTML but *not* CSS. Xav
True, but it doesn't mean HTML mail is not useful with or without css. I use HTML messages in Drupal applications to bring emphasis (h1,h2,etc) tags, transmit bold and italics, and show data in tables. I don't use the drupal mail apis because they don't support html :) Dave On Jul 24, 2008, at 1:36 AM, Xavier Bestel wrote:
On Wed, 2008-07-16 at 18:44 +0200, Stefan Nagtegaal wrote:
Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven:
On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly <matt@cabinetuk.com> wrote:
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Have you even tried to make an HTML email look the same in multiple email clients? That stuff is impossible... and forget it if you want colored anchors or css support consistently. Heck they don't even send mime attachments consistently... They all do something close to spec... and lets not even get into the quirks of various webmail clients and the pluthera of different versions of MS Outlook in the wild and still supported by MS.
It isn't impossible! Just use CSS and make sure you have a wrapper div around your HTML-layout, styled with the CSS. The only thing that breaks your e-mails along the different e-mail clients is when you add styling to the <body>...</body> of your HTML e-mail.
Some current email clients support HTML but *not* CSS.
Xav
On Thu, 24 Jul 2008 22:32:34 -0700 David Metzler <metzlerd@metzlerd.com> wrote:
True, but it doesn't mean HTML mail is not useful with or without css.
I use HTML messages in Drupal applications to bring emphasis (h1,h2,etc) tags, transmit bold and italics, and show data in tables. I don't use the drupal mail apis because they don't
I'd say that while layout helps increasing efficiency of communication in some cases (have you noticed how much italics, bold, colors are used in a science book compared to a literature book?) HTML emails are still to be used with extreme care. In a browser you can turn off images, you've a stop button, you can chose a textual browser that will avoid to download css and js.... You don't have so much freedom in an email reader and while email is some how pull content (you chose to pull emails from the server) it looks more like a push content (think about spam). When you really need more control on "layout" in an email most of the times you'd be better to add a suitable attachment or provide a link. Most of the times we are required to provide html emails it is for "spammish" reasons. Still among non geeks there is an unbelievably high percent of people that prefer to receive html emails when they are given the choice. If we're honest about why we generally have to send html emails from drupal we could build something that could really be useful. Most of the times we send out html emails to replicate the look&feel of the web site. I'm perfectly aware of the limitations of such approach... but readability is surely not the most frequent (reasonable?) reason why we are required to send out html. If readability was our first concern we wouldn't send out html emails. mimemail already does a good job since it includes css directly from the website. What maybe is missing is a bit more logic on the core side to dynamically manage the added css and template according to different media. When I had to send html emails I didn't use mimemail because my first target was actually to have well formatted textual content out of HTML.
support html :)
In a perfect world we shouldn't. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Op 24 jul 2008, om 10:36 heeft Xavier Bestel het volgende geschreven:
On Wed, 2008-07-16 at 18:44 +0200, Stefan Nagtegaal wrote:
Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven:
On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly <matt@cabinetuk.com> wrote:
Besides, email clients have been HTML friendly for a *long* time, so I don't see why Drupal shouldn't have an interface that understands rich email messages.
Thoughts?
Have you even tried to make an HTML email look the same in multiple email clients? That stuff is impossible... and forget it if you want colored anchors or css support consistently. Heck they don't even send mime attachments consistently... They all do something close to spec... and lets not even get into the quirks of various webmail clients and the pluthera of different versions of MS Outlook in the wild and still supported by MS.
It isn't impossible! Just use CSS and make sure you have a wrapper div around your HTML-layout, styled with the CSS. The only thing that breaks your e-mails along the different e-mail clients is when you add styling to the <body>...</body> of your HTML e-mail.
Some current email clients support HTML but *not* CSS.
They do, but you should use the CSS inside the header itself, and not as a external file. I'm sorry, I should have said so in the first place.. Stefan
participants (16)
-
Allie Micka -
Benjamin Lewis -
Darrel O'Pry -
David Metzler -
Eric-Alexander Schaefer -
Ivan Sergio Borgonovo -
Larry Garfield -
Lluís -
marolijo - Pol Maresma -
Matt Connolly -
Nathaniel Catchpole -
Omar Abdel-Wahab -
Sean Burlington -
Stefan Nagtegaal -
Steven Peck -
Xavier Bestel