Really simple here but i am trying to generate a link within an email that popups a page but its not working it also is througing a security exception in outlook 365 how does one properly open a popup from email with correct height and width of window.
here
Using scripts is totally unsupported in emails.
"Scripting in Emails
The short answer is that scripting is unsupported in emails. This is hardly surprising, given the obvious security risks involved with a script running inside an application that has all that personal information stored in it.
Webmail clients are mostly running the interface in JavaScript and are not keen on your email interfering with that, and desktop client filters often consider JavaScript to be an indicator of spam or phishing emails.
Even in the cases where it might run, there really is little benefit to scripting in emails. Keep your emails as straight HTML and CSS, and avoid the hassle."
Source: https://www.campaignmonitor.com/dev-resources/guides/coding/
You can use target="_blank" instead.
You have to use the a tag this way:
Open page in new window
Hope it helps.
Related
I'm just trying to send a little Christmas e-message around my friends/family, I've built it to be fully responsive etc the way I always do. However as it's just for friends I'm not going to send it via MailChimp which usually sends everything for me no problem.
The way I'm trying to send it is by opening the index.html file, selecting all, copying, then pasting into Gmail. This has always worked fine for me in the past, and does work. However this is my first responsive email that I'm trying to send this way, and it seems the media queries don't get brought across this way, at least not in the gmail -> hotmail test that I just did (Resizing window etc does nothing, just shows the desktop version).
Is there a better way of sending an already built HTML email, rather than just copying/pasting in Gmail?
Unfortunately, Gmail does not support the <style> tag. Media queries can only be called in the <style> tag, and not inline, therefore Gmail doesn't support them.
Here is the support chart.
I would suggest you stick to an ESP like Mailchimp for sending html email. But while you are playing around in Gmail, here is a tool that may help you debug issues with your email code.
The selected answer is not actually correct! Gmail strips IDs and classes from the email body itself, but the style tag IS retained.
You can use the following:
*[summary~='fakeclassname'] {
styles: here;
}
"Summary" is one of the attributes that Gmail does not strip out. After it occurred to me what Gmail was actually doing to emails I found this article that breaks it down in detail:
http://freshinbox.com/blog/interactive-emails-in-gmail-using-css-attribute-selectors/
There are helpful links on that page that get deeper into Gmail-specific targeting.
Note: the Gmail app does strip the style tag, and with a rising market share (Android no longer has a native app and pushes people to use the Gmail app) should be considered a starting point for mobile-first email development.
I'm looking for some advice on what I "should" research for a particular project I've been asked to keep in mind. I've been doing so for roughly 3 days by exploring various Google technologies, but none of them seems quite right.
I need to put together something for gmail that's roughly equivalent to something I've put together for Windows Outlook. I'll explain in brief therefor what I've done for Outlook users, to give you a feel for what I'm looking for. I put together an Outlook C# AddIn that when loaded by Outlook on startup adds a number of clickable tabs, buttons, and other assorted interface elements to the Outlook interface. When you click them the C# code in my Add-In is invoked in various ways to carry out various activities, like archiving the email message that's currently selected in a remote database managed by one of our web applications. It does this by calling a variety of Outlook C# APIs that are available to any loaded AddIn, to extract or manipulate various Outlook "objects". Another thing it does on a button click is bring up a web browser the AddIn creates from a .Net class "webbrowser control" instance, essentially adding chrome to the IE "engine". It also adds what it needs to to the DOM of that web browser to make a large number of Add-In C# functions callable by javascript code that might be running in pages of that browser, essentially giving our web applications a way to "ask" my AddIn to create Outlook contacts, tasks, messages etc on behalf of that application. The gist of it is that the UI I add to the Outlook application can be used to make various web service calls to our applications (based on the state of various Outlook "objects" made visible/manageable by way of the Outlook C# API), and the state of the Outlook application can be manipulated by javascript code running in web application pages that happen to be loaded in the web browser it creates.
I need to support "similar" functionality with respect to the altogether different gmail beast (rather than a Windows application a browser based web app). I feel a bit like I've been spinning in circles the last few days, while investigating. I began by researching gmail Sidebar and Contextual gadgets, to add some roughly equivalent UI of my own to gmail, but found fairly quickly that I can't really get to any gmail APIs using them, only try to shoehorn what I've got into a set of triggered gmail "behaviors" supported by contextual gadgets, which I came to realize isn't really sufficient to support what I want. Eventually I navigated my way to the set of developer pages describing Google Apps Script supported functionally, which seemed for a time like "the way to go" to provide me with hooks into gmail APIs. I played a bit with them, making a web app script to collect the subject lines of all my gmail messages and dump them into a UI also built by the script, just to get an experimental quick feel for how things fit together. The script works, but it seems pretty slow, taking roughly a minute to collect and display just 57 email subject lines. And I can't really figure out how to get any script built UI into the gmail user interface. I tried building a side bar gadget with the URL of my app script referenced (with no HTML or javascript in the content tag body at all). An area is allocated to the gadget ok, but my script UI never appears in it. After playing a bit unsuccessfully to get my script to run in an iframe in a completely different context, just experimenting again to see what I might be able to do, I'm beginning to get the impression that some security related caveat prevents it from building/displaying its interface in either an iframe or a gmail side bar gadget, though perhaps I'm just missing some essential piece of information.
My question is a bit big I know, but "should" I be looking to other Google technologies to build the sort of thing I have in mind, or am I "roughly" following a tenable track. I'm looking for some rough architectural advice I guess, some hints about what maybe I should further explore.
With Google Apps Script you cannot add anything to the Gmail interface. Putting it simply, it will not do what you want.
Now back to your problem, if sidebar and contextual gadgets are not enough for you. The only solution I see where you can really manipulate the page is via an add-on/extension/script installed on the users browser.
This approach is powerful, in the way that you can change the page as you like, but has its shortcomings as well. First, and more obvious, it's somewhat browser dependent and installed locally on a browser. Meaning that if the user switch computers or browsers, he'll need to re-install your add-on.
Also, you're somewhat dependent on gmail's "internal" structure. I say "somewhat" because that depends on how you coded your app. But they may make a change and break your app instantly, without any notice, since gmail's html-css structure is not a "published API".
Well, that's my 2 cents. I hope it helps.
Use JSF and rich faces. this can give u a google gmail like looks and development with this is very easy and fast.
Happy Coding
Is there anything I need to be aware of when creating a HTML e-mail? Is it as simple as creating a valid HTML page then sending it via PHP? Or do I need to use tables to ensure it display's correctly.
Any advice to get this right first time would be much appreciated.
Creating an HTML email that displays the way you want to in email clients, can be very difficult, if not impossible. Unfortunately, email clients do not use the latest and greatest web browsers when displaying emails, and they can also restrict what should be allowed (and with good reasons).
No matter how much you might love CSS-based layouts, table-based layout is still the way to go for HTML emails. You can still use CSS for other things, of course, but in some cases it will need to be inline. The best looking HTML emails I've seen, are largely made up of tables and big images - simply because unlike on normal web pages it is nigh on impossible to create the equivalent using good web development practices. HTML email is a world of its own.
You should also test the emails in as many email clients as you can - and while it can be cumbersome to install all the different clients, you can also use services such as Litmus, MailChimp and CampaignMonitor (see also this question). Personally I have had good experiences with Litmus.
Good luck, creating HTML emails can be quite messy!
Tables are definitely the best option for HTML emails, since most other methods tend to display differently on different machines.
Things to watch out for:
Images are often blocked by email programmes - try to use background colours where possible
Don't link to an external stylesheet - put the styles in <head>. This will prevent your server being hit when the emails are opened.
There's also a good blog post from Mailchimp about using CSS in HTML emails.
Tables is bad...but the correct way to go in emails...
Also send only the part you would normally put in the body and only use inline css.
Another important thing is that background images most of the time dont work.
This is a very good guide that can help you out.
my advice: test in a lot of browsers,mailclients and email programs
You should check out Email on Acid, they not only show you what your email will look like in each client they also analyze your HTML. They highlight the HTML in you code that is not supported in the clients. This tool has saved me hours trying to figure out why an email doesn't render correctly.
One other thing that is very helpful is they provide Tips & Tricks for each client. Anyway you might want to check it out, very helpful.
As the question states: Mailto is useful enough for people who use a desktop email client. That number is, I'm thinking, going down all the time outside of corporate intranets. Thus making mailto links an annoyance for these people, as they have to close whatever the default mail client is on their system and copy-paste the link.
Now, I know that there's plugins to bridge the issue, but let's face it - most people probably don't use them. Is using mailto rude or unthinking these days? I say yes, what say ye?
I personally think they're still relevant, since I still use a desktop email client. What alternatives to a mailto link exist? Printing the email address sans an actual <a> tag is annoying, because then visitors have to copy-paste the email address; and using a form to submit a message is annoying because then there's no record of a sent email.
If a visitor without a configured desktop email client is really concerned about mailto links, he can always install a plugin to handle mailto links with his webmail client.
If you use the Google Toolbar, you can have mailto: links go to gmail.
So, no... mailto: links are still relevant.
I'll be the dissenting view here. Mailto links annoy the hell out of me when the email is not also printed on the webpage, or when it isn't clear that it is an email link. For example, a link marked "feedback" could just as well lead to a web form. I browse a lot on machines other than my own, and I don't appreciate having to wait ~10 seconds for Outlook to start up, just so I can click No a bunch of times, then go back to my browser.
So mailto links are fine, but please label them clearly.
Mailto is relevant. As with all HTML, it's up to the client's web browser to interpret the meaning. Which implies that it is possible for a web browser to forward the request to a web mail solution.
It's unlikely for that work, as that most web mail services do not follow a standard way of doing things. However, there are a lot of mail clients that are used, and I find it nice to have a mailto link. Also, firefox allows for the user to copy just the email address.
Mailto links are still the standard way to do things. Your alternative is to just put the email on a page in plain text, which is strictly less usable, since now nobody can click on it.
If you really want to do something useful, you could use javascript to add a little drop down menu that appears on hover that has links to several popular webmail's "compose" options. However, I haven't seen that done anywhere and so might be awkward for users.
Browsers are building in support for webmail. I'm using Firefox 3.5 and it gives me a choice of Gmail, Yahoo mail, or "use other" (in addition to Thunderbird).
I'm not sure what's the problem? Use a mailto link for those who want it, and have the link text display the address. Those who use webmail (or want to copy it for whatever purprose) can then just highlight it and copy.
It's a standard. Why throw away a standard just because some people don't use it? Browsers like Google Chrome have a "Copy E-mail Address" option on the right-click menu so people without a desktop client can easily get the address into their webmail application.
These days, I don't think people post their email addresses as text, anyway. Or they shouldn't, at least. It's way too easy for spam bots to grab them that way. I always try to place mine in an image or something.
The bottom line is, it's kind of a non-issue.
Gmail can be used to link mailto - so, webmail is not an issue, if it is well written ;)
Take a loot at this, for instance. And as said in another post, Google Toolbar offers this out of the box.
Its either close the default mail client or copy-and-paste the mailto address. What we really need is for OS vendors to make it so we can set up a webmail address as our default mail client. Though there are security issues to consider with that of course.
Any additional semantic meaning you can add to content is a good thing. Mailto differentiates an email address where a user needs to take immediate action on, from a regular address that can wait to have action taken.
Mailto is a wonderful thing. I want your email address to open in my client, not a browser window.
I have seen some mails which has HTML content embedded in them. The content of the mail changes as the corresponding webpage in their site change(for example price of stocks which keeps updating in the mail itself). How to link such webpage content into emails?
In other words how to link a web page into an email so that whenever I change the html page, the mail content also changes.
Thanks...
A thought: maybe they are using an image that is downloaded from the server?
As you can't have JavaScript in an email or even most CSS, I'm guessing this might be one of the only ways. I'm pretty sure that one email client or service removes every piece of "special" HTML: iframes, JavaScript, CSS, Flash, etc.
You could place an image in your HTML - which was updated by you on your server.
This may be impossible due to security limitations, but you may be able to use an iframe element.
Not a solution, but a quick answer from my site on this topic as a user: Beside the point that Javascript/Image/IFrame/Flash solutions doesn't reliable work in all email clients, but are a general security risk, I dislike the basic idea of changing the looks of an email after you have send it without the receivers approval. Additionally you make it very easy for the user to be tracked (working hours, locations, view) and that is definitely NOT in the interest of the users. If you have something important or interesting to tell just provide a link to your site plus a short description...