Embed JQuery library in HTML file [duplicate] - html

Is JavaScript supported in an email message?

http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients
Old clients, such as Lotus Notes, Mozilla Thunderbird, Outlook Express, and Windows Live Mail all seem to have supported some sort of JavaScript execution. Nothing else does.
It seems like a bad idea security-wise, so I would expect this to be a feature that won't always be around, even in these clients.

Short answer
No
Descriptive answer
It depends. But the email is not guaranteed to behave in the way you want it to. Different email clients handle JS differently. Most of the newer email clients do not support any of it since it is potentially very dangerous to support script execution in a desktop application which contains so much of your personal info.
I had a use case where I needed to use JS in an email. I tried out on the web client of outlook and desktop client as well, and it turns out outlook just wipes out the script part of your HTML email. There might be some other email client which does support JS execution, but given that you cannot control the client where your email would be viewed in the client machine, it's not a good idea to embed any scripts in the HTML email.
Its advised to keep your HTML email as simple as possible, no JS, and the least CSS you can do with (because, again, different email clients have varying support for CSS as well) eg: outlook's web client was not even recognizing an HTML button tag in the email. I had to use an anchor tag and some CSS on top of it to mimic the display of a button.
Bottom Line - Don't rely on Javascript when working with HTML email content.

No, generally speaking email readers do not allow javascript.

Other answerers have suggested that the answer is "No."
On the other hand, an html attachment will probably get opened in an environment that runs Javascript.
EDIT: It was suggested that I haven't properly answered the question so here goes a more complete effort.
Summary: I would expect that many or most users receiving an html-formatted email containing embedded Javascript will see it run and have run tests to confirm that this is true in some environments. But Javascript WILL be blocked for some users.
The protocols (specifically RFC2854) explicitly address scripting (within the text/html message body type) with the statement that:
In addition, the introduction of scripting languages and
interactive capabilities in HTML 4.0 introduced a number of
security risks associated with the automatic execution of programs
written by the sender but interpreted by the recipient. User
agents executing such scripts or programs must be extremely careful
to insure that untrusted software is executed in a protected
environment.
So the protocols do support Javascript, but which user agents do?
My (ancient) email reader uses a table to specify which viewer software to use for each mimetype, diverting html content to my favorite web browser. Almost all current web browsers support Javascript (and some issue dire warnings when you try to turn it off!) Do modern email agents include internal html interpreters and, if so, is the javascript turned on or off? I've checked documentation on Thunderbird and find that javascript seems to be turned on by default but can be turned off: http://codeverge.com/mozilla.support.thunderbird/simple-html-tags-reference-docume/2030160
I have noticed that some (?many?) users now access their email from a browser directly (webmail is one such platform) rather than running separate email software. All such platforms which I have tested so far do run any Javascript embedded in the html of the email message. However some such environments, depending on user security settings, do not automatically fetch external links (Javascript or pictures or other) and so can only run external Javascript from a file which is included as an attachment to the message. The same would be true of any offline email reader on a device without a current internet connection.
The above applies to javascript embedded in the main message part of the email body. One can also have html explicitly given as an "attachment", which if saved and then opened would be displayed in a web browser, wherein Javascript is available with very high likelyhood. Therefore, one might included a second copy of the javascript enabled email as an html attachement with an alternative text/plain main body and/or tag in the main text/html directing the user to the attachment.
I've been thinking about this because some of my acquaintances insist on sending me "email greeting cards" which consist of a text message directing me to a link which I've found so unsatisfactory that I refuse to even consider loading it just on principle. I have written and sent email greeting cards with interactive graphics and music and even games using embedded javascript and been satisfied with the result.
Therefore, I maintain that the correct answer is "Yes" both on the grounds that the protocols specifically address scripting and on the grounds that all the email agents I personally use ran the Javascript in my test emails.

You aren't going to get executable JavaScript onto a server and into a mail client. But emails DO support links, you can always link to your content within an email.

For most mail clients, no.

No email client support javascript due to security concern
Try to send a mail with this HTML content
<!DOCTYPE html>
<html>
<body>
<button onclick="this.innerHTML=Date()">The time is?</button>
</body>
</html>

It may be, but mail clients won't read it & mail servers may reject it. So leave it out.

Javascript is not supported in emails.

You can view an email with JavaScript working with Windows Live Mail, but can't add JavaScript to a new email you wish to send.
JavaScript also works with saved .eml files.
Mozilla Thunderbird version 60.7.0 can't view or add JavaScript.
(If you save an eml file with Thunderbird, the code will work if file is then loaded with Live Mail)
You can send an email with JavaScript using PHP code.
Some email websites may support it, but the few I used don't. (AOL, uk2.net, GMail)

Short answer: No it is not supported in an email message
Long answer:
I have tested it with two email readers. Outlook (online) and OE Classic. As OE Classic is very outdated (I use it on windows 7), it does support JavaScript and I tested it with an alert button. However, the newer Outlook does not even support buttons, which showed up as plain text. So to conclude JavaScript is only enabled on some, usually older, email readers but not on new ones such as Outlook.

Related

HTML: How to send an email via an html link?

I learned to write html and css code a month ago. I am in the process of making a blog website for my friend. I got there when I made the about page. And I made a button there that would have made it possible to talk to my friend via email. And it didn't work :(
(I can't code in PHP)
I tried this:
<button type="button">Let's Talk!</button>
I thought it would open a page with only the email and nothing else. (of course the recipient and the subject)
The HTML you wrote should work, even if it's not strictly valid. To be clear:
You cannot send an email directly via HTML, it is up to the web browser itself how a href="mailto:" link is handled.
For example, Firefox will attempt to start the default email client of the operating system when a mailto: link is clicked. You can also configure what Firefox should do with mailto: links. There are similar configurations for other browsers and operating systems.
Websites and apps can also ask the browser or operating system for permission to become the default email client.
In short, control of mailto: links is up to the browser, and not something you can control from HTML.

HTML5 - Do users get to see all my client code?

If I am building an HTML5 web app.. And all the rendering, UI events, etc are handled on the client, then the client gets to see the source code correct?
I am working on an enterprise HTML5 application but Id like the source code to be hidden. Are there any options?
Is it also possible to somehow hide UI graphic elements (buttons, backgrounds, sounds, etc?)
What are the options here?
Thank you
My ready answer is No : your javascript code as well as links to jQuery UI code is visible on the client's asking to "view the source".
The question is : Is it possible for your code to be applied/run by the client's browser without being shown as "source?"Is there a way :- to prevent the client from seeing the "source"; or - to destroy the incoming code as soon as it has been run and displayed once?
The second eventuality seems excluded unless there are no further javascript actions on the client's side(?)
Danquest
Quick answer: No.
Why? Well, your browser (the client) effectively downloads assets like HTML, JS and CSS (along with images and other media objects), to render on the users machine.
Because all client code is downloaded to the client, the user can essentially do with the client code, whatever they wish to.
Server side code does not get to the client, because it is processed on the server, which then produces client translatable output...again, HTML etc. You only see the end result, with the source that produced it locked away on your guarded server.
Your best bet, is to simply minify and compress your JS assets. This won't do much against a savvy developer, but it may be off-putting to the casual thief.
In any case, theft is theft and if your code is found to be used by someone else's company, I guess you have a case to file a lawsuit against them...even though in a way, it's public code.
Make sure you put a license statement with all of your code, so that you're legally covered.

Add a new mailid in outlook by clicking on email id in a mail body

I want to generate a mail body in which i want to make a link, on which user clicks and add new contact outlook popup opens into the client screen.
How this can be done??
This is what vCard was invented for. Create a vCard file (from Outlook or using a third party application), and host it online on some webspace. Or, if needed, you can create a webpage that generates the vCard dynamically. Simply add a hyperlink to the vCard URL to the email message body.
Upon clicking upon the URL, Outlook will open up the contents from the vCard as a new Outlook contact.
That is, if Outlook isn't setup to block URLs, in which case you'd be better off sending the vCard as an attachment. Outlook signatures can be setup to contain a vCard.
I'm afraid this will most likely turn out to be impossible. Scripting is usually taboo in E-Mail clients.
This may be possible from within a web site using IE specific scripting (in VBScript, connecting to Outlook via COM or something), but security settings would block that from working for the vast majority of users anyway.

mailto: subject= and body= support in email clients

Does anyone know if when sending a html newsletter what kind of support the major email clients have for the subject= and body= parts of the mailto tag?
The behavior varies by both email client and source application. Here's a likely enough example from my own system, using pjp's link.
Send Mail
Mailto link followed within Outlook client successfully fills subject
Mailto link followed in IE successfully fills subject for Outlook client
Mailto link followed in Firefox fails for same Outlook client (subject text remains part of "TO" field)
I tried the same link in HTML emails read by gmail and Yahoo web clients.
Gmail correctly opens a new message with desired subject
Yahoo pre-fills the subject, but truncates at the space ("Hello" only)
That much variation on just one computer makes embedded mailto tricky to use. I bet that's why many email newsletters provide a "View as a web page" link in the header.
I imagine they've got quite good support for it. BUT!! But mailto will be used to send and email FROM the client TO me#somewhere.com . Thats definitely not you sending out a newsletter.
You'll have to send emails from the server, potentially in a background process.
EDIT:
Slight rethink. Are you talking about you using an admin section with a link with multiple TO addresses that will then open an email client to send out your newsletter? In which case, even though the major browsers probably do have decent support, you shouldn't rely on it out in the wild, since its not in the standard (I think), so they are not required to support it.
EDIT AGAIN:
rfc 2368 info in support of my previous edit

mailto: links and webmail

Is there a way to implement a mailto: link that works with webmail clients?
Edit - so a traditional mailto link is (as I suspected) not going to work. So has anyone seen anything similar to those rss buttons you see with a variety of the most popular sites on?
The links are handled by the user's browser. GMail has a client-side install (GMail Notifier) that lets you specify that you want GMail to handle all mailto links.
But there's no way for a web page to specify that it's mailto link should be handled by a webmail app (even if it could, how would you know which one?).
That's really more of a web client issue, it's already available for Firefox:
http://starkravingfinkle.org/blog/2008/04/firefox-3-web-protocol-handlers/
but ultimately it's down to the user to decide how their browser handles mailto links.
Create a text file named MailtoWebMail.reg with the following content...
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command]
#="\"(BrowserExecutable)\" (Parameters)"
where (BrowserExecutable) is replaced with the complete path to your browser (ie. C:\Program Files\Internet Explorer\iexplore.exe)
and (Parameters) is replaced with the appropriate line for the mail service as described below...
GMail
"http://mail.google.com/mail/?view=cm&fs=1&to=%1"
Hotmail
"http://hotmail.msn.com/cgi-bin/compose?To=%1&mailto=1"
Yahoo Mail
"http://compose.mail.yahoo.com/?To=%1"
Netscape Mail
"http://webmail.netscape.com/compose.adp?mailto=%1"
Mail.com
"http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=%1&compose=1"
Opera Web Mail
"http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=%1"
Note: There should not be a blank line after the [HKEY_LOCAL_MACHINE] line
MikeB
I am just brainstorming here. You might be able attach a Javascript handler to the link that asks the user if s/he wants to login to a webmail account (along with a list of providers). If you have the correct URLs for the webmail providers, you would then be able to invoke them on the basis of the user's choice. If the user answers no, return true from the handler and presumably the link would work normally.
See, for example, http://toric.blogspot.com/2005/07/gmail-compose-link.html and http://blog.monstuff.com/archives/000238.html
Here are 2 Opera UserJS examples that you can inspect to give you and idea of how you can do it on a regular pages. (Obviously, UserJS-specific functions wouldn't work in a regular page, but you can use regular events.)
This one catches left-clicks on mailto links and opens them in Gmail for example. It can also handle forms.
http://shadow2531.com/opera/userjs/BeforeMailtoURL.js
This one catches all mailto actions, has a more generic parser (that supports any hname and not just to, cc, bcc, subject and body) and has a better format string syntax:
http://shadow2531.com/opera/userjs/BeforeMailtoURL.zip
Basically, you have to find a way to intercept mailto link actions. You can do this with click event listeners on links and submit listeners on forms (if you really want to support forms). (It's easier to use a click event listener on the whole window and just filter it to find mailto actions. That way, you catch mailto links that are dynamically added at some arbitrary time.)
Or, you can just run through the page and process all the mailto links.
But, if you want to intercept mailto actions in the address field, via window.open or document.location etc., you'll need something like HTML5's registerProtocolHandler or something like Opera's webmailprovider.ini support. You can use registerProtocolHandler in Firefox, but by default, it's restricted to the domain you set it on.
So, basically, you either convert mailto links to http(s) webmail compose URIs up front, or at the time the mailto action is invoked. The latter works much better.
Converting a mailto link to a webmail compose URI involves a few things. First, you need to know what query string variables the webmail accepts. Then, you need to parse the mailto URI to split it up into the parts you want. Then, you need to decode and re-encode (to normalize) those parts. Then, you need to join multiple occurrences of hvalues together. And, you need to handle things in a case-insensitive manner and check for and escape unsafe characters and %HH etc.
For the parsing, you can do a quick and dirty regex, but you'll get better results with a full mailto URI parser and normalizing functions.
So, if you just want to handle left-clicking on links, you can do that cross-browser. For more than that, you have to use any hooks the particular browser gives you.
Hypothetically, assuming the webmail client passes arguments through the authentication process (or the user is already authenticated), I don't see why this is so impossible. It can't be done in the simple mailto: way, but it'd be possible to provide a selection of links to popular webmail services and use Javascript to intercept clicks on mailto: links such that the user is presented with a drop-down list of possible webmail services (or their local email client). The links would carry the To:/Subject: address but formed in whatever structure that webmail service requires.
If you're using a Google Apps email account (hosted email), than Gmail Notifier will not work. You can use a bookmarklet though, to change all of your mailto: links to links that point to your webmail.
Here's a bookmarklet I wrote to do just that, it will highlight all fixed links in red.
javascript:for(var i=0;i<document.links.length;i++){var a=document.links[i];if(a.href.indexOf('mailto:')==0){a.href='http://mail.google.com/a/sample.com/mail?extsrc=mailto&url='+a.href;a.style.backgroundColor='red';a.style.color='white'}};return true;
Just be sure to change http://mail.google.com/a/sample.com to whatever the proper hosted address is for you.
I suppose this will work with a number of other email clients if you just change that link around.
Kind of an old thread, but nobody has quite answered it yet, so here goes.
As blesh nearly says above, while there's no way to get "mailto:" to go to Gmail, there's another way to skin this cat that works just fine in many situations. Just change the URL. Remove the "mailto:" prefix and insert "https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=".
This seems to work like a charm, whether or not the user is coming in through Google Apps. If the user is not logged in, he'll be walked through that step, and then Gmail will still kick off a new message. The only downside I've noticed is that if (when?) Google decides to change their bookmarking scheme, this may need a bit of tweaking.
It may make sense to perform this transform either before or after the URL is in the DOM, depending on your situation.
Oh and double click the MailtoWebMail.reg to insert the command into your registry.
MikeB
Has anyone seen numbers indicating what percentage of webmail users have configured their systems with plugins etc. to properly have mailto: links sent to their browser / webmail system rather than to a desktop app? This seems critical in deciding whether to use mailto: links on a site or a contact form, but I'm having trouble coming up with numbers to guide the decision.