On the form is correctly displayed but can't be submitted.Īs you may already know, the Outlook Desktop version uses MS Word as its HTML rendering engine, and this explains most of its issues. Forms element were either completely dropped (IOS version) or else rendered as plain text (Outlook 2013), as you can see in the screenshot below: Overall, Outlook delivered the worst results in the test: the form wasn't rendered on either Outlook 2013/Win 7 or on IOS. #OPERA MAIL CLIENT FIELD CREATED FORMAT WINDOWS#The XHTML version is almost the same save for a handful of some language-specific differences.įirst of all: changing the doctype made no discernable, difference, as both the HTML5 and the XHTML doctypes provides the same result.Īll the client I've tested correctly displayed the form, with the exception of Outlook for Windows and IOS. Both versions have passed the W3C validator. I ran two test with HTML5 and XHTML 1 strict doctypes. I built a very simple mail: it contains a sample of main form elements:įor each of them I provided a default value and, in addition, the input text field had a required attribute. On the positive side, things have not changed very much from what they describe, but out of curiosity, I decided to run some of my own tests with a simple form on some email clients. I searched the web for information on email form compatibility, but only found a handful of (mostly old) articles on the subject: Obviously you can't use a unique link to save both satisfaction and comment, so, if you decide you don't want to send users to a web page, you'll need to add a form to your email. The safest and simplest way to do that is to add a link to each smile with a specific variable to record the user choice. In cases like this we are not talking about something that can be solved with a simple web link. There may be usecases where adding a form to an email is raised as an option – maybe to increase the impact of a message or to stimulate immediate user interaction (for example, to ask for a comment). In addition, you now lost the ability to perform client-side validation on email forms because JavaScript and HTML5 form constraints are inconsistent. Users will still need to submit the form to a web page, so there is really no extra convenience in terms of usability. It’s a good one since I personally don't believe there currently is a good reason to embed a form in an e-mail. So, the first question is: why would to want to use forms in email?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |