BCWhich meta tag is the best for Responsive?
Personally, I like to include at least 3 metatags in my emails, to save from any potential future headaches or other pains.
<meta name="format-detection" content="telephone=no">
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=no;">
<meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />
My preferred viewport tag is a little more verbose compared to the ones in most boilerplates, but I find that it also solves the most headaches for me. Also, I like including the format-detection tag, since even random number strings can, at times, be considered phone numbers and are turned into links on mobile devices.
Finally, the IE Edge tag. This one has a funny story as to why I always include it. I had a boss that always insisted on using the 'compatability mode' button on IE. She actually didn't know what the button did, or why. I started including the EDGE metatag, which strips the compatability mode button from even showing up, and it has saved me a LOT of headaches. Also, since it's been announced that including IE Edge also makes responsive work with Windows Phone, I consider it a win-win. What are your thoughts, guys?
Here's what I typically include:
<meta charset="utf-8">Sets character encoding to utf-8 which is going to work for most cases. Can be changed to different character set as needed.<meta name="viewport" content="width=device-width">I go with the simpler width=device-width. If everything is built correctly, forcing initial-scale shouldn't really be necessary and I agree with other commenters that disabling user zooming is a bad UX practice.<meta http-equiv="X-UA-Compatible" content="IE=edge">Just a little bit cleaner version of IE=edge. Should accomplish the same thing as what you're using.As far as
<meta name="format-detection" content="telephone=no">, I considering this to be a similar issue to disabling zooming. Disabling default functionality is typically a bad practice if it can be avoided. I've found that phone numbers, addresses, etc are typically in emails much more often than random strings, so I typically just handle the random strings on a case by case basis instead of disabling the correct telephone functionality across everything.In addition, because I do a large amount of reviewing designs in the browser with clients, I include the following in projects using a flag that removes it for actual builds/sends:
This disables caching and removes the need to have to explain to clients how to clear their cache to see updates.
Personally, I prefer dealing with phone #'s and addresses as links myself, even going as far as wrapping phone #'s with tel: links and addresses with google maps links. I'd rather set a certain behavior beforehand versus allowing the phone make decisions for me.
Good point about using
width=device-widthvs.initial-scale=1.0. I've also updated my start templates. Cheers!Love this, going to use it in my emails from now on!
Also, thanks for adding it to the Learning Center article I wrote :-)
Is there a reason why we would want to set
user-scalable=nofor emails? In an app that has zooming functionality, it makes sense to disable the phone's zooming function. In emails and most websites, however, I don't think it's very good UX design to disable zoom.we usually avoid
user-scalable=no, so if people want to zoom in then they still canI usually also add
<meta name="apple-mobile-web-app-capable" content="yes"><meta content="yes" name="apple-touch-fullscreen" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
though admittedly they're very edge case (for the hosted link when viewed in iOS)
I used to keep those three in as well, but I've found with testing it doesn't add anything extra.
And as for user-scalable, maybe i should take that one off mine.
If I have it set, I don't want an 'accidental pinch' to make the design unreadable.
I wouldn't use the viewport tag anymore! This causes an issue on Windows Phone 8, as the device-width is replaced with the screen resolution. So, if you're using a 100% table, it will display your email at 1280px width. Read more about this issue at http://mattstow.com/responsive-design-in-ie10-on-windows-phone-8.html
Hold your horses. Just because there are issues in Windows Phone certainly doesn't mean you should remove the viewport meta tag. It's certainly needed for proper scaling in iOS and Android native mail clients, which have far more users.
Secondly, I believe this only applies to the
@-ms-viewportdirective in CSS, not the viewport meta tag. I find the viewport meta tag works perfectly fine on Windows Phone.Lastly, if you are adamant about using
@-ms-viewport, I would suggest the following media queries:Hi Michael, I tested this (yes, with Litmus) and I don't see any difference in scaling at iOS and Android, nore at other email clients.
So I really believe we don't have to use the <meta name="viewport" content="width=device-width"/> for emails.
In my test, the media query with @-ms-viewport didn't work for WP8.
Looks like the issue may be fixed, if you read to the very bottom of the link you provided.
Unfortunately that only counts for page rendering, not for this issue with emails. I discovered this today after complaints from one of our clients (with a Windows Phone 8). So the Litmus-tests and the actual smartphone gave the same result.
Yikes, that's unfortunate.
did you try to use the viewport tag in in combination with forced 4.01 HTML & vml? I put this one in cuz our boss is viewing the emails on outlook Win7 Application. I tested my new 2017 layout (3 months ago) and it worked good on all clints (exept for notes 7 & 8).
this worked just fine for me for now I did not see the issue on windows Phone =/