The majority of HTML emails and boilerplate that I've seen coded by other people, always declare a viewport meta tag.
I mindfully always avoid declaring a viewport and strive for a very high level of cross/backwards compatibility.
Declaring viewport settings render the email totally unusable for any of your audience using a Blackberry and overall is very poorly supported by any client.
Is there a reason to use this tag that I missed? Why are the majority of other peoples emails I see using this?
Additional Reference: http://www.emailonacid.com/blog/details/C13/emailology_viewport_metatag_rendered_unusable
If you want blackberry to work then by all means do not declare your viewport tag. Also don't nest tables, that will break the layout on blackberry too.
however, your other (vast majority of) mobile users will suffer. They will be able to pinch and zoom which can break your layout, I've also heard of resizing issues on high ppi screens without viewport, and I've had problems with horizontal scroll bars on my emails when I tried to go without it as well.
My current client has a huge email list. I forget the precise open stats, but versus the iphone and android's 100-140k opens each, blackberry opens accounted for 400.
of course one of their higher ups (above our contact for them) was the guy that just would not get rid of his ancient rolly ball blackberry and was pretty upset that he wasn't seeing anything. It took a while for us to convince them that dropping legacy blackberry support was the right move.
Read this I hope this will help
http://dev.tutsplus.com/articles/quick-tip-dont-forget-the-viewport-meta-tag--webdesign-5972
The viewport meta is worth using as it is also used by
http://htmlemailboilerplate.com/ using the following values
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
Related
I'm finishing up a Mailchimp template and Gmail is the biggest headache now.
In my head I have some styles (css) and media queries. If I put the media-queries at the bottom - it stops most of the styles from getting through. If I put the media queries at the top - all my styles work perfectly but the mail looks "broken down" (like it should under 600px width / Mobile) like the media queries already kicked in.
Firstly I didn't think Gmail should read anything inside of a media-query and secondly why are is my mail shown "responsive" when I have full browser width?
---- on a side note ---- I know I can go through everything and add inline styles but, I have three templates and I'd rather not if I can get away with it :)
I found out through extensive google-ing that I'm not the only one in the world that had this (weird) problem. I quote Lucas Mainardi below that posted an answer to a similar problem for Outlook.com.
Basically, putting an extra style tag with your media queries just before the closing body tag will fix things.
I've tested on my devices (gmail, iphone, thunderbird) and it doesn't seem to do any damage for clients that didn't have problems before. I'm also waiting for my Mailchimp inbox inspections to finish (where I test more clients like Outlook, Android etc). I'll edit my answer if it seems to do any harm, otherwise consider this a solution.
Hello James,
In the comments bellow I posted a possible solution to this issue in Outlook.com.
The problem seems to be the area in which the email is loaded. Apparently, the area starts out in a small size and is resized a few seconds later, but in that time the media queries fire up and display the mobile version. This is because the media queries are read first in the hierarchy of the code (they're at the head section) and the HTML email is read second.
The solution I found is to place the style section which contains the media queries after the HTML e-mail, specifically right above the closing body tag.
I tried this out in Litmus and all seemed to work just fine across the board (no other browsers/mobile devices/e-mail servers seem to be affected negatively, displaying the exact same version of the email with the styles in the head section).
Taken from http://emailwizardry.nightjar.com.au/2013/08/28/media-queries-in-html-email-cover-all-your-bases/
I have a very large (as in feature-rich) responsive website. It consists of over 150 different UI pages, and so far both rendering and performance on mobile are fine (I'm using an iPhone5 to test, and occasionally other devices).
Except for one page, which I am coding now. Here's the temporary dev URL:
http://www.jungledragon.org/apps/jd3/daylight
On Mobile Safari, this page performance extremely poorly:
- It takes several seconds to load, much slower than all other pages
- Once loaded, a touch scroll can take 5-10 secs to do anything
- Mobile Safari as a whole becomes non responding or close to it
I'm trying to troubleshoot the root cause of the issue, but no luck so far. I cannot reproduce this on any desktop browser using a small viewport, not even on desktop Safari. On the desktop, I've inspected several web debuggers to check for any long-running processes, but found none.
Some explanation on what the page does:
It will try to detect your current location (using alerts I discovered this takes little time)
Based on your current location and the current date, it will calculate the sun times for the day. This too is nearly instant
Based on the suntimes, it will dynamically generate a table, and then finally show it on screen
Here's the what I am seeing in detail on mobile Safari:
The server response is fine, the page loads quickly and shows the site header soon
Next, the content body is blank and stays blank for several seconds (which I cannot explain)
Finally, the suntimes table renders.
This completes the page, yet as of this point, the page as well as the browser are extremely sluggish, scrolling takes forever, and Safari controls are nearly irresponsive. It looks and feels as if the browser can crash any moment.
Based on my research so far, and given fine performance in all other pages on the site, I'm totally in the dark on what causes this.
Edit: Using BrowserStack I did some more tests:
iPhone 4S: no issues
iPhone 5S: no issues
Galaxy SII: no issues
HTC One X: no issues
iPhone 5: same issue as above
So I'm not seeing the issue on any desktop browser, and on no mobile device except for the iPhone 5 (iOS7).
Edit2: adding more findings and explanation based on comments received:
The issue does not seem animation-related. For this I have a number of proof points. A simple proof point is the page does not do any visual rendering that is much different from any of the other 100+ pages on the site which have no performance issue.
The 2nd proof point can be explained by understanding what is going on in this specific page. What happens is this:
The system will detect the current user's time and location. For now assume that the user actually allows location sharing. Using a simple alert, I've been able to proof that location detection is not the bottleneck.
Based on the user's time and location, the daylight periods are calculated. This is done by using the Suncalc JS library (https://github.com/mourner/suncalc).
The Suncalc library returns an array of daylight periods for the given date and location. I render that array as a table with colored background rows. That is all.
Rendering a table with 12 rows and different background colors is not likely to cause such enormous issues. My theory therefore lies in step 2 being the root cause. The Suncalc library has a lot of advanced math in it. I am thinking (without evidence yet) that either my mobile processor is horrible at those kind of operations, and/or the specific calculation for some reason cause a peak in memory usage (or even a leak).
As an additional proof point: once the page is loaded on mobile, use the right arrow next to the date to navigate to "tomorrow". Again you will see the extremely bad performance. During that step, there is no network activity, no location detection, nothing, just calculations and some very simple rendering. This validates my theory that perhaps the issue lies in the calculation.
Sadly, it looks like native Javascript profilers on that platform are non-existent. You may also want to try the Javascript Microtime function referenced in this answer. You will need to seed your script with calls at points where you think the bottleneck might be.
Just ran this through Chrome remote debugger (https://developers.google.com/chrome-developer-tools/docs/remote-debugging) on my S3, and it looks like Modernizr's cancelZoom function (showing up in jd3_0006.js) is getting called recursively too many times or by too broad a selector. I've uploaded the profiles into dropbox: https://www.dropbox.com/s/kubxk44smm6qqkx/jungledragon_debug..zip
You can import them into Chrome's debugger on the "Profiles" tab.
I believe your performance problem centers around the use of navigator.geolocation.getCurrentPosition() in your runMap() function
if (urlDate != null) {
urlPos(latitude,longitude);
} else {
if (navigator.geolocation) {
$(".img-loading").show(100);
navigator.geolocation.getCurrentPosition(successPos, errorPos{maximumAge:600000,timeout:10000});
} else {
errorPos('');
}
}
Consider using watchPosition() instead with a callback which will not halt processing of the script thread. You can cancel the watchPostion() update by using clearWatch()
So I've played with this some more, and ran the "Timeline" feature on Chrome (load this file into your chrome timeline tool: https://www.dropbox.com/s/2vpl6z1ntuk3aqj/TimelineRawData-20140328T105820.json), and it looks like this might be your main problem.
Your scripts and libs (including loading Google Maps and jQuery) are getting evaluated AFTER parsing the HTML and running Google Analytics because they are at the bottom of the body, not head. Unless you have a very good reason to do that, I would recommend moving those to the head.
There seems to be a separate problem with scrolling, but perhaps it will be resolved by this change.
I have a problem regarding fixed positioning that works on desktop(as expected), but doesn't work in any of the responsive testing tools in which i tested.
The site in question is this one: http://www.claytoncheung.com/
The problem is with menu div, it is set to position:fixed. Please don't ask why it is not set to absolute, i will only say that it can only be set to position:fixed. The reason is the limitations of the CMS that i use, i lost two days on various jQuery solutions to insert the menu dynamicaly, but unfortunately due to limitations in CMS none of these solutions worked.
The problem is that it is a multi language site, and the menu is not an ordinary one, since it is a one page site, so i am left with position fixed.
I tested the site in these tools:
http://www.responsinator.com/
http://mattkersley.com/responsive/
http://iphonetester.com/ and many more, but in all of them the menu doesn't take fixed position relative to the viewport, but to the parent element.
Please if anyone would take a look at the site to see how it should be and then try some of these tools to see the problem, or even better to check live on iPhone, which unfortunately i can't do.
If anyone could close this question, the problem was with my media queries, not with position fixed. After two days it just came to mind this moment.
I recently was requested to put together a Flash site. Since I did that, I of course need to follow up with sister site that will work with handheld devices etc.
I put a site together which looks, for example, fantastic on the Blackberry, but the resolution of an iphone is so good that the site looks microscopic. What is an elegant way to deal with these resolution disparities?
Also, I just used PHP to check the browser type and feed different pages based on that, I didn't actually make a mobile subdomain or use special mobile code.. those days are over right? Or am I committing semantic crimes by treating it like a normal-but-different website?
Thanks for everyone's input.
CSS Media Queries were specifically designed to solve this problem.
Check out the article on Responsive Web Design over at A List Apart
Example site: A List Apart CSS Media Query Example
Another great example/tutorial: http://webdesignerwall.com/tutorials/css3-media-queries
another: http://hicksdesign.co.uk/
another: http://colly.com/
Resize the width and height of this window to see what the media queries are doing. (also, view the underlying css)
Update: Please disregard, my problem was caused by an advertisement bar being inserted by the vendor who provides my workplace wireless service.
I was building a mobile friendly website and wanted to use HTML 5. However when I specify the doctype as <!DOCTYPE HTML> , I get a gap at the top of the page on safari on the iphone.
I notice that other sites have the same problem such as nextstop.com and nike.com
I guess safari does not fully support HTML 5 yet. Anybody know of a workaround?
HTML 5 is still in a very unstable state. Don't use it in a production environment.
Edit Just so you guys know what it's about, HTML 5 is currently an Editor's Draft, and the document clearly states (in the Status of This Document section) that this specification is not stable, and that a consensus may not have been reached on any of the proposed sections. I think it should be clear enough that it means it's a bit early to start using it.
All browsers correctly interpret the HTML doctype. Putting it in sets your browser into Standards Compliant mode, that is the only difference with or without the doctype.
You can use a CSS reset tool like http://meyerweb.com/eric/tools/css/reset/ to get rid of default margins and padding on all elements.