Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
Yahoo web mail (mail.yahoo.com) is stripping out these inline styles, but keeping things like color and padding.
text-decoration
font-size
border-radius
text-align
font-family
Any idea why these are purposely being removed?
Example:
<span style="font-size:30px;">Hello</span>
becomes:
<span style>Hello</span>
What can be done?
This is the difficult part because options are few. Even with free market choices well established corporate entities have little to no business reasons to improve their products unless competition comes along. You could always attempt to file a bug report (like, where if even any where though...) and as usual wait decades for a(n intelligent) response (*cough* Mozilla *cough*). You could attempt to work around the issue (replace width with min-width in example). I've noticed that font-size: 120%; works just fine so consider what unit values you're using for testing.
You can make a different though, even if it's relatively small. I was wronged by a motherboard manufacturer in the mid-2000s and since then they've lost tens of thousands of dollars of sales because of me directly and who knows how much more based on the video I posted back then and that is just in the past ten years. The issue with Yahoo is different, at best all you can do is write a blog entry and link to other people talking about the issue to raise awareness. You could go so far as to disallow registrations from users with Yahoo accounts or greatly discourage users from using Yahoo accounts though that could lead to a loss of members so I wouldn't do something like that unless you've got something people really want. The state of HTML email in general is exceptionally sad at this point though most (at least technical users) typically have multiple email addresses.
You could always use <style type="text/css"></style> even though scoped CSS is not widely supported in 2017 except for Gecko/Firefox though it did seem to fix some of the issues for me that you mentioned you were having.
Lastly you can always provide a "view this email on our website" option; I see it all the time because HTML email is still a disaster (2017). I've even seen nonsense with developers sending email with html element (uh, it's not an entire page, it will be embedded, but you know, whatever...).
So try utilizing different unit values and even the contexts themselves. Inline-styling is the way to go and if that fails provide a website version of the email (with security considerations for email with sensitive data).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
It's 2017 and we are still stuck with HTML tables to create rich emails. Why? It seems reasonable to leverage the hard work behind the modern browser engines (ie. blink), when all you want is to render an HTML document properly.
Update: Since this question was closed and my answer resembles a blog post, I published an updated version on Medium.
Email clients use rendering engines appropriate for displaying emails. This is not always in step with displaying web pages.
Only a small % of email users care about HTML/CSS support. Think email marketers and developers. The vast majority of email users simply want a simple, secure way of sending and receiving rich text messages with other people. That’s what email clients are designed for.
Even more advanced users don’t often cite good HTML/CSS support as a top concern. Recent innovations give us a little insight as to what folks are frustrated with regarding email clients: help managing incoming messages, more security, less SPAM, and overall ease of use.
No one cares if it takes developers a long time to use <tables> and inline CSS to create an email. When it comes to changing how emails are rendered… “If it’s not broke, why fix it?” When email clients actually do update rendering, it’s rarely news outside of the tech community. Few people care.
Consider Desktop Outlook, which typically comes bundled with programs like Word and Powerpoint. All these programs have a similar interface and display output. If you can author a Word document, there’s almost no learning curve in writing an email in Outlook. That’s huge for a lot of people. In all likelihood, Outlook’s rendering engine wasn’t chosen based on it’s ability to render an HTML document properly, yet the product is still considered a success. Because desktop Outlook and doesn’t get automatic updates, old versions (that we have to code for) tend to hang around.
Fun fact: Outlook 2000-2003 rendered email using whatever version of Internet Explorer was installed locally the computer to render email (usually Internet Explorer 6).
Gmail is another example. While Gmail has pretty good HTML/CSS support, it didn’t support external CSS files until late 2016. Gmail (unofficially) cited security as one of the reasons. I don’t know what keeps the Gmail team up at night, but I bet it’s not how email developers can’t optimize their email layouts. I bet it’s security. And so that’s where the gmail dev work gets focused.
Overall email clients do their job relatively well. Since HTML/CSS support matters to so few people, changing it is likely not often a priority for product teams that make email clients.
However, things are trending in the right direction. Gmail and Yahoo! app began supporting media queries in most of their products. Outlook on iOS got a huge facelift including good markup support. New email clients that crop up (Mailbox, Nylus. Polymail) generally have good HTML/CSS support compared to the web. Rarely does support go backwards. The majority of clients based on market share use “modern rendering engines”.
Additionally we can always reference our own email analytics. Don’t have many Outlook subscribers? Then code an email using <div>s. Don’t need to support every mobile client? Then use media-queries.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Having ranged through a number of support indices and point - trouble - shooting, templates and tutorials, I felt like I was struck by a thunderbolt when it occurred to me that I should be making all my emails to work in Gmail first, because I don't recall at least ever seeing that as a specific recommendation.
This is assuming I have elements I may want to be visible depending on the user's device/screen, and as such, out of all the email clients I've been hassled by, Gmail is the least flexible since it doesn't support any embedded styles. So, to me, it would make the most sense to layout the email for how it should work in Gmail, then add on to it from there primarily with embedded styles.
As per the question guidelines, I'm not looking for opinions about this, but technical limitations that you all could foresee arising as a result of this workflow. That being said, what would they be, if any?
I've been slicing emails for a very long time and have watched the changes (or lack thereof) over the years. I don't think in terms of "GMail" or "Outlook" first but rather what I consider the three basic categories of HTML emails: fixed, fluid or responsive (or a combo of one of the first two and responsive, too).
A properly done fixed email looks the same everywhere and is supported by every major email client. A fluid email will change on every email client but the changes will be relative to neighboring changes and can for the most part be predicted. A responsive email, although similar to a fluid email, has much more granular control over rendering and can actually set the "fluid rules" based on screen size.
Depending on your target audience, my recommendation to you would be to build a fixed email that looks awesome (you're worst case scenario) and then add styles to the <body> tag to handle responsive to make it even more awesome. Once you get the knack for building fixed emails it goes pretty fast so you'll spend most of your time in the responsive side of things.
View Campaign Monitor's Guide to CSS for the most comprehensive guide of supported CSS in email clients. In general, before you use a certain type of css you should see what email clients are supported. Gmail would be a good reference point to start, but you will want to be aware that there are some elements that will not work in some other clients.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am just completing my mobile website, and I was about to put a <a href="tel:"> links, when I thought about telphone number harvesting, in a similar capacity to email harvesting.
This may not be the biggest issue now, but as mobile websites get more popular this is clearly going to be a target, with the biggest issue being it's not going to be easy to ignore spam phone call like it is with email. This is probably a big issue now!
Has anyone heard of this type of telephone harvesting, although not that much different to the ways company already get your numbers, except this doesn't really have a no call list you can join.
I'm not saying this doesn't already exist now, I've had a few calls from the odd "SEO company", to which I laugh at being a web developer. But this is clearly going to make it easier to harvest numbers.
Has anyone got any thoughts on solutions to prevent this, like the js obfuscation for emails? OR is it going to turn in to one of those do it at your own risk situations, like mailto: ?
Update:
Is there a way to obfuscate the phone number? or is this just something to be avoided?
Telephone number harvesting is possible anyway without the tel: attribute. It's not that difficult to write a parser to extract phone numbers from plain/html text. It's much, much less of an issue than email harvesting as it is so cheap to send an email. A phone call costs money and takes time. Plus of course I've never ever heard of this being an issue to anyone. So I really wouldn't worry about it.
If you are still concerned about it, I suggest you read up on email obfuscation techniques. Very briefly these are:
Scramble the data server-side, and decode it in javascript (but what happens if js is off?)
Use an image
Hide behind a captcha (requires user intervention, is a pain)
And of course none of these are bullet proof anyway, a determined harvester can work round all of these. And don't forget human slave farms in the far east.
tl;dr: honestly, it's not worth it.
Not sure what you are looking for exactly, and I don't know about obfuscating phone numbers, but you could try a CAPTCHA (although that wouldn't work well for some users, and is annoying to almost all users) and/or using a phone forwarding service like Google Voice, which would allow blacklisting numbers, or pulling the plug on all phone calls if it becomes a problem.
I don't think it will become a big problem for you, as phone calls are as cheap or easy as an email message, and it isn't as easy to hop phone numbers as it is to switch email addresses, so it might be possible to keep up with blacklisting numbers.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Has anyone, with a large sampling, done research on how many users actually print webpages? I'm looking for some percentage values. .01%, 1%, etc actually print webpages.
It seems like a waste of time, to create design oriented print pages, if the stats extremely low.
It is very easy to create some print styles for your stylesheet to make printing easier on people.
As an example: http://www.alistapart.com/articles/goingtoprint/
In the same way that not everyone who visits your site will be disabled, the best practice is still to create sites that work for people with accessibility problems.
I don't have a link to a study for you but I'm very confident that it depends heavily on the type of content. I.e. the percentage of people who print a youtube video page is for sure much lower than those who print a recipe from a online cookbook.
So it's probably best to run your own study on the particular website where you need it. You can either make a little poll for the users of your site or track how often pages actually get printed.
This is not a metric that is usually tracked.
Since one needs to differentiate the regular page from the printable page, this requires a custom implementation on the printable version page that sends a particular tracking code/cookie.
It is not that hard to implement, one can even have printable pages tracked in google analytics or any analytic engine, but as I said it does require preparation and most people don't track this metric in particular.
It is possible through JavaScript to track the actual printing event with IE browsers. Considering users most likely won't switch to IE just to do the printing, it would give some sort of accurate indication of what % of the IE users, print the page.
For more information about the onbeforeprint and onafterprint events have a look at:
http://msdn.microsoft.com/en-us/library/ms536672(v=vs.85).aspx
Btw, I am not saying that collecting this data solely from IE users would give an accurate indication of the overall % of printed pages across all browsers, because IE is far more commonly used in office environments rather than home environments.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
A member of my company in greater ranking than myself refuses to use recaptcha.net on his website to thwart spam off of a public form. He thinks it would be difficult for anyone coming to our site to enter their information since the Turing Tests are "so darn hard to read".
Is there an alternative to using this method? That doesn't contain these sorts of difficult to read images?
(Okay stupid question...if it were up to me we'd use recaptcha because everyone else on earth does...but I just figured I'd check anyway.)
Also, is using a hidden field that is set by Javascript and later checked on the server really a good way to thawart spam?
I myself don't really buy that it is...since there are all sorts of Javascript engines that don't run in a browser yet can run Javascript (Rhino etc...), that could easily be used to thawart a JS/Serverside anti-spam method.
CAPTCHA will reduce your spam but it won't eliminate it. People are paid to decipher those glyphs. Some sites use the glyph that was presented to them for their own site so some hapless visitor will decipher it.
Just so you're aware that it's not a perfect solution.
Based on the principle of don't solve a problem until it's a problem: is spam a significant problem on your website? There is something to be said for not annoying your customers/visitors. Even here I sometimes need to make a few edits and I get the irritating "I'm a Human Being" test on typically the last edit I need to make. It's annoying.
People have proposed all sorts of other methods for dealing with this problem. One I read about used picutres of cats and dogs that you had to classify because apparently there's a database of 30+ million of these in the US for abandoned animals or somesuch. This or anything that gets in widespread use will be defeated.
The biggest problem with spam on sites is if you use software that's in widespread use (eg phpBB). Your best bet for those is to make enough modifications to defeat out-of-the-box scripting. You may get targeted anyway but spamming is a high-volume low-success game. There's no real reason to target your site until it accounts for a significant amount of traffic.
The other thing worth mentioning is techniques that can be used to defeat scripted spam:
Use Javascript to write critical content rather than including it as static HTML. That's a lot harder to deal with (but not impossible);
Rename and/or reorder key fields like username and password. For example, generate username and password form fields and store them as session variables so they only work for that user. That then requires the user to have visited the page with the login form (rather than scripting a form response that can be POSTed directly);
Obfuscate the form submission. Things like unobtrusive Javascript that you can do in jQuery and similar frameworks make this pretty easy;
Include a CAPTCHA image and field box and then don't display them (display: none in CSS). You'll confuse parsers.
The best way for not so popular sites is to insert a hidden field and check it. If it's filled then it's spam because those bots just fill in any field they find.
You might want to look into Akistmet and/or Mollom.
Add a non-standard required input field. For example, require a check-box that says "check me" to be checked. That will defeat any automated scripts that aren't tailored to your site. Just keep in mind it won't defeat anyone specifically targeting your site.
A simple way is to display an image reading "orange", and asking users to type that.
Yes, recaptcha will cut spam but it will also cut conversions! You should consider using XVerify which does real time data verification. What makes those registrations spam is bogus data, with XVerify it will make sure the information you put in is real data by verifing the email address, phone number, and physical address of users. If the information is fake the user cannot click continue! SIMPLE!
I used to think CAPTCHAs were good and used reCAPTCHA on public forms. I noticed that spam submissions were gone but I also noticed that real submissions were cut drastically as well.
Now I don't believe in CAPTCHAs. They work but I feel they can do more harm than good. After having to enter in hard to read CAPTCHAs on other sites I understand why I don't get as many real submissions. Any input that a user must act on that is not related to their main goal is a deterrent.
I usually use several methods to prevent spam and it depends on what type of content I'm expecting in forms. I created server methods that scan comments and mark them as spam based on content. It works ok, but I'm no spam expert so it doesn't work great. I wish someone would make a web service that did this.
I think the links from Evan are pretty interesting!
Another method that I have heard about, which basically extends the javascript idea, is getting the client's browser to perform a configurable JavaScript calculation.
It has been implemented in the NoBot sample as part of the Microsoft AJAX Control Toolkit
http://www.asp.net/AJAX/AjaxControlToolkit/Samples/NoBot/NoBot.aspx for some more details of how it works.
I found an alternative called Are You A Human. Not that programmers should go on gut feelings, but from the start it seemed insecure. Since it's a fun game you play, I decided to try it. It didn't work for me. It's possible the host isn't set up for it. That's the last thing for me to check.
If anyone else has tried ayah, I'd like to know how it worked.
I've used Confident Captcha before and it was really easy to get set up and running. Also I haven't had any spam get through on the forum I manage.
It isn't a text based Captcha but instead uses images similar to picaptcha. I've tried 'Are you a human' before and it's definitely an interesting concept.
Found one called NuCaptcha which displays moving letters...
8 years later...
I have been looking for alternatives to Google's reCaptcha, which doesn't ruin the UX, tracks user, etc. and found this gem: Coinhive Captcha.
It works by mining Monero coins (hash count is adjustable) in the background and provides a server-side API to verify it. It should be noted, that - depending on the selected hash count to solve - it may be slow, specially on mobile devices.