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
