Re: [PHP] HTML in emails
At 10:09 PM -0400 7/6/10, Paul M Foster wrote: On Tue, Jul 06, 2010 at 06:32:40PM +0200, Per Jessen wrote: In principle, I agree - in practice, CPU cycles are getting cheaper by the minute, and being wasted all the time. Not using HTML is highly unlikely to have a measurable impact on anybodys CPU cycles. I keep hearing this argument. Here are what I consider similar arguments. Everyone else pours their waste into the river. Ours won't make that much difference. Our smokestack is just one of hundreds in the city. No one will notice the additional smoke. Putting paint thinner down the toilet won't make any difference. The water processing plant will clean it up. Just because everyone else wastes CPU doesn't mean you have to contribute to it, too. I keep hearing this argument too! There's always two sides to every argument -- to extend your metaphor, as a result of pollution we have the EPA and other environmental concerns who are now so focused on the rules they actually hurt the quality of life for *all* things (the recent Gulf Oil Spill is one of thousands of examples). The application of any rule-set should be tempered with how it affects the whole and not the just a part. The term Waste in the phrase Wasting CPU cycles is dependant upon what yardstick you use to measure what waste means. I do not think it a waste when you break your code into more manageable parts as compared to creating a cryptic routine that simply runs quicker. When creating code, there are things more important things to consider than CPU cycles, such as readability, maintainability, and reusability. Every programmer has to realize that Wasting CPU cycles (like wasting memory) is becoming exponentially less of a problem whereas creating reusable code is doing just the opposite. So when considering waste I hold programmer's time in more regard than CPU cycles. Just because some people write cryptic code, doesn't mean you have too. :-) Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
On 2010-07-04 11:43 -0400, Al wrote: Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. Browsers ? The web ? I thought it was about email ? If it's HTML, I have to decode and save the email to a file from my MUA and then switch a browser to read it. As you can imagine, I rarely bother. It use to be that we specified content-type text/html, etc. and sent both the plain ASCII and the html with boundaries and so forth. That is the only sane approach. -- André Majorel http://www.teaser.fr/~amajorel/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
Paul M Foster wrote: Here is the real problem with HTML email. Any straight text message will swell to many times its size when you HTML-ize it. Okay, so now you're sending the message around the internet to perhaps hundreds or thousands of users, using up many times the bandwidth that the actual message really needs. It's like installing a 100w light bulb when a 60w will do. There's simply no reason to suck CPU cycles all over the internet just to make your message prettier. In principle, I agree - in practice, CPU cycles are getting cheaper by the minute, and being wasted all the time. Not using HTML is highly unlikely to have a measurable impact on anybodys CPU cycles. Besides, HTML is not just about making the message prettier. A number of times I have experienced that important system notifications (from our systems to customers') were simply ignored, apparently due to being plain text. We decided to jazz them up a bit, and it worked. -- Per Jessen, Zürich (25.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
On Tuesday, July 06, 2010 07:03:58 am Andre Majorel wrote: On 2010-07-04 11:43 -0400, Al wrote: Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. Browsers ? The web ? I thought it was about email ? If it's HTML, I have to decode and save the email to a file from my MUA and then switch a browser to read it. As you can imagine, I rarely bother. I agree, actually my filters are setup to send HTML to the trash can. Its a security risk in some cases. It use to be that we specified content-type text/html, etc. and sent both the plain ASCII and the html with boundaries and so forth. That is the only sane approach. -- Russ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
On Tue, Jul 06, 2010 at 06:32:40PM +0200, Per Jessen wrote: Paul M Foster wrote: Here is the real problem with HTML email. Any straight text message will swell to many times its size when you HTML-ize it. Okay, so now you're sending the message around the internet to perhaps hundreds or thousands of users, using up many times the bandwidth that the actual message really needs. It's like installing a 100w light bulb when a 60w will do. There's simply no reason to suck CPU cycles all over the internet just to make your message prettier. In principle, I agree - in practice, CPU cycles are getting cheaper by the minute, and being wasted all the time. Not using HTML is highly unlikely to have a measurable impact on anybodys CPU cycles. I keep hearing this argument. Here are what I consider similar arguments. Everyone else pours their waste into the river. Ours won't make that much difference. Our smokestack is just one of hundreds in the city. No one will notice the additional smoke. Putting paint thinner down the toilet won't make any difference. The water processing plant will clean it up. Just because everyone else wastes CPU doesn't mean you have to contribute to it, too. Besides, HTML is not just about making the message prettier. A number of times I have experienced that important system notifications (from our systems to customers') were simply ignored, apparently due to being plain text. We decided to jazz them up a bit, and it worked. s/prettier/more noticeable/g Same point. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
On Sun, 2010-07-04 at 23:12 -0400, Paul M Foster wrote: On Sun, Jul 04, 2010 at 11:44:29PM +0100, Ashley Sheridan wrote: snip It is nice to be able to format emails nicely, but you have to realise when to restrain yourself. I've been getting loads of emails from Adobe lately that haven't been formatted well at all, and appear awfully in my email client (Evolution, which I consider to be a very good client) until I download all the images they've used as backgrounds. It's situations like this that give HTML emails an awful name. Isn't this a popular exploit these days? I don't really watch these things since I use Linux and view mail as straight text. But isn't there some current exploit where images which can be downloaded as part of an email actually contain code which can be used to sniff your system or somesuch? Paul -- Paul M. Foster Probably if you're using Outlook I'd imagine so. I think the primary use of images in an email is to track who has read it, as you can reference an image like http://www.somedomain.com/image.php?id=123456 . That's why I have them turned off by default, and hence why Adobes mails always look awful. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] HTML in emails
On 4 July 2010 16:43, Al n...@ridersite.org wrote: What are you folks doing? Al.. One of the tasks I had to develop was the sending of authorised work in a by job report. We receive the work as a fax/email. We log the job in our system. The client comes to our site and confirms the on-cost billing to the job. We produce the invoices for their clients. We produce HTML emails which render just fine in Outlook 2003+, Outlook Express (we are told they are fine - I've never actually bothered), GMail (I use it) and Yahoo's email (again we are told it is OK). Sure, the plain text part for most normal emails is what is read by most developers, but this client isn't a developer. So comments like eye-candy is exactly what it is all about. They use their email tool to read communications. If the communications are easier to understand, laid out nicely, look like the secured webpage, then the customer is a happy one. In producing the HTML, I had to back date my thinking a decade or so. So, I use table and some VERY limited inline styling. Not because I want to. But because the application with the largest market share for reading email in my customer base requires me to do so. Regards, Richard. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
At 11:44 PM +0100 7/4/10, Ashley Sheridan wrote: On Sun, 2010-07-04 at 17:06 -0400, Paul M Foster wrote: On Sun, Jul 04, 2010 at 11:43:59AM -0400, Al wrote: -snip- Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. What are you folks doing? I use mutt for email, so I only see the text portion. That make me an anomaly. However, for example there are various listserv software that will not allow HTML in emails. -snip- Paul -snip- One feature I've seen in some mailing list software is the ability to track how people prefer their email formatted, so that you only send HTML emails to those that want them, and text emails to those who prefer that method. It's the best of both worlds I reckon, and one that is likely to upset as few people as possible; at the worst they might receive one email in a format they don't want before they change their preferences. Ash I agree with both Paul and Ash but for a different reason. Receiving email is much like looking at web sites -- it's data provided from a server to an application to be shown to a user. In the case of web sites, html is provided to a browser and the browser presents the content to the user via the instructions provided by the html and others, such as css and javascript. Unfortunately, if you've done any web sites at all, you know that not all (less than a score of them) browsers are created equal and while your web site may look great in your browser, it sucks in another. It takes a lot of work to make a web site look consistent on all modern browsers. Here's a little something I wrote about it: http://sperling.com/four-things-clients-should-know.php Now throw on to this problem how hundreds of different email applications running under hundreds of different OS's (this includes hand held devices) handle html/css/javascript and you'll have an idea of the size of the problem of how to present data to the user via the user's device. Sending HTML in email isn't the problem, but receiving and displaying HTML in email IS. Simply put, there isn't a standard for sending/receiving email and while clients may want a pretty email to be sent to all their customers, they are clueless as to what their customers will actually receive. Furthermore, there is considerable pressure by clients on developers to create the prefect email. Unfortunately, some developers succumb to the pressure (or they don't know any better) and create a send/receive that works for a special case, namely something sufficient for management to think the problem has been solved but it hasn't -- perhaps that's the reason why Adobe emails look so bad -- management still doesn't understand the problem and their developers either don't know any better, or are afraid to tell management the truth. But proof is in the pudding and while they may think the Emperor's new clothes are magnificent, they aren't. My advice, send text! If you want the end user to see something, then send a link. But do not send HTML in email until every known browser conforms to W3C standards. At that point, then we can start working on hand-held devices to follow the standards as well. When that is finished, then we can consider sending something other than text in an email. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] HTML in emails
I know this is a bit off-topic; but close enough. I'm starting to update the email feature of one of my DB applications and noticed that it appears most of the fancy emails I receive are using just plain old, simple html pages, with a note about not being able to see, go here with a link. It use to be that we specified content-type text/html, etc. and sent both the plain ASCII and the html with boundaries and so forth. Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. What are you folks doing? Al.. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
Al wrote: I know this is a bit off-topic; but close enough. I'm starting to update the email feature of one of my DB applications and noticed that it appears most of the fancy emails I receive are using just plain old, simple html pages, with a note about not being able to see, go here with a link. It use to be that we specified content-type text/html, etc. and sent both the plain ASCII and the html with boundaries and so forth. Yes, multipart/alternative that was. Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. What are you folks doing? We follow the standard and send both text and html. -- Per Jessen, Zürich (24.5°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
On Sun, Jul 04, 2010 at 06:31:38PM +0200, Per Jessen wrote: Al wrote: I know this is a bit off-topic; but close enough. I'm starting to update the email feature of one of my DB applications and noticed that it appears most of the fancy emails I receive are using just plain old, simple html pages, with a note about not being able to see, go here with a link. Such emails are stupid. Obviously I can read the email quite fine. The problem is that there is no useful content. Just an instruction to click on a link. It use to be that we specified content-type text/html, etc. and sent both the plain ASCII and the html with boundaries and so forth. Yes, multipart/alternative that was. Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. Then I will never read your email. Browsers are for web pages, not email. What are you folks doing? We follow the standard and send both text and html. The text portion is the *only* portion I read. -- When dealing with people, remember you are not dealing with creatures of logic, but creatures of emotion. -- Dale Carnegie Rick Pasottor...@niof.nethttp://www.niof.net -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
Rick Pasotto wrote: On Sun, Jul 04, 2010 at 06:31:38PM +0200, Per Jessen wrote: We follow the standard and send both text and html. The text portion is the *only* portion I read. Cool, that is the whole point. -- Per Jessen, Zürich (24.3°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
On Sun, Jul 04, 2010 at 11:43:59AM -0400, Al wrote: I know this is a bit off-topic; but close enough. I'm starting to update the email feature of one of my DB applications and noticed that it appears most of the fancy emails I receive are using just plain old, simple html pages, with a note about not being able to see, go here with a link. It use to be that we specified content-type text/html, etc. and sent both the plain ASCII and the html with boundaries and so forth. Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. What are you folks doing? I use mutt for email, so I only see the text portion. That make me an anomaly. However, for example there are various listserv software that will not allow HTML in emails. Here is the real problem with HTML email. Any straight text message will swell to many times its size when you HTML-ize it. Okay, so now you're sending the message around the internet to perhaps hundreds or thousands of users, using up many times the bandwidth that the actual message really needs. It's like installing a 100w light bulb when a 60w will do. There's simply no reason to suck CPU cycles all over the internet just to make your message prettier. I understand that the functions of email and browser seem to be merging. However, this is what I would consider a bad trend. It stems from folks like Microsoft who have convinced people, for example, that spreadsheets function perfectly well as databases. They don't, but that doesn't stop people from using Excel to keep their mailing lists. Of course, opinions like mine won't stop the merging of browsing and reading email. Ah well. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML in emails
On Sun, 2010-07-04 at 17:06 -0400, Paul M Foster wrote: On Sun, Jul 04, 2010 at 11:43:59AM -0400, Al wrote: I know this is a bit off-topic; but close enough. I'm starting to update the email feature of one of my DB applications and noticed that it appears most of the fancy emails I receive are using just plain old, simple html pages, with a note about not being able to see, go here with a link. It use to be that we specified content-type text/html, etc. and sent both the plain ASCII and the html with boundaries and so forth. Seems like, from my preliminary Google searching, I should not waste time with the standard's way and just go straight to sending simple html pages since all modern browsers handle it well. And, it appears to be the way web is going. What are you folks doing? I use mutt for email, so I only see the text portion. That make me an anomaly. However, for example there are various listserv software that will not allow HTML in emails. Here is the real problem with HTML email. Any straight text message will swell to many times its size when you HTML-ize it. Okay, so now you're sending the message around the internet to perhaps hundreds or thousands of users, using up many times the bandwidth that the actual message really needs. It's like installing a 100w light bulb when a 60w will do. There's simply no reason to suck CPU cycles all over the internet just to make your message prettier. I understand that the functions of email and browser seem to be merging. However, this is what I would consider a bad trend. It stems from folks like Microsoft who have convinced people, for example, that spreadsheets function perfectly well as databases. They don't, but that doesn't stop people from using Excel to keep their mailing lists. Of course, opinions like mine won't stop the merging of browsing and reading email. Ah well. Paul -- Paul M. Foster I agree. Obviously the proliferation of free webmail accounts like Live, GMail, Yahoo, etc have had a large impact on the way people consider email. I actually had a friend ask me what this POP3 email thing was, and what made it different from normal email, and it took me a moment to realise his understanding of normal was one of these webmail services available through the browser! It is nice to be able to format emails nicely, but you have to realise when to restrain yourself. I've been getting loads of emails from Adobe lately that haven't been formatted well at all, and appear awfully in my email client (Evolution, which I consider to be a very good client) until I download all the images they've used as backgrounds. It's situations like this that give HTML emails an awful name. One feature I've seen in some mailing list software is the ability to track how people prefer their email formatted, so that you only send HTML emails to those that want them, and text emails to those who prefer that method. It's the best of both worlds I reckon, and one that is likely to upset as few people as possible; at the worst they might receive one email in a format they don't want before they change their preferences. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] HTML in emails
On Sun, Jul 04, 2010 at 11:44:29PM +0100, Ashley Sheridan wrote: snip It is nice to be able to format emails nicely, but you have to realise when to restrain yourself. I've been getting loads of emails from Adobe lately that haven't been formatted well at all, and appear awfully in my email client (Evolution, which I consider to be a very good client) until I download all the images they've used as backgrounds. It's situations like this that give HTML emails an awful name. Isn't this a popular exploit these days? I don't really watch these things since I use Linux and view mail as straight text. But isn't there some current exploit where images which can be downloaded as part of an email actually contain code which can be used to sniff your system or somesuch? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
