[HN Gopher] Why does email development have to suck? - Explainin...
___________________________________________________________________
Why does email development have to suck? - Explaining all the
<tr>'s and <td>'s
Author : hdodov
Score : 125 points
Date : 2023-08-17 16:03 UTC (1 days ago)
(HTM) web link (dodov.dev)
(TXT) w3m dump (dodov.dev)
| alentred wrote:
| While we are at it, what is the most surefire way to include
| images into email? How do I make sure that simple images, like
| logos, are shown in most common email clients?
| gabereiser wrote:
| base64 encoded <img src"<base64>">...
|
| It's the only way to ensure you're logo is forwarded to every
| single CC and BCC.
|
| _edit_ I take it all back, gmail strips them. I guess as an
| attachement and then referenced like <img src="cid:<id>">
| javitury wrote:
| Gmail does not support base64 images according to caniemail
|
| https://www.caniemail.com/features/image-base64/
|
| The most reliable method is to attach a png image to the
| email and reference it from the body using `<img
| src="cid:insert_cid_ref_here" `
| SAI_Peregrinus wrote:
| You don't. Common email clients block images by default,
| because advertisers used them for tracking.
|
| Or you make ASCII art of the logo.
| chungy wrote:
| Or you include a base64-encoded version of the image. Doing
| it in-line in HTML should work; I believe <img> tags can also
| reference an email attachment containing the image (email
| attachments are base64-encoded anyway...).
| hdodov wrote:
| When I first got introduced to email development, I remember I
| wanted to throw myself off a cliff. I couldn't believe how
| nonsensical everything was. I kept track of everything in a
| little text document, which I've now turned into a post.
|
| If you happen to be starting out with emails, I hope this can get
| you up to speed with exactly how everything is fucked. And if
| you're an Outlook survivor, I hope you'll find something you can
| relate to...
| mdgrech23 wrote:
| For the most part you can kind of have header and a footer
| which you reuse across all email and then just more or less
| text in the middle. Maybe an image every once in a while. If
| you can get business partners to agree to that I've found that
| to be an ideal middle ground.
| scrollaway wrote:
| Since you mention MJML: I wrote a little tool called mjmgr
| which was meant to be a prototype of a MJML email manager for a
| bunch of providers. So that you can keep the source code of the
| MJML email checked in, but deploy it as compiled templates
| across various email template providers.
|
| https://github.com/siguelaola/mjmgr
|
| I only really did sendgrid and mailgun, but as a POC it worked
| well. Just putting this out there because it's useful but I
| don't touch it much anymore.
| shortformblog wrote:
| This is cool! My CMS (Craft CMS) has an MJML plugin as well
| as some good inlining plugins, making it possible to build
| emails using the CMS as the base. My goal was to have a
| system that put email templating on equal ground to content
| display, and MJML was a really key part of that. Love seeing
| the cool ideas MJML has inspired in the ecosystem.
| dsr_ wrote:
| If you were thinking more clearly, you would want to throw
| whoever asked for "email development" off a cliff.
|
| People choose the wrong targets for violence.
| nottheengineer wrote:
| As an ABAP developer, I thought "that doesn't sound too bad".
|
| I definitely need to get out of there before my brain rots
| further.
|
| And for anyone curious:
| https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-us/a...
| Those are the keywords, about a third of that list is obsolete
| and you usually need multiple of them to make a valid statement.
| And that's just the tip of the iceberg.
| fdgjgbdfhgb wrote:
| Hah, that takes me back!! MY first internship was at SAP and I
| foolishly didn't even ask which technologies I would work
| with... ABAP is literally the worst lol. This was 2018 btw
| hyperman1 wrote:
| I love how the numbers 1 to 7 are keywords and 8 and 9 aren't.
| cosmodisk wrote:
| That's why I never saw any SAP job paying peanuts...
| amelius wrote:
| If you think sending email is hard, you haven't tried sending
| whatsapp messages.
| internet101010 wrote:
| How do I make gmail automatically scan every incoming email for
| "unsubscribe" links and click them?
| epolanski wrote:
| You can't get the end result by automation alone but you could
| automate half of it.
|
| 1) Use AppScript from google to find those.
|
| 2) Save all the links.
|
| 3) Go through them manually (because each service will want you
| to confirm you did not click by mistake).
| rahkiin wrote:
| Virus scanners and other tools like google will fetch any
| urls in emails to check their target. So having a direct
| unsubscribe action behind GET of a link breaks your email
| list as Gmail will unsubscribe everyone
| chungy wrote:
| Is this why they always have a confirm button? That's been
| a pet-peeve annoyance of mine.
| JimDabell wrote:
| It's a basic part of HTTP. If you follow a link, that's a
| GET request. GET requests are supposed to be safe. A user
| may not have initiated the action if it's a GET. If you
| want something that implies "yes, the user made an
| intentional choice to take action", then use another
| verb, like POST.
| pvorb wrote:
| There must be some additional logic behind that, because I
| see this regularly behind GET requests and I'm not being
| unsubscribed from everything.
| ndriscoll wrote:
| Alternatively, make a filter that applies a label and skips
| inbox. Occasionally, open the label, select all, and Report
| Spam.
| mint2 wrote:
| So when provide.autoinsurance@fhsbsh.com sends you an email
| that consists of nonsense text, a sketchy link, and an
| unsubscribe link you want to automatically follow the
| unsubscribe link?
|
| Looking at my spam folder, how about hitting the unsubscribe
| link in email from the alias "100_free_spins" sent from
| top1.povertytrap.site? There's an unsubscribe button at the
| bottom.
|
| I'm slightly impressed how that spcammer is using the email
| "povertytrap" but I assume it's just by chance they hacked that
| domain to send spam.
| shortformblog wrote:
| As someone who has custom-coded newsletters over the years, I
| understand the other comments here, but to me, email deserves to
| have room as a creative medium with visual elements, because
| visuals are often part of the storytelling.
|
| MJML has been a real shot in the arm from that standpoint, as it
| greatly simplified what was possible.
| pvorb wrote:
| Wouldn't most of these pains go away if you simply could include
| style _tags_ (not attributes) in the body? I 've always wondered
| why it's possible to include script tags pretty much everywhere
| but not style tags.
| hdodov wrote:
| Nope, that doesn't work as well. I tested it before finishing
| up the article a few days ago. If you put `<style>` in the
| `<body>`, it gets removed when the email is forwarded and it
| still looks like shit.
| pvorb wrote:
| That's why I said "if you could". I know it's not valid HTML.
| For some reason, style tags are only allowed inside the
| <head/>. My point was that I find it strange that HTML in
| general has this limit and that script tags are allowed in
| the <body/> as well.
| JohnFen wrote:
| > An email is essentially just an HTML document, like a web page,
| except it's visualized in an email client, rather than a web
| browser. However, both are capable of rendering, which is the
| process of turning HTML code into text, rectangles, and images,
| i.e. the visualization of the content.
|
| No, it is not. An email is a text document. That document might
| be HTML, but it doesn't have to be. And if such email is sent to
| me, the HTML is never rendered because I don't allow it.
|
| The only time I get HTML through email is when it's spam or
| commercial email, and screw them. Sometimes a real person will
| neglect to turn HTML off in their mail client, but even then,
| they aren't really using HTML or are using it for trivial things,
| so not allowing HTML only makes the garbage email hard to read.
| legitster wrote:
| > The only time I get HTML through email is when it's spam or
| commercial email, and screw them.
|
| Heaven help any friends/coworkers who tried to send you an
| email with color, embedded pictures, or bullet point lists.
| jgalt212 wrote:
| I assume your preferred browser is lynx, or maybe you just pipe
| curl into emacs?
| mr_mitm wrote:
| I use mutt and unfortunately in the corporate world you can't
| just ignore HTML or even HTML only mails. I pipe them to
| elinks, works 99.9% of the time easily.
| JohnFen wrote:
| That may be the case, but that still doesn't make HTML a
| part of email itself. It's using email to send/receive
| HTML.
| JimDabell wrote:
| The ability to use formats other than plain text have
| been a standard part of email since 1992:
|
| https://datatracker.ietf.org/doc/html/rfc1341
|
| HTML email is not merely an HTML file sent _by_ email -
| it _is_ the email.
| JohnFen wrote:
| Umm, no? I don't understand your point...
| jgalt212 wrote:
| > And if such email is sent to me, the HTML is never
| rendered because I don't allow it.
|
| This part feels like you're being difficult for the sake of
| being difficult. I agree that presentation >> content for
| many emails, but stuff like bolding, monospace, and inline
| images is genuinely useful in emails.
| thiht wrote:
| Once again the stereotypical HN comment of << no this is all
| wrong, my way is right >>
|
| For all communications that matter today, email is HTML. No one
| cares that JohnFen choses to not render them as HTML.
| SoftTalker wrote:
| Whast about text messages? We must have HTML in text message
| too, I think, so that we can use them more effectively.
| thiht wrote:
| Not necessarily HTML, but yeah? Why not?
| ttepasse wrote:
| I believe the 20 year old MMS standard supported in
| principle a XHTML subset via WAP.
| tomjen3 wrote:
| You will hate me then. I have recently started to embrace html
| emails. I needed to book a room for a series of events and
| color highlightinged the available options.
|
| Another time I needed to provide a summary of options for fees
| and that got added as a table with colours to indicate fees,
| profits and losses.
|
| And I don't care at all if it meant that it could not be read
| in mutt. At some point we have to march forward or we will
| never progress at all.
| happytoexplain wrote:
| I agree with the OP - it's not misleading to say an email is
| "essentially" HTML, regardless of whether the client supports
| parsing out the markup. Browsers too will happily render an
| HTML file consisting only of the string "hello world", and yet
| it's still a web page.
| cypressious wrote:
| Last time I had to deal with emails, I've used https://mjml.io/
| and was very happy with it. You can version the templates,
| compile them as part of your build pipeline and it seems to do
| produce very _adequate_ HTML full of tables that looks good on
| all clients that we tested.
| andrei_says_ wrote:
| How's responsive design with mjml?
|
| Creating precise multi column responsive designs that work both
| in outlook and sane email clients is a nightmare.
| marpstar wrote:
| I've been using MJML for a few years now, I can't imagine
| even trying to build a responsive email without it. I don't
| even have to think about it.
|
| You may still have to slice images, but it's grid/column
| support has worked great for me.
| NoraCodes wrote:
| I don't understand the insistence on building "beautiful" emails.
| I'm not the kind of person to insist on text-only e-mail, but I
| do think it's ridiculous to spend lots of time and money making
| e-mails that look like fully-fledged Web documents.
|
| Either your message _does_ have some useful information for the
| reader, in which case say that and then get out of my way, or it
| _doesn 't_, in which case you're a spammer. There is no third
| option.
| oliwarner wrote:
| It's weird that your can't conceive of _useful information_
| that benefits from HTML elements (images, actual tables, links)
| and layout design to make it more readable. In pretty much the
| same way a web page does. I benefit from this as the reader. I
| want it.
|
| That non-existent third option is critical for good
| communication.
| thfuran wrote:
| >There is no third option
|
| But only because the best way to accomplish the first option is
| to be cognizant of the way the information is presented so that
| it can be most effectively conveyed. And that can involve
| paying attention to layout and color and possibly including
| some graphics.
| blowski wrote:
| Perhaps that is your response, but it's not true of everybody.
| I've done a lot of experiments with different types of email,
| and beautiful emails always get significantly better response
| rates.
| cosmodisk wrote:
| Beautiful emails are easy. Emails with well conveyed and
| informative text- much much harder.
| NoraCodes wrote:
| Ah. I think the difference is that when I send emails, I do
| so to communicate information, rather than to elicit people
| to buy a product.
| yakshaving_jgt wrote:
| Are you relying on the user's email client to convert
| plaintext URIs into interactive hyperlinks in transactional
| mail?
| NoraCodes wrote:
| No. As I said, I'm not advocating for plain text only
| emails, just simple ones.
| LastTrain wrote:
| So, spam.
| yakshaving_jgt wrote:
| Is transactional email spam?
| LastTrain wrote:
| Well, that depends. Is it something I need to see? Did I
| proactively ask for it, or did I neglect to opt out? Etc,
| etc. If you are having to measure response rate, and it
| doesn't involve an emergency alert or some such, it is
| probably spam.
| yakshaving_jgt wrote:
| Transactional mail is not marketing mail.
|
| It's typically a notification in response to an action
| you initiated on some web application.
|
| https://postmarkapp.com/blog/what-is-transactional-email-
| and...
| LastTrain wrote:
| OK. So what, I'm not going to complete my password reset
| notification because the page isn't beautiful? If you are
| tracking response rates it is because people aren't
| expecting an email, because they didn't ask for one (i.e.
| it isn't a password reset notification). GP is right - I
| want information I /need/ to be in an email in a succinct
| format, and I don't want emails I don't need.
| yakshaving_jgt wrote:
| 1. Yes, normal people who don't read HN have less trust
| in a plaintext email.
|
| 2. Yes, abandonment will be higher if the user can't
| click the password reset link in the email.
| marssaxman wrote:
| > less trust in a plaintext email
|
| What a remarkable idea! "HTML mail = useless bullshit" is
| such a strong correlation in my mind that it had never
| occurred to me other people might see it the opposite
| way.
| yakshaving_jgt wrote:
| I can't tell if this is sarcasm.
|
| Personally, I've been using mutt in the terminal as my
| primary email client for several years, and I absolutely
| prefer plaintext email.
|
| But this isn't about me. Nor is it about any other
| computer nerd here clutching their pearls over HTML
| email. The reality is that users of web applications --
| the kind that probably a significant proportion of HN
| readers develop to earn a living -- expect HTML
| transactional email.
|
| It's table stakes. That's just the reality.
| marssaxman wrote:
| Not sarcasm at all.
| seba_dos1 wrote:
| How much sense does it make to measure and discuss
| response rates for transactional mails though?
| blowski wrote:
| Low response rates are used as a spam signal by major
| email providers, whatever the type of email.
| seba_dos1 wrote:
| How does that make any sense when those are often sent
| from no-reply addresses that are routed nowhere?
| yakshaving_jgt wrote:
| I think response rate is meant more generally in this
| context. It doesn't necessarily literally mean an email
| in response. I think more typically it means the
| recipient following the _call to action_ link in the
| email.
| thrashh wrote:
| Some of us like beautiful things.
| NoraCodes wrote:
| Fair enough. I fully support hobbyists making email clients
| do fun tricks.
| epolanski wrote:
| There's no chance a business today can work with plain text
| documents at scale.
|
| Virtually all email clients support html since a decade and the
| expectations user have todays have changed.
|
| To put it differently, it looks unprofessional.
| [deleted]
| legitster wrote:
| To add to this, plaintext emails are a much bigger avenue for
| phishing, MITM attacks, and scammers.
|
| Especially when dealing with technology, consistent branding
| actually has an important safety factor for consumers.
| dsr_ wrote:
| There is nothing in the average internal email that requires
| HTML, much less CSS.
|
| There is nothing in the average external email that requires
| HTML or CSS.
|
| There is no useful content in any email that requires
| JavaScript.
|
| "looks unprofessional" is cultural, and of the same
| significance as green vs blue text bubbles in your SMS
| messaging system.
| unethical_ban wrote:
| Some people _want_ marketing emails. Did you know some
| people sign up for them voluntarily? They 're like
| newsletters of old, but electronic. And it arrives in your
| mailbox, ready to be rendered!
|
| Furthermore, many emails are direct links to status pages
| of orders, account verifications, password resets, and so
| on, which are definitely most functional as a clickable
| URL.
| yakshaving_jgt wrote:
| This is an absurdly wrong, yet characteristically HN take.
|
| Transactional mail typically requires some hyperlink for
| the average user.
| dsr_ wrote:
| No, it doesn't. Email is a great feedback medium.
|
| "If you want to continue with the subscription, reply
| with the word YES on a line by itself. You can put
| comments on other lines and we will read them."
|
| do-not-reply@marketing.com is one of the stupid
| innovations by people who can't automate their email.
| Transactional email gets handled by robots and fed into a
| ticketing system when it goes awry.
|
| Treat your customers like customers, not consumers.
| yakshaving_jgt wrote:
| Why would transactional mail come from do-not-
| reply@marketing.com?
|
| Transactional mail is not marketing mail.
|
| It's not a good look to declare things as stupid when you
| aren't sure what the discussion is about.
| JimDabell wrote:
| Transactional emails are things like reset password
| emails. You're really going to build your reset password
| functionality by having people email their new password
| to you?
| corporage wrote:
| [flagged]
| thiht wrote:
| Now you need to deal with << yes >>, << Yes >>, << YES.
| >>, HTML wrapping, user signatures, dangling spaces, etc.
|
| I've worked with a system that let users order domain
| names by email and it was a nightmare to maintain. Don't
| EVER build a system that relies on reading and parsing
| emails sent by users, it WILL fail horribly.
| toast0 wrote:
| You can certainly put urls into a text/plain email. It
| helps if your urls aren't terribly long and don't have
| characters that are questionable in urls.
|
| w3c suggests surrounding them with angle brackets [1],
| but I can't find a source that makes more than a
| suggestion. By reports, some mail user agents, and some
| users will include the trailing > in the url they provide
| to their web user-agent, so that's something to consider
| and make sure the destination of the link can handle.
|
| Putting links on a line by themselves works well too.
|
| If you don't know what a user prefers, it makes sense to
| send a text/plain with links as I've described, as well
| as a text/html with links in tags, because tagged links
| may be friendlier to some users and some mail user-agents
| are tragically bad at their job.
|
| [1] https://www.w3.org/Addressing/URL/5.1_Wrappers.html
| yakshaving_jgt wrote:
| Yes, you _can_ put them in there, but then you 're
| relying on the recipient's client to turn that plaintext
| url into a link the recipient can actually click on, as
| opposed to having to copy and paste the url into their
| browser address bar.
|
| Right? Or do I have something wrong?
| toast0 wrote:
| Yeah, but most email clients do linkify urls in
| text/plain emails. Heck, an awful lot of email clients
| linkify urls in text/html emails.
| maw wrote:
| I read the first paragraph and it seemed about right to me: there
| are many standards at play and many implementations of varying
| quality; lots of folklore, possibly false, makes the rounds and
| some of the more important providers are, by reputation at least,
| known to be difficult; one has to deal with issues of scale and
| stability and atomicity and reliability; there's spam.
|
| In other words, no shortage of interesting if often maddening
| problems to work on here.
|
| Then I saw that this was all just about formatting HTML mail.
|
| Oh.
| rossdavidh wrote:
| "So if you want a reasonable portion of users to see your email
| as intended, let's say 95%, you have to stick to the most basic
| features of HTML and CSS..."
|
| Or, you know, you could just SEND TEXT.
| thiht wrote:
| Wow so clever. That totally solves the need to show logos and
| images, colors, formatting, centering things, making things
| visually appealing, etc.
|
| Can you conceive your needs and your basic understanding of an
| issue is not, in fact, the whole thing?
| rossdavidh wrote:
| There is no "need" to show logos and images, etc. etc. In
| fact, far from making things visually appealing, all of that
| tells me (and most other people) "this is an email which I
| can safely delete without reading", precisely because real
| people not trying to sell you something rarely do that.
| thiht wrote:
| > There is no "need" to show logos and images, etc.
|
| ...yes, there is. Email is a communication medium, and like
| in all written communication, an image can be useful. Do I
| really need to explain that images are useful in human
| communication?
|
| > and most other people
|
| According to you I guess?
| hyperman1 wrote:
| I believe there is a human need for images, but also that
| only text is still capable of creating a lot more than
| you'd expect.
|
| When email was monospace text, the whole ASCII art thing
| was glorious. People added ANSI escape codes and gave us
| e.g. the glowing, blinking Chernobyl cows, in plain email.
| I also remember seeing a giant ASCII art 'high-res' nude
| somewhere, intended to be printed on a matrix printer, on 5
| or 6 pages of continuous paper (Long-legged she was.)
|
| Writing this, I wonder what desperate marketing attention
| whores would produce with ASCII art.
| globalreset wrote:
| Text. Just use damn text. Nobody wants to look at your logo. Why
| biz people have to ruin everything.
| mr_mitm wrote:
| I'm pleasantly surprised that amazon actually sends plain text
| emails. Pretty much every other corporation insists on HTML
| mails.
| bilalq wrote:
| I just checked, and they don't. It's certainly plain looking
| and without fancy styling/formatting, but they do send
| content-type text/html. The links and tracking pixel images
| are why they need HTML, I guess.
| chungy wrote:
| There's an account setting somewhere to always send plain
| text emails and do not send HTML. I don't know where the
| setting is, I enabled it many years ago. Been happy with
| that.
| m463 wrote:
| This appears to be untrue. I looked at all the amazon
| emails in my inbox and they are all:
| Content-Type: text/plain; charset=utf-8 Content-
| Transfer-Encoding: quoted-printable
| bilalq wrote:
| Did you actually scroll through all the way? Some emails
| send both plain text and HTML. I looked through mine and
| indeed saw text/html for most Amazon emails (including
| AWS). Some AWS emails like ACM cert renewals were
| text/plain. Though like someone else said here, you may
| have changed a setting in your account preferences. The
| default is still HTML.
| ------=_Part_4161549_398020174.1685704999675
| Content-Type: text/html; charset=utf-8 Content-
| Transfer-Encoding: 7bit
| m463 wrote:
| I have zero html attachments.
|
| (These emails are not marketing emails which I don't get,
| they all relate to orders and shipping)
| JimDabell wrote:
| They aren't talking about HTML attachments. HTML email is
| typically sent as a multipart/alternative email with one
| text/plain component and one text/html component. An
| email with attachments is a multipart/mixed email.
| mr_mitm wrote:
| Mine have the text/plain header. I must have checked that
| setting like the sibling commenter said.
| jimmaswell wrote:
| Tracking pixel in an email? I thought nobody had done that
| in decades because major webmail clients pre-cache all
| images to prevent leaking user IP etc.
| bilalq wrote:
| I don't know about decades. It's true that a lot of
| clients do that nowadays, but they're definitely still
| used.
| captn3m0 wrote:
| The clients also need to focus on this. Apple Mail on iOS uses
| plain text variant to show snippets, but if you try to expand
| the email, it only supports HTML, without a fallback to plain
| text. This is often the case on slow internet.
| fanf2 wrote:
| That isn't true: Apple Mail is perfectly capable of showing
| plain-text-only messages.
| joaonmatos wrote:
| The post you're responding to probably meant in the event
| of alternative HTML+text emails. Obviously if the email is
| plain text-only it won't invent HTML to show the user...
| graypegg wrote:
| Sticker Mule sends marketing newsletter emails in plain text
| ONLY. I love it. They're just:
|
| > Hey ${name},
|
| > Our custom holographic stickers are on for on for ${deal}.
|
| And that's it. I bet they have awesome deliverability because
| it's... just email.
| ryanwaggoner wrote:
| Approximately no one outside of HN only wants text emails.
|
| And the argument that anything beyond plain text is a waste and
| ruins everything applies to literally every single medium out
| there where the written word is conveyed: webpages, magazines,
| printed flyers, books, etc. It's laughable to think that all
| formatting of any kind beyond ASCII is a waste.
|
| If it were up to HN readers, the entire world would be so ugly
| and boring.
| hattmall wrote:
| Ultimately it depends on if it facilities the delivery of
| information. In most cases excessive styling does the
| opposite.
| postalrat wrote:
| Why doesn't HN or reddit or most social media format messages
| in html like email? Email has been doing it for years. People
| would love it! Images, colors, tables, etc in every message!
|
| And why not in text messages? Its 2023 guys.
| Yizahi wrote:
| If only it was a simple logo. My HRs send emails with a full
| blown wallpaper on top, which stretches the inbox on a smaller
| screen so much that horizontal scroll appears, and text below
| it also overflows. Or when I disabple dynamic content, then
| they manage to create links inside the graphical buttons with
| no alt text, invisible without the picture. And these are
| people whose main job are emails. Sigh...
| legitster wrote:
| Ironically, plain text emails actually do better for us - the
| problem is that plaintext emails are often _more likely_ to be
| caught up by spam filters.
| rossdavidh wrote:
| The data I've seen suggests the opposite?
| legitster wrote:
| All of our internal tests have confirmed this, and even the
| email providers have more or less confirmed the same thing:
| https://blog.hubspot.com/marketing/plain-text-vs-html-
| emails...
| eastern wrote:
| That's HTML emails _pretending_ to be plain text.
|
| Meaning the 'plain' text is Html-formatted to look plain
| and there are tracker links and probably tracking pixels
| too.
|
| Real plain text should be just like something a human
| being typed.
|
| Also, ignoring the general scamminess of hubspot, the
| linked article says html mail is MORE likely to be
| flagged as commercial. The article, in fact, is entirely
| pro plain text.
| legitster wrote:
| As someone who is very familiar with designing and developing
| emails, I think it's actually a pretty happy medium between
| format and freedom. Not everything needs to be a responsive,
| javascript-riddled design with interactivity. 600px-wide text
| with graphics does the job. (The irony is that often plaintext
| emails perform better)
|
| The problem is the lack of consistency between email clients.
| It's crazy how each email client has a completely different and
| crazy idea for how to interpret basic HTML. And heaven help you
| if you have a brand designer breathing down your neck about dark
| mode...
| Finnucane wrote:
| I am involved in ebook production, so I can somewhat sympathize,
| in that ebook reading systems tend to be way behind browsers in
| what code they support.
|
| On the other hand, complex html in emails is mainly for the
| benefit of the businesses sending you the email, for their
| commercial purposes, i.e., mostly spam. It rarely has anything to
| do with communicating useful content to the receiver. If the
| email is too complex for the client, maybe it shouldn't be in the
| email.
___________________________________________________________________
(page generated 2023-08-18 23:02 UTC)