[HN Gopher] Caniemail.com - like caniuse but for email content
___________________________________________________________________
Caniemail.com - like caniuse but for email content
Author : fagnerbrack
Score : 701 points
Date : 2024-05-06 23:03 UTC (23 hours ago)
(HTM) web link (www.caniemail.com)
(TXT) w3m dump (www.caniemail.com)
| whoisthemachine wrote:
| The two most popular clients, Gmail and Outlook, are ranked at 25
| and 41 (the bottom) respectively.
| jolmg wrote:
| That's reminiscent of IE, being the most popular and
| underfeatured.
| dylan604 wrote:
| Most popular _only_ because it was included with the OS and
| most IT departments did not allow use of other browsers. Just
| because it was the most installed does not make it the most
| popular. There was an old saying, "Internet Explorer: the
| most used browser to download another browser."
| lolinder wrote:
| That was a saying later in the game and among techies.
| Website usage stats indicate that in 2007 a solid 67% of
| people were using IE, and that didn't drop below a majority
| of usage until mid-2010.
|
| https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers
| dylan604 wrote:
| I remember hearing stats about the continued high numbers
| for IE, but a lot of those numbers were attributed to
| pirated copies of XP being used in China. Maybe it was
| why IE6 seemed to hang around as high as it was. Just a
| clarification of the numbers that I found interesting.
| JimDabell wrote:
| A quarter of Chinese web surfers were using Internet
| Explorer 6 twelve years after it was released. At that
| time, most online banking in China only supported
| Internet Explorer and derivatives.
|
| https://www.techinasia.com/chrome-firefox-chinese-online-
| ban...
| wongarsu wrote:
| IE 4 and 5 were pretty good. ActiveDesktop was pretty cool.
| XMLHttpRequest turned out to be revolutionary.
|
| It was only after triple whammy of Netscape being unable to
| further compete, the dotcom crash and the antitrust suit
| against Microsoft's integration between Windows and IE that
| IE got deprioritized by MS and slowly turned into the
| underfeatured mess every developer hated.
| dylan604 wrote:
| IE for Mac was atrocious. Woz has some interesting
| thoughts about it in his book iWoz.
| kalleboo wrote:
| Although Netscape was even worse (if you resized the
| window, it reloaded the whole page), and IE for Mac at
| the time had the best CSS support out of any browser (it
| was a different renderer from IE Win). I did a lot of
| bouncing between browsers (Netscape/IE/iCab/Opera) back
| then until Mozilla came out and wiped everything else
| out.
| darkwater wrote:
| This take is pretty revisionist. IE4 wasn't good,
| ActiveDesktop and ActiveX were either useless or actually
| bad. AJAX was probably the only good thing out of IE, and
| I would not dare to call it an happy accident but I'm
| tempted
| gertop wrote:
| You're being a revisionist. The claim that it wasn't
| popular is just dumb. For years it was simply superior to
| all other browsers (both technologically and users liking
| it).
| jolmg wrote:
| > Just because it was the most installed does not make it
| the most popular.
|
| It kind of does:
|
| > popular - prevailing among the people generally ---
| https://www.dictionary.com/browse/popular
|
| I didn't mean to say most preferred.
| dylan604 wrote:
| It's not a like it's a vote. Most people didn't choose
| it. They had it because their corp uses Windows, and
| Windows came with IE, and IT did not allow other
| browsers.
| jolmg wrote:
| I'm saying I agree with you. It's just that we're using
| different definitions of "popular".
| tgv wrote:
| When I look at the features gmail doesn't support, I see things
| like "display: none", animation, and other kinds of css which
| arguably shouldn't be part of an email. The basics are there,
| so that makes high ranking not necessarily a good target.
| decremental wrote:
| I wish there was something like BrowserStack but you send a test
| email and it shows you how it renders on tons of different email
| clients on various platforms. It wouldn't work for web-based
| email like Gmail but it would still be useful.
| benmanns wrote:
| Good news, https://www.litmus.com/ is exactly this, and does
| work for Gmail.
| solardev wrote:
| And Mailchimp has a built-in integration:
| https://mailchimp.com/help/test-with-inbox-preview/
| rsoto wrote:
| Best tool I've found is Testi@[1]. It's really affordable and
| it supports basically everything out there.
|
| * Disclaimer: Not affiliated, just a happy customer.
|
| - [1] https://testi.at/
| shortformblog wrote:
| This looks cool, thank you for sharing!
| iamacyborg wrote:
| There are quite a few tools that literally do exactly what
| you're asking for.
| rrrx3 wrote:
| Litmus, testi@, Email on Acid, InboxMonster, SendForensics,
| Email Preview Services...
|
| Most if not all also support stuff like deliverability, DMARC
| testing, Analytics, Accessibility, as well as web-based render
| testing. I think rendering engine wise, Testi@ has the largest
| device/platform coverage. Or at least last I checked.
| Julesman wrote:
| I think it would be more useful to list the few CSS properties
| that all email clients do recognize. I don't mean to be flippant.
| I'm serious.
|
| CanIEmail? The answer is generally no.
| SigmundurM wrote:
| If you go to this page: https://www.caniemail.com/clients/
|
| and select "check all", it'll show you the features that are
| supported by all the email clients, and separately, which
| features have mixed support.
|
| These appear to be the few features supported by all clients:
|
| - border-collapse
|
| - font shorthand
|
| - list-style-type
|
| - cm unit
|
| - em unit
|
| - ex unit
|
| - in unit
|
| - mm unit
|
| - pc unit
|
| - % unit
|
| - pt unit
|
| - px unit
|
| - vertical-align
|
| - <del> element
|
| - <div> element
|
| - <h1> to <h6> elements
|
| - <hr> element
|
| - <img> element
|
| - <p> element
|
| - <pre> element
|
| - <span> element
|
| - <strong> element
|
| - <table> element
|
| - valign attribute
|
| - JPG image format
|
| - PNG image format
| kylehotchkiss wrote:
| Outlook supporting padding in 2003 then not really supporting it
| in any follow up client sounds just about right for the dumpster
| fire experience that is trying to make an email look nice.
| userbinator wrote:
| The lower the score, the better. I know many who have a policy of
| "emails must be in plaintext only, with no attachments unless
| agreed to in advance; everything else gets deleted
| automatically."
| shortformblog wrote:
| Expand your group of people, because you clearly don't know
| enough people.
| dylan604 wrote:
| I disagree. I wish I had more people that fit that filter.
| Email is broken and just a platform for spam. Even if it
| might be from someone that I purchased something from once or
| even regularly, if I did not select a check box to opt-in to
| receiving your email, it is spam.
|
| It's 2024. Emailing large file attachments is about as old
| and busted as FTP. There are so many other services to
| "share" large files. Attachment to email was such a kludgy
| hack in the first place just shows it was only the best worst
| idea waiting for better solutions. We have them now.
| shortformblog wrote:
| As someone who works very regularly in email, it really
| bugs me that every time I see a thread about this topic in
| Hacker News there seems to be this confirmation bias that
| this is how the average person uses email in the wild, and
| I'm just trying to make the point that "Hey, this is a
| strong minority viewpoint."
|
| I get that y'all don't like HTML email, but the fact of the
| matter is, that was a battle lost 25 years ago, and we need
| to figure out how to keep what we have working for people
| who don't even know how to set plaintext email.
|
| That's what this particular tool is for.
| croes wrote:
| There are valid reasons ro dislike HTML in emails
|
| https://lutrasecurity.com/en/articles/kobold-letters/
|
| And if we have to chose between bold letters or less
| malware, we should choose the latter.
| shortformblog wrote:
| By this standard, we should go back to Lynx, because rich
| web browsers are way more dangerous than this extreme
| edge case that this guy invented because he doesn't like
| HTML email.
| croes wrote:
| Guess why browser sandboxes, TLS and HTTPS exist?
|
| But the mail protocol is still the same.
| shortformblog wrote:
| That's a problem of failing to manage standards, not a
| problem with rich text in emails.
|
| Email is a standards backwater, but the solution is not
| to kneecap it.
| evantbyrne wrote:
| They said many of the people they know only accept plaintext,
| not all of them. We should interpret each other generously.
| shortformblog wrote:
| My point, though, is about confirmation bias. Most people
| don't know a lot of people who turn on plaintext email as a
| point of habit.
|
| It might seem like I'm criticizing the guy, but the thing
| is, there is a very real problem where people are looking
| at this from their own tech-forward perspective when this
| is a topic that affects many more people.
| userbinator wrote:
| For another interesting datapoint: Of the plaintext-only
| and plaintext-strongly-preferred people I know, somehow
| almost all of them are German. I wouldn't call them
| "tech-forward" either, as many of them are specialists in
| other fields.
|
| ...and before the inevitable questioning I'm going to
| receive: no, I'm not German, and I know more people who
| aren't, with similar plaintext preferences.
| pyrale wrote:
| I believe there are two points in the message :
|
| - A normative one : the less is supported, the better.
|
| - A descriptive one : many (not indicative of any share)
| of their relations actually do that.
|
| None of the points is telling about their relations,
| aside from, maybe, not having many friends in adtech.
| shortformblog wrote:
| "Many friends in adtech ..." try average people.
|
| HTML email would not be a thing if only adtech people
| used it, my man.
| pyrale wrote:
| Average people tend to use what they have, I have zero
| "average" friend trying to get more supported features
| than there currently are.
|
| And, by the way, most of my friends do not use html/CSS
| directly, or even indirectly use it besides some bold,
| coloring or the random photo attachment. Zero of them
| know caniemail.com, and, if they understood the point of
| it, zero of them would want or need it.
|
| Average people seeing html in their mail doesn't mean
| they have an opinion on it, or would want more of it if
| they were told honestly what it does and who abuses it.
| shortformblog wrote:
| This was not my point and you know it.
|
| There are two parts to how HTML email is used: Creation
| and consumption. The average person _consumes_ HTML
| email.
| pyrale wrote:
| > This was not my point and you know it.
|
| No, but that was mine in the message you answered to.
|
| > The average person consumes HTML email.
|
| And I'm not sure the average person cares about receiving
| elaborate emails with spy pixels and advanced use of CSS
| either.
| darkstar_16 wrote:
| generously and with a little more respect.
| lelanthran wrote:
| > They said many of the people they know only accept
| plaintext, not all of them.
|
| And parent said "you don't know _enough_ people ", not "you
| don't know _any_ people ".
| yyyk wrote:
| There's a good case for expanding slightly on plaintext. It's
| not just decorative - some usecases like Right-to-Left or lists
| or linked are helped by a little markup, and HTML is good
| enough.
|
| The problem is going overboard on CSS (maybe none should be
| allowed) or allowing any javascript at all. I can't recall any
| email security issue ever which is HTML only without any CSS or
| javascript.
| jimbobthrowawy wrote:
| I know at least two people who send emails where the HTML
| version is either blank or tells the recipient to stop using a
| bloated client, and the actual email content is in the
| plaintext fallback. I think I had to look at the email source
| in thunderbird to read them.
| FigurativeVoid wrote:
| I was using this for a feature I was working on last week.
|
| That's when I learned gmail doesn't support SVG???? That seems
| like a huge miss.
| peddling-brink wrote:
| SVG supports JavaScript.
| arjvik wrote:
| can't Gmail support SVG without javascript?
| cypherpunks01 wrote:
| Huh, I didn't really fully understand that about SVG. Thanks
| for the info.
|
| From what I'm reading, it seems that from inside an SVG
| script, you can call out to javascript functions of the
| parent page? That seems kinda surprising, I'm sure there are
| security policies around it, but it means that there are
| potential security and performance risks/considerations
| around hosting and serving SVG files that I didn't realize
| existed.
| barkbyte wrote:
| The comment you're replying to is misleading. SVG supports
| JavaScript but only if you load the SVG directly in your
| browser or inline it fully into the DOM. Using it as a
| normal image tag, by reference or with inlined data:, it's
| inert and harmless from a JavaScript perspective.
|
| However, for a long time browsers were susceptible to
| denial of service attacks from maliciously crafted XML
| files, which SVG could exploit. ("Million laughs"). This
| doesn't work in current versions but it might be a reason
| that SVGs are rejected.
| cypherpunks01 wrote:
| Ahh ok thanks for the clarification, that makes sense
| arp242 wrote:
| Rendering HTML emails in the browser is rather tricky
| business, because HTML/CSS isolation mechanisms are non-
| existent or come with a lot of caveats. You want to make
| sure your layout doesn't get screwed because of some
| bonkers HTML/CSS but you _also_ don 't want the intended
| layout of the email to be completely screwed.
|
| It's been a long while since I worked on this, but I was
| always very hesitant to make changes here, because we
| knew that our current thing worked for almost all
| customers, and you never knew what changes would break
| what.
|
| We dogfooded our own client, and at some point a change I
| made broke the automated SIDN (which manages .nl TLD)
| emails. I forgot what exactly it was, but they did some
| really weird stuff. You can't just shrug and say "oh
| well, that's just crazy, fix your emails" because people
| do need those emails and getting these types of
| organisations to take action is like moving a mountain.
| candiddevmike wrote:
| IMO, HTML was the worst thing that ever happened to email. Plain
| text content is the best content.
| astrodust wrote:
| It's easy to say this, but can you imagine the hodge-podge of
| proprietary garbage we'd have to deal with if you couldn't
| email a simple file attachment to someone?
| arjvik wrote:
| Can still do plain text with attachments... unless you expect
| that companies would move to emailing you HTML files of their
| message?
| candiddevmike wrote:
| I think that hodge podge (OneDrive, Google drive, Dropbox,
| etc) is what most people already use. "Simple file
| attachments" are an oxymoron these days--size/extension
| restrictions, spam scores, not to mention the hell of
| iterating over email.
| kiwijamo wrote:
| Depends on your use case. Sometimes I want to send a
| document and not have the receiver change it at their
| whims. E.g. quotes for jobs. Simple attachments are great
| for that. Also I find some people who aren't good with tech
| find attachments much easier to deal with. If I send a an
| attachment I am 100% confident the other person can open
| it. No so for sharing links etc.
| smsm42 wrote:
| I'm good with attachment when you need to send me a real
| document, but if the email text itself ends up being multi-
| megabyte blob because you absolutely must have your name in
| the signature in blue and italic, then I tend to frown upon
| this. Over decades of my work I probably sent thousands of
| emails, yet very rarely if ever I needed HTML capabilities,
| and pretty much never ones that go beyond very basic Markup
| formatting.
| hollerith wrote:
| I'm confused. How is HTML needed to attach a file (or to open
| the attachment)?
| astrodust wrote:
| MIME is needed, and with MIME, HTML is basically right
| there, so people are going to use it.
| hollerith wrote:
| HTML is not needed for attachments to work. If the
| government for example, banned all use of HTML in emails,
| people could still attach (non-HTML) files to emails the
| same way they do now. Therefore the comment I replied to,
| a defense of HTML in emails, is a bogus argument.
| anamexis wrote:
| The point is that attachments are needed to make HTML
| work. If you have attachments, you have HTML emails.
| throw0101c wrote:
| > _The point is that attachments are needed to make HTML
| work._
|
| They are not.
|
| MIME headers are helpful for telling MUAs what the
| content (type and/or disposition) of a message is, but
| there's nothing from stoping mail clients from just
| putting "raw" HTML in the body of an e-mail message
| without MIME.
| anamexis wrote:
| Yes, obviously you could just email HTML before MIME
| existed. That's not the point of the discussion at hand.
| hollerith wrote:
| This is bad logic, and so is your comment upthread, IMHO.
| astrodust wrote:
| "I think HTML sucks" is a bogus argument.
|
| Why not HTML? At least it isn't RTF or some wonky SGML
| evolutionary dead-end.
| hollerith wrote:
| A browser engine is necessary to render an HTML email,
| and browser engines have large attack surfaces -- and in
| general they are very complicated, which makes them
| difficult to reason about.
|
| Also, normies don't write HTML, but rather they depend on
| services (like Gmail) offered by corporations to
| transform their composition into HTML, which gives the
| corporations and avenue to track me or to try to persuade
| or influence me unless I want to respond by instructing
| my normie friend never to send me email.
|
| In general, HTML email brings the privacy and security
| problems of the web to email.
|
| Also, HTML makes email much harder to archive because an
| HTML document's legibility often depends on references
| (embedded in the HTML document) to files on the internet,
| and these references to online files tend to rot.
|
| Some of us are tired of web tech spreading its tentacles
| everywhere, especially to technologies like email that
| were already useful and mature before web tech started
| spreading to them.
| feikname wrote:
| Email attachments are defined through MIME and don't depend
| at all on HTML being available as a Content-Type. We could
| well have had another format and attachments together.
| djbusby wrote:
| Yea! `text/rtf` FTW!
| StableAlkyne wrote:
| That's a completely valid opinion, and I prefer plaintext as
| well
|
| But at this point, it's pretty clear that most non-technical
| people prefer emails with fancy text and graphics.
|
| Personally, I'm just glad that email is a flexible enough
| medium to allow that. It's better than the alternative, where
| people moved to some closed, proprietary protocol behind like
| 20 patents that allows the same thing.
|
| Is there any other common way we communicate over screens
| (aside from http) that has had the staying power of email for
| the general public? I think that's a testament to the sheer
| flexibility of it. The ugliness that people have contorted
| email into is a badge of honor IMO
| throw0101c wrote:
| > _But at this point, it 's pretty clear that most non-
| technical people prefer emails with fancy text and graphics._
|
| And what percentage of e-mails from people / human beings
| have those things?
|
| Certainly _marketing_ e-mails have fancy formats, but I 've
| rarely seen any person at a companies I've worked at use any
| kind of formatting: generally most folks hit reply and start
| typing with whatever the default is. Hardly any italics or
| bold, and forget about fixed width (for things like CLI
| commands in technical discussions).
|
| Heck, even Slack messages these styles are hardly used (on my
| current team I use them the most since I know that Markdown
| so it's easy for me to throw in some **, //, or `` in my
| typing flow, so I can highlight hostnames, CLI commands,
| _etc_ ).
| gertop wrote:
| Any e-commerce email showing you pictures of what you
| bought. People tend to find this convenient.
| wrycoder wrote:
| My wife has a fastmail account, but she uses her iMail
| client, so she can send inline photos with her email. Even
| FM can't do that yet.
| brongondwana wrote:
| Huh? You can paste if you have an image in your buffer,
| or drag-drop image files into an email in the Fastmail
| composer. I paste images into emails from screenshots
| almost every day.
|
| (I'll take this report as a "we need to make it clearer
| you can do this!")
| luckman212 wrote:
| Very happy Fastmail user here! Would love if images could
| be resized in the webapp. For some reason most
| screenshots I paste in get scaled up to a very unwieldy
| size.
| brongondwana wrote:
| Yeah, this is a common request :) I've added your prod to
| the "this is common" data
| Semaphor wrote:
| If plain text would support inline-images, I'd probably be
| okay with it. But it doesn't, so I'm not.
|
| I also generally prefer structured formatting to plain
| text.
| bregma wrote:
| They say an image is worth 1000 words.
|
| If you're sending emails with thousands of words you have
| probably chosen the wrong medium.
| Semaphor wrote:
| And sometimes 22 can already be too many.
| yau8edq12i wrote:
| You must be joking. I write and receive emails containing
| lists, hyperlinks, or blockquotes all the time. I don't
| need the last flexbox technology, but _some_ formatting is
| important.
| sbuk wrote:
| There is always Rich Text...
| throw0101c wrote:
| > _You must be joking. I write and receive emails
| containing lists, hyperlinks, or blockquotes all the
| time._
|
| I am not.
|
| I don't receive e-mails with fancy formatting at all. As
| for hyperlinks: I can paste a URL just fine without an <A
| HREF...> tag.
| dzhiurgis wrote:
| My guess SMS (and similar) (by volume) are more frequent than
| email.
|
| Anecdotally, I only get 2-3 actual human emails per _year_.
| Rest is transactional spam.
| kiwijamo wrote:
| That's you. My work emails receives 25-50 real human a day.
| I get less than that amount in SMS in an whole year on my
| work phone. Even my personal email is significantly more
| email than SMS. SMS is dying and replaced with messengers
| e.g. Teams, Signal, WhatsApp, Facebook Messenger etc.
| dzhiurgis wrote:
| No u.
|
| I understand if you are manager/owner you might be
| running comms via email. But internally all of that went
| to slack for good reason - lack of history is a feature,
| not a bug.
| carbonatom wrote:
| > I understand if you are manager/owner you might be
| running comms via email. But internally all of that went
| to slack for good reason - lack of history is a feature,
| not a bug.
|
| I am neither manager nor owner. Just another 1x engineer.
| 75% of my comms run over email. 25% over Jabber.
|
| Not every software company uses Slack!
| dzhiurgis wrote:
| Well you are not op to begin with and admit running a
| chat app which is has 99% chance of having better UX than
| email.
|
| Email is good for having common interface. In my case
| it's ~abused in 99% of cases.
|
| Also - you do not mention how much non-comms emails do
| you receive. While chat apps are fucky in terms of lock-
| in, lack of interop and tons of other things, lack of
| spam is nice.
| jordanreger wrote:
| Pretty much the only credit I'll give to Amazon is that they
| give the option to get plaintext emails. Doesn't mask the
| larger problems, but still a nice thing I wish was the norm.
| HelmetFigNewton wrote:
| Amazon deserves zero credit for anything regarding E-mail,
| because their "order confirmations" don't say WHAT YOU
| ORDERED.
|
| Mind-bogglingly stupid and annoying.
| derrikcurran wrote:
| I think that's because they don't want email providers,
| Gmail in particular, scraping for purchase history
| legitster wrote:
| > Plain text content is the best content.
|
| Hard disagree. Things like bolding text, adding pictures,
| changing colors, etc are very important for the emails I send.
| So _some_ amount of HTML is important to me.
| arp242 wrote:
| Lack of ability to distinguish between pre-formatted text and
| regular prose alone makes it a complete non-starter for most
| who aren't reading monospaced text in a terminal. I don't
| really like reading monospace text for prose (many people
| don't), and using proportional fonts means things that are
| supposed to be aligned will break (and if you restrict
| yourself to text only, you'll find yourself aligning things
| on occasion for tables or other content).
|
| I actually use plain text in FastMail because it's "better"
| than HTML (usually), but it's not good.
|
| Ability to send text/markdown natively would be pretty
| brilliant.
| brongondwana wrote:
| Ctrl-D to format the selected text as monospace in the
| Fastmail composer is pretty nice - I use it often for
| sending bits of log line or terminal output when writing up
| incidents or describing how to do something.
| HelmetFigNewton wrote:
| RTF would be fine, then.
| jeltz wrote:
| Yes, it would be. It is a pity HTML won over RTF.
| ktosobcy wrote:
| plain-text with some sort of simple formatting would be fine
| (markdown/asciidoc). We don't have to go overboard in the
| opposite direction...
| prmoustache wrote:
| Gemtext[1] would have been perfect and way enough while still
| being legible on a terminal. Italic and bold can be done via
| unicode, you don't need a markup language for that.
|
| [1] https://geminiprotocol.net/docs/gemtext.gmi
| cortesoft wrote:
| I like being able to email in line photos
| Dylan16807 wrote:
| Weird limited HTML isn't fun, but images, basic layout, and
| some amount of font control are all pretty important features.
| nox101 wrote:
| This reads me as "I prefer letters" or "I prefer fax"
|
| HTML is what non-techies want, or rather, they want to insert
| pictures and videos directly inline. They want to bold and
| highlight. They want bullet lists and numbered lists. They want
| to change fonts, make headlines, etc.. And they want it all to
| reflow for their device.
|
| I do to. I don't want to say in the 70s terminal. I get that
| lots of techies wish the world was still 80 column monochrome
| ASCII only but you're the exception.
| medstrom wrote:
| "80 column monochrome ASCII only"
|
| Mmm... Paradise
| nebulous1 wrote:
| I think the "techies" that you are referring to just see the
| issues with html email that the non-techies don't notice.
| Some of course just want things to be more like the 80-column
| monochrome that you mention, but for most it's not that
| extreme.
|
| I think HTML is way too complicated for email, and it would
| have been much better if they'd standardised on a version of
| markdown.
|
| That ship has sailed though, so we're stuck between using
| HTML or plain text.
| lelanthran wrote:
| > IMO, HTML was the worst thing that ever happened to email.
| Plain text content is the best content.
|
| Your first statement might be true (it's debatable). Your
| second is definitely false.
|
| Lets assume that HTML really was the worst thing that ever
| happened to email. Plain text content for email is _still_ not
| the best content.
|
| People want to:
|
| 1. Click on a link in the email, not fumble with copy and paste
| on their phone.
|
| 2. See decently formatted paragraphs and content with bold,
| italics and different font sizes for headings and paragraphs,
| not a wall of text.
|
| 3. See images in the email itself, not have to once again
| fumble around with copy and paste.
|
| 4. Correctly formatted bullet points, including sub-lists.
|
| For all of the above, _some_ sort of format is required. If we
| exclude HTML as a possibility, you 're _still_ going to have to
| need a format of some type, because the wall-o-text format is
| not a good UI.
| makapuf wrote:
| A subset of markdown (since you can use html in markdown)
| might be a good candidate.
| prmoustache wrote:
| I would have favored gemtext to avoid the temptation of re-
| adding html support to a dumbed down markdown flavor.
| ivanjermakov wrote:
| Regarding 1. it's up to the client to parse and highlight
| links in plain text.
| lelanthran wrote:
| > Regarding 1. it's up to the client to parse and highlight
| links in plain text.
|
| If the client is interpreting the content and then
| displaying its interpretation to the user, then it's not
| plain text anymore, is it? It's a format; in this case it's
| a poorly-specified, ad-hoc format and broken format[1] that
| is _worse_ than simply having a reduced ad-hoc HTML format.
|
| Just like HTML is "plain text" which is interpreted by the
| client and that interpretation is displayed to the user.
|
| [1] For example, what if the sender types in `You should go
| to http://ww.example.com, where "example" must be replaced
| with your company name`? Suddenly `www.example.com` has an
| unintended DDoS!
| sanitycheck wrote:
| I imagine example.com is either set up to be robust
| enough to withstand that, or they don't care if it goes
| down: https://www.iana.org/help/example-domains
|
| Oh interesting, I pasted a URL in plain text and a bit of
| code in HN turned it into a link you can click on. I
| think it's totally fine for email clients to do that too.
|
| The only thing I find redeeming about HTML email is the
| ability to have inline images so when I'm illustrating
| some sort of process to somebody I can do it more
| clearly. Without those, I'd create and send a proper
| document (I don't object to attachments), or publish the
| information on a wiki/blog/etc - but perhaps a those
| would be overall better approaches than a 'rich' email.
| ivanjermakov wrote:
| Fair, but url syntax is strictly defined in RFC 3986:
| https://datatracker.ietf.org/doc/html/rfc3986
| lelanthran wrote:
| What does that have to do with someone typing
| 'http://example.com' with the intention that that is not
| turned into a link?
| ktosobcy wrote:
| 1. all links are click-able at this point; what's more plain-
| text would force to provide just a link without all the
| tracking garbage 2. you can have paragraphs and headings...
| it's just a matter of structure - using html you can write a
| wall of text just fine 3. not sure if needed, besides you can
| attach images to plain text (though not inlining) or click-
| able links to external sources (at exact place) 4. still -
| easily do-able; it's a matter of particular editor tracking
| lists - for markdown editors it works just fine and in the
| end you virtually have a "plain text bullet list"... magic.
|
| The most contagious/problematic issue is (3) and inlining -
| as I said, it's possible to attach anything but the location
| is lost. Probably something simple like anchor (again,
| markdown linking comes to mind) to indicate placement would
| be just fine...
|
| (I loath html mails with passion...)
| lelanthran wrote:
| > 1. all links are click-able at this point; what's more
| plain-text would force to provide just a link without all
| the tracking garbage 2. you can have paragraphs and
| headings... it's just a matter of structure - using html
| you can write a wall of text just fine 3. not sure if
| needed, besides you can attach images to plain text (though
| not inlining) or click-able links to external sources (at
| exact place) 4. still - easily do-able; it's a matter of
| particular editor tracking lists - for markdown editors it
| works just fine and in the end you virtually have a "plain
| text bullet list"... magic.
|
| I think this comment displays the problems with plain text.
| I really couldn't have provided a better example.
|
| As regards the counterpoints:
|
| 1. All links are clickable
|
| Yes, and that's a _bug_. "http://www.example.com" _should
| not be a clickable line_. More to the point, it 's not
| plain text anymore if the user gets something that has been
| interpreted and then rendered by the software.
|
| 2. It's not obvious how this should be done, and how it
| should reflow. You yourself failed to manage this in your
| reply, which I consider a good argument for why plain text
| is a poor UI.
|
| 3. Who cares whether _you_ need it or not. The reality is
| that the clear majority of people _use it!_
|
| 4. Once again, if we're talking about a specific format
| that gets rendered into something readable, then it's not
| plain text anymore.
|
| I'm arguing against the GPs assertion that plain text is
| the best format, not that markdown is insufficient.
| rakoo wrote:
| > what's more plain-text would force to provide just a link
| without all the tracking garbage
|
| I'm glad that you never ever received any link to some
| derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn
| that hide the real link, but in the real world, that's how
| tracking is done. Plain text doesn't prevent anything.
|
| > not sure if needed, besides you can attach images to
| plain text (though not inlining) or click-able links to
| external sources (at exact place)
|
| For a Linux user, you can already build such a system
| yourself quite trivially by getting an FTP account,
| mounting it locally with curlftpfs, and then using SVN or
| CVS on the mounted filesystem. From Windows or Mac, this
| FTP account could be accessed through built-in software.
|
| You want to argue that plain text is better, but your
| arguments are that plain tex, are better _for you_. Don 't
| make the mistake to assume that your specific experience is
| a workable average.
| pquki4 wrote:
| > Don't make the mistake to assume that your specific
| experience is a workable average.
|
| Sadly many people on HN do exactly this, as seen in
| comments like
|
| "I don't use a phone and don't have a phone number, so I
| can't pass the anti-spam check of xx website. It is their
| fault"
|
| "Why do we need a UI for this? Command line is much
| better than this"
|
| "Why do we need to do this? I have been installing
| applications by compiling from source since 199x and it
| has worked perfectly fine for me."
| mavhc wrote:
| Surely lack of soft wrapping in the first version was the worst
| thing to happen to email, that breaks quoting, which leads to
| top posting.
|
| Also lack of a signature section, relying on weird -- \n hacks
| nedt wrote:
| Worst thing is spam. Second worst is silos by big players to
| fight spam, which makes it hard to run your own email server.
| Then comes HTML.
| iamacyborg wrote:
| Making it hard to run your own server seems to be a small
| price to pay to ensure billions of inboxes don't get overly
| spammed.
| nedt wrote:
| It's not like many spammers are using SPF and DKIM. And
| then you have google sending bounce emails to spam although
| they already know with SPF that the original mail came from
| somewhere else making them the spammers.
| kivlad wrote:
| The new Outlook desktop client is awful, but there's one silver
| lining and it's the retirement of the even more awful Word HTML
| renderer.
| croes wrote:
| MS did it on purpose for security reasons
| chrismorgan wrote:
| Are you sure? I have a vague recollection of someone confirming
| late last year that it was still MSO. But I may be mistaken.
| ceejayoz wrote:
| I thought this'd be one of those novelty sites that just say
| "No." in a big font.
| beAbU wrote:
| That's usually my default answer when my design team comes to
| me with a request for email template updates. "No. Basic
| formatting only. If you are feeling frisky, tables. Nothing
| more"
| NoGravitas wrote:
| Really should have been.
| blcknight wrote:
| Hehe, apple mail supports marquee very recently... Outlook even
| more so! 2020!
|
| https://www.caniemail.com/search/?s=marquee
| zipping1549 wrote:
| Bost mased HTML tag
| eqvinox wrote:
| Isn't AMP considered an antifeature these days? Last I heard even
| Google had abandoned it -- but this is outside my zone of
| expertise, so I might be wrong?
| dubcanada wrote:
| It's still quite wildly on websites. But it doesn't even have
| support for GA4 yet. It's probably dead just not yet on the
| dead list.
| dylan604 wrote:
| You maybe underestimating the number of people that use
| things without knowing what said things do, so those things
| just continue to live and never get migrated away from use.
| shortformblog wrote:
| AMP for email is a bit different of a beast. It works a lot
| differently from the web version and is used essentially to add
| interactivity to the email. If you use Google Docs, it's what
| allows you to directly reply to a comment in your inbox.
| chrisfrantz wrote:
| I use this daily, great resource.
| astrodust wrote:
| Alas! https://www.caniemail.com/search/?s=strongbad
| dang wrote:
| Related:
|
| _Can I Email?_ - https://news.ycombinator.com/item?id=27112960 -
| May 2021 (273 comments)
|
| _Can I Email: 'Can I Use' for email_ -
| https://news.ycombinator.com/item?id=20948826 - Sept 2019 (196
| comments)
|
| _' Can I Use' for Email_ -
| https://news.ycombinator.com/item?id=20934601 - Sept 2019 (1
| comment)
| Eric_WVGG wrote:
| HTML email was such a tragic mistake.
|
| I think the whole mess could have been averted if Markdown had
| been invented about twenty years earlier.
| zzzkkk wrote:
| Is this intended as sarcasm? Markdown renders to html, it's an
| authoring syntax that happens to be readable in it's "code"
| state. How would it solve email?
|
| The real issue is bespoke rendering engines instead of just
| using a rule of "everything the current browser can do, but no
| js".
| shortformblog wrote:
| Yes, this. Many more would be fine with HTML email if it
| didn't work like IE6--and honestly, the only reason it does
| is because of decades-old enshittification that we failed to
| address at the time.
| pavo-etc wrote:
| If emails could be marked up with the subset of HTML that
| Markdown is able to generate without having inlined HTML
| tags, email markup would be so pleasant. Just bold/italics,
| some headings, tables, properly flowing text, code blocks,
| horizontal rule, links, and images.
| prmoustache wrote:
| you just need gemtext. Bold/Italics can be done with
| unicode, no need for a markup language.
|
| Images can just be links and it would be a setting on the
| client to open it or not. Like what the Lagrange gemini
| browser does: it lets you click on a link to an image to
| load it.
|
| I would argue that even tables are superfluous, you could
| put a csv file in a block quote and people's clients could
| just render it optionnally.
| Eric_WVGG wrote:
| Not in the slightest.
|
| You can't make elaborate layouts with Markdown. You can't
| obfuscate text in images or make hidden links or inject
| JavaScript.
|
| Just some basic text styling (headers, italics, bold type),
| and images. Everything necessary to make a well-formatted
| message -- which is what email is supposed to be -- instead
| of mailing a web page, in a medium that hasn't been refined
| for quality and safety like modern HTML+CSS has.
| arp242 wrote:
| Markdown gives most people >95% of the formatting they want
| to do.
|
| It's easy and fairly intuitive to write (most of it, anyway).
|
| It's easy to read in different formats and ways (HTML, plain
| text).
|
| It doesn't add highly complex rendering issues. I've worked
| on two email clients in the last ten years, and the amount of
| weird HTML some send is just bonkers. Is <div
| style="position:fixed"> in emails crazy? Yes. Do you need to
| deal with it? Also yes.
| prmoustache wrote:
| The point is: markdown is HTML, not something else.
| arp242 wrote:
| It's not. Markdown is markdown. It can render to HTML,
| but that's a different thing. I struggle to understand
| why this is even a point of contention.
| prmoustache wrote:
| Since it supports any HTML tag, it is irrelevant.
|
| Mandate markdown and MTAs and marketing departments will
| send you markdown only made of pure HTML.
| arp242 wrote:
| That's quite the pivot from "markdown is HTML". But no,
| it probably shouldn't support HTML tags, or support it
| with limits. And maybe also a few other things like
| #-headers also shouldn't be supported as it can be too
| easily to do by accident. All of that seems pretty
| obvious in all but the most aggressively pedantic
| reading.
| jeltz wrote:
| Is C amd64 assembly then?
| prmoustache wrote:
| If your C code end up like that, yes:
|
| ``` #include <stdio.h>
|
| int main() { /* my software in ASM */ __asm__ (
| [...<insert your assembly code lines here>...] );
| return 0 ;
|
| } ```
|
| And you are pretty sure this is pretty much what would
| happen with markdown in emails if it ended up being
| mandatory. You would end up with emails entirely made of
| html.
| teddyh wrote:
| We did have text/enriched1 since 1994, but everybody mostly
| ignored it.
|
| 1. <https://www.rfc-editor.org/rfc/rfc1896>
| HelmetFigNewton wrote:
| RTF was invented in 1987.
| langsoul-com wrote:
| Non proper and standard HTML email was and still is a mistake.
|
| You're really rolling a dice on what may work, even if it's
| valid HTML
| l0b0 wrote:
| Is there something like this for features techies might care
| about? Like some sort of guarantee of at-rest encryption,
| SMTP/IMAP/POP/etc support, end user encryption, reasonably fast
| search _, backup /restore, etc.
|
| _ GNOME Evolution and Thunderbird, at least last I used it, have
| abysmal search speed, taking seconds to search through a _local_
| DB of a few thousand emails. So they 're clearly using search
| tech much inferior to a local DB with indexes.
| fastball wrote:
| I don't know about most of your list, but I do know that Proton
| Mail has E2EE email encryption via their proprietary client.
| andrew_ wrote:
| FWIW jsx-email has a builtin CLI email client compatibility check
| which uses the caniemail dataset:
| https://jsx.email/docs/core/cli#check
| ryanbigg wrote:
| What an excellent resource! (And yes Outlook is a pain and
| supports so very little!)
|
| We've tried building email templates for notifications for our
| apps where I work, and it has typically been a pain. We have
| since swapped to using mjml (https://mjml.io/) to build the
| templates, and it's working wonders. The output seems the be the
| most compatible with all different devices that we've tested on.
|
| The other tool we enjoy using is Litmus (https://litmus.com),
| which allows you to throw in an email template and see what it
| looks like on all kinds of apps and devices. Other thread here
| mentions https://testi.at/ as well, which we've also had success
| with.
|
| All of these have been really invaluable to designing emails for
| our apps.
| shortformblog wrote:
| MJML is easily the best tool of its kind and I use it a lot. If
| anyone is trying to build emails in 2024, it's a major shortcut
| that helps avoid and mitigate some of HTML email's biggest
| headaches.
| iamacyborg wrote:
| It can quite quickly lead to clipping in gmail if you're not
| careful though.
| willdr wrote:
| can you elaborate?
| joe8756438 wrote:
| the mjml components unpack to a very large number of html
| tags. so depending on how you structure the doc it can
| exceed the gmail doc size with a surprisingly small
| amount of content
| iamacyborg wrote:
| Gmail will clip emails if they're larger than (I think)
| 104kb.
|
| Using frameworks like mjml can add a lot of arbitrary
| markup that'll rapidly increase the size of your email.
| shortformblog wrote:
| I usually add a minify step to my sends for this reason.
|
| In my experience one of the biggest causes of clipping is
| styled links with lots of tracking, oddly enough.
| dabber wrote:
| mjml looks really interesting, thanks for sharing. I wish there
| was a business reason for orgs to care about accessable and
| machine readable (I guess OCR is a thing now but still) emails.
|
| I've been using Foundation for Emails[1] for the very small
| number of emails that I've worked on which required more than
| just a list of img tags, and I really appreciate it for
| existing because HTML emails have been stuck in ie6 web days.
|
| [1]: https://get.foundation/emails.html
| darekkay wrote:
| > I wish there was a business reason for orgs to care about
| accessable and machine readable emails.
|
| I hope the upcoming EU Accessibility Act will be enough for
| many organizations to finally make their emails accessible. I
| disable images by default in my email client, and some emails
| are pretty much empty without them, without providing any
| alternative.
| varnaud wrote:
| I assume most email client support email with both html and
| txt content. If they don't support html or configured not to
| display it, the txt version is displayed.
|
| We have a html and txt template for each email we send. It's
| not exactly double the work, but it's appreciated by some of
| our customers.
| almost wrote:
| Thank you so much for linking testi.at. I've been looking for
| an affordable alternative to Litmus!
| rjzzleep wrote:
| > What an excellent resource! (And yes Outlook is a pain and
| supports so very little!)
|
| So outlook today is the internet explorer of mail?
| easton wrote:
| It literally is, Outlook for Windows uses the IE9 engine to
| render HTML email, IIRC. And even then not everything is
| supported.
| GoblinSlayer wrote:
| You aren't trying to send an angular SPA in an email, are
| you?
| Vinnl wrote:
| Which is an improvement over when it used to use the Word
| engine to render HTML email, IIRC.
| another_kel wrote:
| Kind of. Though if outlook magically goes away we'll still
| make emails with <table> because most clients still do not
| support even flex-direction. Outlook is just exceptionally
| bad with stuff like width:100px working on table elements,
| but not on <div>, or padding working only on specific
| elements.
| chrisldgk wrote:
| While we're here I'd also like to recommend react-email[1]
| which I've been using for building emails for a while now. The
| components it offers are more than enough and it's definitely
| better than building mails with <!--MSO--> tags every five
| lines like we did back in my email marketing days.
|
| [1] https://react.email
| Animats wrote:
| It's about _content_ , not deliverability. It looks like it's
| intended to test whether A can email B, which would be useful.
| But no.
| EGreg wrote:
| So, does Android support inserting images yet into HTML email you
| compose with an app, for the user to send?
|
| It's been A DECADE NOW
|
| https://stackoverflow.com/questions/15136480/how-to-send-htm...
| qwerty456127 wrote:
| What about RoundCube, RainLoop, SquirrelMail etc?
| Aachen wrote:
| I was also a bit disappointed by the lack of open source
| coverage. If someone uses proprietary crap that doesn't work,
| they can go cry to their vendor, but I'd like Thunderbird, K9,
| FairEmail, and RoundCube to work for example. Anyone is free to
| use these so it would be cool if emails work there
|
| Would you be interested in adding RoundCube, FairEmail, and K9
| support? Those clients I'm familiar with so I can easily load
| up some eml files into my IMAP server and try them out, but
| it's some 144 tests total and a tad much to do all alone for
| "fun"
| isodev wrote:
| I love it! Designing emails is always a bit of a pain. With that
| said... plain text emails are so sexy ;).
| dankobgd wrote:
| but no, we can't just write plain text, we have to put our
| whole website inside an email
| morgunkorn wrote:
| Hilarious anecdote about this website: the owner once said there
| are tons of entries in the usage log of people misunderstanding
| the purpose of the website and inputting celebrities names to try
| to email them. :D
| junon wrote:
| I wish there was a database of some sort for these sorts of
| anecdotes!
| seper8 wrote:
| canianecdote
| kome wrote:
| that's a startup idea. and the answer to the "can i email...?"
| will be always a static page the says "no".
|
| there is money to be made here.
| loa_in_ wrote:
| That's not true and a very much defeatist view. Yes, you can
| talk with people if they're willing to listen and maybe even
| respond. Yes, even if they're extremely popular already. Even
| if they're richer than you.
| mamediz wrote:
| At first glance I was trying to figure out what this is about
| but, so far nothing. It's "like caniuse but for email content",
| ok but, what is caniuse? I don't know if it is worth but,
| before launching something new, I wish everyone consider to
| publish a brief section to explain to the average person what
| this is about.
| HelmetFigNewton wrote:
| "like caniuse"
|
| Is that supposed to tell us something?
| issafram wrote:
| Yes. It is used to let us know which HTML elements/features/etc
| are supported by different browsers/versions
| HelmetFigNewton wrote:
| It doesn't say that. It merely says this thing is like
| another undescribed thing.
|
| At first I thought it was some kind of service for dog
| owners, until I noticed the missing N. So... that left no
| explanation.
| jeltz wrote:
| An undescribed but very famous thing among the readers of
| HN.
| debesyla wrote:
| https://caniuse.com/ is a popular tool to check what web
| features are working across different browsers - "can you use
| this and assume that it will work for others".
| ahofmann wrote:
| caniuse.com is a website, where developers can check which
| features are supported by which browser and their versions. It
| is a immensely useful resource for webdevs.
| Longhanks wrote:
| If you had typed half your comment into a search machine
| instead of the HN comment box, you would've gotten an answer.
| guenthert wrote:
| But then I would have had to search as well.
|
| As a rule of thumb (well, wishful thinking, I realize), if
| Wikipedia doesn't know it, spend a few words to introduce a
| term.
| tuyiown wrote:
| caniuse is an extremely popular website among people that had
| to touch web technologies, so much that almost anyone searching
| for issues on web apis seriously will have hard time not
| stumble upon it very quickly.
|
| Hence, it's a totally valid assomption that the HN crowd might
| be aware of it. I'm sorry you were not, but you really are an
| outlier on this, which is really not a bad thing, btw.
| idle_zealot wrote:
| A fully-featured HTML "document" is really an application, not a
| document at all, so it makes sense that mail clients limit
| support. But this fragmentation makes me yearn for a real
| standard here, an official non-application subset of HTML that
| doesn't allow fetching remote resources or executing code. Just a
| document format with embedded media, animations, styling, etc.
| social_quotient wrote:
| Is it a "document" if it has animations and non static (video)
| media?
| idle_zealot wrote:
| Arguably? We don't really have a standard format like that in
| common usage so I can't predict where people would settle on
| it linguistically.
| joquarky wrote:
| PDF documents support video.
| pyrale wrote:
| Quite honestly, people have no business sending me code to
| execute or resources to fetch.
|
| I get that adtech is interested in using my email as their
| billboard, but they can fuck right off. Plaintext + attachments
| or gtfo.
| kcrwfrd_ wrote:
| Dark mode support in email is one of the most frustrating things
| I've dealt with as a frontend dev who's been coding since the IE6
| days.
|
| Basically you have to accept that you must only implement a light
| mode design and choose colors that will look okay when
| automatically inverted by all of the shoddy dark mode email
| client implementations.
|
| Gmail is one of the worst offenders. You have zero recourse for
| picking your own colors for dark mode.
| emmet wrote:
| Flashbacks to making a nice email template for a company only to
| find out their entire client list used outlook from a decade
| earlier and could just about render plaintext. There was no point
| in me even showing up.
| mykehunt wrote:
| MJML is better than most but remember every templating language
| has a footprint.
|
| When possible reduce your html code weight to the bare bones
| minimum. Nothing too fancy. Keep it logical. After a bit of
| practice it's actually easy and in my opinion often faster than
| MJML (For example MailJet. Don't even get me started on Klaviyo.)
|
| Even with minimal coding/hmtl experience you can run your code
| through GPT-4/Bard.
|
| Bonus for including custom instructions such as "transactional
| intent", Bayesian/heuristic filtering, coded for users with poor
| digital accessibility, under-served internet users, etc.
|
| Even with the best domain domain/ip reputation without a positive
| engagement history specific to that user you will often land in
| promotions/other tab and not the primary tab for new users with a
| heavily weighted creative.
|
| Remember you want to mimic "an email from Grandma" while
| maintaining some degree of control of visual design.
|
| Or if that's too complicated just keep your subject line under
| three words and all lowercase.
| Doctor_Fegg wrote:
| > Apple Mail (iOS) : 266/284
|
| > Gmail (Android) : 111/284
|
| Interesting corrective to the "Apple is holding back HTML"
| narrative that appears so often on HN.
| darylteo wrote:
| Honestly the biggest surprise to me. How on EARTH is Apple Mail
| (OSX) top!
| ktosobcy wrote:
| I would love for a middle-ground to emerge - plain-text emails
| with rudimentary formatting and ability to inline images.
| Something like markdown/asciidoc would be fine for overwhelming
| majority of cases. Unfortunately we ended up in a world where
| HTML email is a commonplace...
| EyebrowsWhite wrote:
| I use plain text, and I even enable "block external image" on the
| client, and I would advise others to do the same, because there
| is just too much phishing with email..
| sachahjkl wrote:
| Tuta.com not here :(
| kwhitefoot wrote:
| No Thunderbird on Linux, Windows, etc.? Is it different on MacOS?
| jpecar wrote:
| Soooooo happy that my mail client is not even on the list here.
| It automatically strips out anything remotely looking like html
| and it sends out plain text emails only, as email was designed to
| be and should still be.
|
| Anyone sending me css garbage will be directed to /dev/null.
| Thanks.
| mike31fr wrote:
| Reminds me of someone I knew 15 years ago, who often said
| "Anyone sending me text messages with abbreviations doesn't
| deserve a response". Sadly, now this guy has hardly any
| friends.
| tormeh wrote:
| Text messages with abbreviations come from real people.
| Emails with HTML and CSS are almost all automated, and
| usually some kind of spam.
|
| (Some email clients for humans probably add a bit of html and
| css to everything, but you get what I mean. It still looks
| like plain text)
| pembrook wrote:
| Have you ever come across the insanely rare use case of wanting
| to put something in italic or bold?
|
| Or even more insane, maybe wanting to add a link in an email?
|
| Or, you ever purchase anything online? It's kind of nice to
| have line items in receipts and an image of the thing I bought.
| But then again, I'm an irrational human who enjoys things like
| "aesthetic readability."
|
| As a true purist, do you also exclusively program in Machine
| code? Because that's how all software was originally designed
| to be.
|
| Seems silly to get religious about it.
| Aissen wrote:
| Nice to find privacy leaking clients:
| https://www.caniemail.com/features/css-pseudo-class-visited/
| EduardoBautista wrote:
| How would this be privacy leaking? Wouldn't only the email
| viewer be able to see the result of using :visited?
| nedt wrote:
| You could just load a different (invisible) background image
| based on the visited state to send out a ping.
| kevincox wrote:
| I recommend reading https://developer.mozilla.org/en-
| US/docs/Web/CSS/:visited
|
| > For privacy reasons, the styles that can be modified
| using this selector are very limited
| dustedcodes wrote:
| I can't figure out how to use it.
|
| When I enter "<a href="https://example.org>Test</a>" it says "No
| results found. Why not suggest this feature to be added?".
|
| When I enter "<a>" I get "AMP for email", "BIMI", "accent-color"
| and lots of other CSS attributes starting with "a" as result.
|
| When I enter "a" I get the same as above.
|
| How do I check if I can email the HTML Anchor tag? The input says
| "HTML, CSS, ..." but it doesn't seem to understand HTML unless
| I'm doing it wrong?
| nedt wrote:
| You might have been unlucky searching for the a element that's
| really short. And very basic HTML would work everywhere. But
| you might be more happy to go via the feature list:
| https://www.caniemail.com/features/
| dustedcodes wrote:
| LOL ok that was just a really unfortunate coincidence. I used
| the <a> tag because I knew it would/should be supported
| everywhere so wanted to test the website with an input where
| I know what response to expect :)
| pabs3 wrote:
| Hmm, no mention of JavaScript or remote resources, nor any of the
| Linux clients.
| asddubs wrote:
| do any email clients support js?
| silon42 wrote:
| I hope not.
| gtirloni wrote:
| The compare email clients option got me confused. I select
| Thunderbird and Apple Mail and didn't get a list of differences.
| throw4847285 wrote:
| I can't be the only person disappointed that this isn't
| Caninemail.com, can I?
| palata wrote:
| I like plaintext better (https://useplaintext.email/).
|
| And emails can totally be sent both as plaintext and HTML, so
| that the receiver can choose! I just don't understand why so many
| services only send a text/html version instead of both text/html
| and text/plain.
___________________________________________________________________
(page generated 2024-05-07 23:02 UTC)