Add mobile friendly meta tags to the html.tpl.php

Something for John to take a look at.

For the viewport meta tag, I prefer to use the following: width=device-width, target-densitydpi=160dpi, initial-scale=1

Users should be able to zoom, hence I don't use minimum/maximum.

I agree with lewisnyman in choosing option 1.

I personally use option 3, but to implement it for core requires including the iOS orientationchange fix script, and we run into the same issue as before when including third-party scripts. I propose we deal with option 3 together with including respond.js and other scripts into specific themes.

I prefer <meta name="MobileOptimized" content="width" /> so that it benefits older devices with screens sizes other than 320px.

The other meta tags in patch #7 look good to me.

1. The iOS orientation zoom bug is minor. And its easy (and obvious) for users how to work-around it; they just have to zoom out. For most designs the incorrect zoom level is obvious. I'm strongly opposed to adding a javascript fix for this. And preventing users from zooming in and out is also completely out of the question. Do nothing and let Apple fix the bug is the correct choice for us.
2. Agree with dcmouyard. MobileOptimized should be set to "width". Also that meta tag is missing documentation. Here's a URL: http://msdn.microsoft.com/en-us/library/bb431690.aspx
3. Here's a link for the HandheldFriendly meta tag: http://docs.blackberry.com/en/developers/deliverables/26991/Supported_me...
4. Link in comment for the cleartype meta tag points at generic docs about cleartype. The URL that describes the cleartype meta tag is: http://msdn.microsoft.com/en-us/library/bb159711.aspx
5. The viewport tag has a great URL for 2 of the 3 parts, but it lacks any docs about the target-densitydpi part. That was introduced by Android. Here's a URL: http://developer.android.com/guide/webapps/targeting.html
6. All URLs in the comments should be prefixed with: @see.

Nice job, Lewis!

I was reminded of this issue when I came across this note in normalize.css:

/*
Prevents iOS text size adjust after orientation change, without disabling user zoom
http://www.456bereastreet.com/archive/201012/controlling_text_size_in_sa...
*/
html {
-webkit-text-size-adjust: 100%;
-ms-text-size-adjust: 100%;
}

Interesting, no?

Lewis, I'll review the patch this weekend if someone doesn't beat me to it.

Just fixed a few minor coding style issues.

I've tested the most recent version of this patch and everything looks to be working properly. Tested on desktop, iOS and Android browser.

just one small thing I found during testing this issue: #1488754: Add mobile friendly meta tags to the Stark theme
for some older Android Browsers, if you zoom it triggers also a resize of the viewport, so this means it could load another layout. Which is kinda strange, because on the iOS it only really zooms and not triggers a viewport resize.
Interesting is, that the Android 2.3.5 Browser tries to guess to which area the user tries to zoom and then still changes the viewport, but automatically jumps to this area.
Tested also with newer Android 4.0 and there it looks that it works like the iOS zooming

There is also an issue for this for desktop browser: http://alastairc.ac/2012/01/zooming-bug-in-webkit/

A fix for this would be to disable zooming with "minimum-scale=1.0, maximum-scale=1.0, user-scalable=no" but this you already discussed to remove this from the code.

But I would leave as it is.

So also an RTBC by me

Regarding the target-densitydpi setting for the viewport meta tag, the following article discusses it in great detail. The author recommends against its use based on his testing. http://sunpig.com/martin/archives/2012/03/18/goldilocks-and-the-three-de...

mjohnq3 brings up a good point, and the article he linked to convinced me not to include target-densitydpi.

I'll create a new patch for this change.

In that article, they discuss why target-densitydpi=device-dpi doesn't work how you might hope. And then they conclude that you should never use target-densitydpi at all. But there is no discussion about using target-densitydpi with a specific dpi setting, like target-densitydpi=160dpi.

So, I don't see how that article convinced you not to use target-densitydpi=160dpi. Using a specific pixel density allows for a more consistent apparent font size across different devices with different densities.

I missed the part where they were only testing target-densitydpi=device-dpi rather than target-densitydpi=160dpi.

I believe most mobile devices default to 160dpi, but it's better to specify it in case there are any that don't.

The patch in #12 is probably the one to go with, but it would be great if anybody could test it in various devices just to be sure.

Also, catch brought up an interesting point in #1488756: Add mobile friendly meta tags to the Bartik theme on whether we should use hook_page_alter() or hook_preprocess_html() instead of hook_html_head_alter().

so I did some research with the target-density setting.

The target-densitydpi Settings define the browser how to render the Pixels in the Browser.
If you set it to target-densitydpi=device-dpi it uses the native Pixels which can lead into really small texts on highdpi screens.

Interesting is that Android and Opera have an setting for zoom, in the normal Android Browser it is called "Default Zoom" and has Settings for:
- Far
- Medium
- Close

In an Opera you can set Percentage from 100% to 300%.

Now this settings act exactly the same as the setting of target-densitydpi, it "zooms" the site for the user, but also with an viewport change, so a bigger zoom will also call a new mediaquery.

If you set now target-densitydpi=medium-dpi or target-densitydpi=160dpi this is the same and it is shown also the same way on a normal configured Browser, because medium-dpi is the default setting.
But the fun stuff happens if you now change the configuration of the Browser. Then in the normal Android Browser with "Default Zoom" -> Far it shows you the screen as you would set target-densitydpi=high-dpi, so the User still has the possibility to change the size of text, etc if he needs it (accessibility for example).
The Problem ist with Opera Browser, if target-densitydpi=medium-dpi is set, the setting for zooming is still there, but it does not work anymore (it works just after changing the setting, but after a refresh of the browser it jumps back to the setting). I think this is bad, because the zoom setting can also be used as accessibility for people with eye problems.

And because target-densitydpi=160dpi is the default in both Browsers I would suggest to remove the setting completely.
With this, people which need another zoom can use it.

So for me #17 is the way to go

#17 is RTBC

Schnitzel did another great review! And he addresses my concerns from #18. I'm fine with removing that property as long as we understand why we're removing it.

Just had a huge in-person bikeshed because of catch's comment in #3 of #1488756: Add mobile friendly meta tags to the Bartik theme. But we figured out a much better implementation. I'm going to write up a new issue summary while Schnitzel works on a new patch.

Updating title.

here is a first Version.

- Added the Metatags to html.tpl.php
- Added variable to theme.inc template_preprocess_html()
- Wrote a test which checks if the tags are actually shown

ToDo:
- Writing a test which checks if the tags can be hidden or overridden

let's hope :)

Missing http://

Expand issue summary

Second Version:
- forgot one tag
- changed from "mobile_metatags" to "default_mobile_metatags"
- added documentation on top of html.tpl.php

Slightly updated docs.
Changing to system component - we're going in...

New Version
- Added a new test which also checks if a module/theme can remove the Default Mobile Meta Tags via hook_preprocess_html()
- To be able to do this I also added a helper module to system module.
- Fixxed whitespace issues
- Some better Naming

Some whitespace fixes

oops, looks like I missed the whole helper module to add in the patch.

Let's try this one, also added the patch from alan.

doublepost

Overall, the approach is good. I just have nit-picky documentation and code style fixes.

+  // Mobile Metatags, used for Responsive Webdesign. Metatags are added in html.tpl.php
+  $variables['default_mobile_metatags'] = TRUE;

Streamline the code comment. How about: Display the html.tpl.php’s default mobile metatags for responsive design.

I don't think we need to capitalize responsive design either.

+ * - $default_mobile_metatags: (boolean) If TRUE, default mobile metatags for
+ *   Responsive Design will be included.

Let's make the docs more consistent with flags set in page.tpl and node.tpl: - $default_mobile_metatags: TRUE if default mobile metatags for responsive design should be displayed.

+  function setUp() {
+    parent::setUp();
+
+    // Create an administrative user.
+    $this->default_metatags = array(

Code comment is wrong here.

+    $this->default_metatags = array(
+      'MobileOptimized' => '<meta name="MobileOptimized" content="width" />',
+      'apple-mobile-web-app-capable' => '<meta name="apple-mobile-web-app-capable" content="yes" />',
+      'HandheldFriendly' => '<meta name="HandheldFriendly" content="true" />',
+      'viewport' => '<meta name="viewport" content="width=device-width, initial-scale=1" />',
+      'cleartype' => '<meta http-equiv="cleartype" content="on" />'
+    );

We should put these in the same order as in html.tpl.php.

+  /**
+   * Verify that the default mobile meta tags can be removed by a contrib module/theme
+   */

Needs a period. Also shorten to just: “Verify that the default mobile meta tags can be removed.” Since anything can change it, no need to list some things that can change it.

+      $this->assertRaw($metatag, t('Default Mobile meta tag "'.$name.'" generated correctly.'), t('System'));

+      $this->assertNoRaw($metatag, t('Default Mobile meta tag "'.$name.'" does not exist.'), t('System'));

How about "displayed properly" and "removed properly"? Also, the PHP string concatenation operators (.) need spaces around them.

+function system_module_test_preprocess_html(&$variables) {
+  $variables['default_mobile_metatags'] = FALSE;
+}
\ No newline at end of file

Need to add a newline to core/modules/system/tests/system_module_test.module.

So I bumped into Emma Jane and Morten and got to chatting about this patch.. as you do...
They made the valid point that the variable check isn't necessary.
A module doesn't need to decide whether a theme is responsive or not.
I couldn't come up with a use case either.
That's a theme layer decision.
So we can remove the variable, and the check.
If a site wants to be 'non-responsive', the system html.tpl.php can be copied to the custom theme,
and the metatags removed.

A module doesn't need to decide whether a theme is responsive or not.

You are right if you don't want to be responsive you should remove the metatags. But what about this:
A Theme want's to change the Metatags (for example max-zoom:1). With the Setting it could make this:
Set default_mobile_metatags to FALSE, add his own metatags to the HEAD via hooks.

If we don't have the default_mobile_metatags check, the only possibility for the theme would be that it has to ship the html.tpl.php in the theme, which I don't like so much.

But in the end, in both cases a Theme has a full control.

Another thing is: If you want to use for example Bartik (which will be responsive) but you want to disable responsiveness. The only possibililty would be:
- hack core and change the html.tpl.php
- create a subtheme which only changes this (realy hard for non themer/devs)

With the default_mobile_metatags Setting, Bartik could ether provide a setting for this, or a contrib module can implement a setting for this.

btw, check the issue summary, it has all this things in =)

updated the patch with Johns inputs. thx!

+++ b/core/modules/system/html.tpl.php
@@ -22,6 +22,8 @@
+ * - $default_mobile_metatags: TRUE if default mobile metatags for responsive ¶

+++ b/core/modules/system/system.test
@@ -880,6 +880,51 @@ class AdminMetaTagTestCase extends DrupalWebTestCase {
+      'apple-mobile-web-app-capable' => '<meta name="apple-mobile-web-app-capable" content="yes" />',      ¶

Trailing whitespace.

Since I'm already posting, I might add that I also think killing the variable would be a good idea. That seems a perfectly good use-case (one of the few, probably) for overriding html.tpl.php. My two cents...

fixxed whitespace.
Regarding the variable I leave the decision to John.

Ahh, dammit, I found one more thing. I agree that the variable/no-variable issue can be handled in a follow-up.

+++ b/core/modules/system/system.test
@@ -880,6 +880,51 @@ class AdminMetaTagTestCase extends DrupalWebTestCase {
+      $this->assertRaw($metatag, t('Default Mobile meta tag "' . $name . '" displayed properly.'), t('System'));
...
+      $this->assertNoRaw($metatag, t('Default Mobile meta tag "' . $name . '" removed properly.'), t('System'));

We don't do concatenation inside of t(). Either use @name or simply omit the t() per #1380620: Remove t() from test assertions.

Well I might as well fix this myself.
This is RTBC, but I'll let someone have another look at it. It seems JohnAlbin is cool with this (#37).

Sorry, forgot the patch.

Reviewed, looks good! Go RTBC go!

What a lovely productive issue this is. Schnitzel: did you already post that photo of all the devices you tested on during mobile sprint? :)

@yoroy
yes, here: http://twitpic.com/8yngav :)

Hate to step in when we have reviewed & tested by the community but I am not sure about 'initial-scale=1.0'. HTML5 boilderplate recently removed it (see https://github.com/h5bp/html5-boilerplate/issues/824). To summarise the reasons from there

1.) it means messy JS hacks like the meta viewport JS fix are not needed.
2.) we stop seeing lots of sites that either a.) break on rotate/zoom b.) fail to pinch/zoom until the second gesture occurs
3.) it lets iOS perform it's default system behaviour, keeping in-line with user expectations.

I have been doing it in recent projects and it works well and the experience in ios is much nicer.

We can't include the "apple-mobile-web-app-capable" tag by default.

When a page gets added to the home screen this tag removes Safari's toolbar. It a good idea for 'single page' web apps but for a collection of pages it has a detrimental effect. This can't be a good default.

Removing it sounds good to me.

Hate to step in when we have reviewed & tested by the community but I am not sure about 'initial-scale=1.0'.

It's been so long since I added that to my pages, I don't remember why its there. :-\ Removing that will mean we need to retest in various mobile devices.

We can't include the "apple-mobile-web-app-capable" tag by default.

agree, could lead into behavior a sitebuilder would not expect.

It's been so long since I added that to my pages, I don't remember why its there. :-\ Removing that will mean we need to retest in various mobile devices.

If it fixxes a bug in iOS we should remove it, But I'm not 100% sure if the responsive design would still work the same. Definitely have to retest. I hope I find some time next week.

The patch is missing system_module_test.module and system_module_test.info that were added in previous patches.

+++ b/core/modules/system/html.tpl.php
@@ -43,6 +45,13 @@
+      <meta name="apple-mobile-web-app-capable" content="yes" />

This should also be removed. It was removed properly from the tests, but not from the actual template.

Looks good code-wise, but I can't judge the actual tags, so leaving for someone to give this a final lookover before marking RTBC.

Just tested with lewisnyman on Android 2.3, there was no styling, but it did follow the expected behavior that he listed.

+++ b/core/modules/system/system.testundefined
@@ -946,6 +946,50 @@ class AdminMetaTagTestCase extends DrupalWebTestCase {
+  /**
+   * Implement getInfo().
+   */

Not necessary.

+++ b/core/modules/system/system.testundefined
@@ -946,6 +946,50 @@ class AdminMetaTagTestCase extends DrupalWebTestCase {
+  /**
+   * Verify that the default mobile meta tags are added.
+   */

Should start with Verifies...

+++ b/core/modules/system/system.testundefined
@@ -946,6 +946,50 @@ class AdminMetaTagTestCase extends DrupalWebTestCase {
+  /**
+   * Verify that the default mobile meta tags can be removed.
+   */

Same.

Also all modules and themes now need to be in its own directory (see #1299424: Allow one module per directory and move system tests to core/modules/system), so it should probably be moved to its own directory core/modules/system/tests/modules/system_module_test/, like the other system test modules.

Otherwise, this looks good and well-tested!

Tor's comments are code formatting. If someone can re-roll with those changes, I can verify and then mark RTBC. We don't need to test on devices again since Lewis's and Zachory's reviews were excellent.

Rolled new patch.

#64: mobile-meta-tags-1468582-64.patch queued for re-testing.

Thanks, looks good!

Committed to 8.x. I think it can have interesting effects between now and when 8.x. is released.

This patch introduced a HTML5 validation error: #1717090: Remove the http-equiv="cleartype" meta tag.

Improve formatting.

Issue tags aren't Twitter hashtags. :-)

This patch has been removed, so the meta tags are no longer present currently in html.tpl.php, searching for the issue where that was done.

The metatags are still present, although the code no longer looks like it did in the patch above (particularly after the twigification of the templates).

updated problem motivation: apple-mobile-web-app-capable removed based on comment at #50

On comment's #49 & #51, I wanted to add some docs about initial-scale=1.0

Apple's has some docs on Viewport definitions.

But there are a few blogs talking about the importance of properly setting the Viewport so that users can continue to control the Zoom on their device. Viewport : adieu width=device-width and Five Fundamentals of Accessible Responsive Web Design.

The optimal RWD code looks like this:
<meta name="viewport" content="width=device-width, initial-scale=1.0" />

There was no discussion about why this was dropped, so I'm adding back in. If this should be a new issue, do let me know.

This is also consistent with what is in core/vendor/phpunit/php-code-coverage/PHP/CodeCoverage/Report/HTML/Renderer/Template which may be irrelevant, but found while grepping around.

If you run a web page with these meta tags, MobileOptimized, etc. through W3 validator at http://validator.w3.org these tags give an error -

Keyword mobileoptimized is not registered.

The error report helpfully says

"You can register metadata names on the WHATWG wiki yourself."

So I'd suggest someone who knows the details of these tags does that to stop pages failing validation.

Or are these in fact the right keywords to use?

I haven't found that the W3C's validator is well supported. This is already in Core <meta name="MobileOptimized" content="width" />

Similar issue with <meta name="HandheldFriendly" content="true" />

This is not part of the patch in #76. It's also being questioned here:

http://stackoverflow.com/questions/13871836/html-meta-tags-for-mobile-de...
http://stackoverflow.com/questions/1988499/meta-tags-for-mobile-should-t...

But my assumption is that the issue is with the W3C. Their HTML5 setting is still marked as experimental after all.

They have another validator here:
http://validator.w3.org/mobile/

Probably all based on W3C Recommendation 29 July 2008:
http://www.w3.org/TR/mobile-bp/

@LewisNyman and @mgifford - I also agree with the decision to add back in the "initial-scale=1.0" attribute to the viewport meta tag.

There was a previous IE10 for Windows Phone 8 bug which had previously been causing issues in landscape mode (chopping off a decent chunk of the screen), however this has since been resolved with a recent updated pushed to Windows Phone 8 devices (see http://mattstow.com/responsive-design-in-ie10-on-windows-phone-8.html#th... for more info).

The benefits of adding this back in will significantly improve the usability and experience on the admin side in landscape orientation, especially on iOS devices.

Before:
iPhone 5 - Landscape - Without Initial Scale Set

After:
iPhone 5 - Landscape - With Initial Scale Set

hi all,
I'm using Commerce Kickstart (commerce_kickstart-7.x-2.12) than is responsive template.

Looking in Google Webmaster Tools it says I have to configure Viewport for mobile devices and tell me this instructions to proceed:

"Recommendations

Pages optimized to display well on mobile devices should include a meta viewport in the head of the document specifying width=device-width, initial-scale=1.

"

I'd tried with an iPhone 4 but everything looks and works fine.
Must I use this patch #76 viewport-initialscale-1468582-76.patch, 1.22 KB, mgifford?

thanks in advance

PD: sorry I mistake posted it here where you are talking about drupal 8 :(

76: viewport-initialscale-1468582-76.patch queued for re-testing.

Nice to see that Google seems to agree.

You don't have to, but it is a best practice. It all depends if you want to allow users to continue to control the Zoom on their device or not.

76: viewport-initialscale-1468582-76.patch queued for re-testing.

In regards to this tag that hides the navigation in iOS Safari:

Found this info here (haven't tested to verify):

http://stackoverflow.com/questions/6582732/what-does-apple-mobile-web-ap...

A couple of caveats:

• This only works on the first page you load; any navigation away to another page will make the address bar and navigation buttons reappear. So if you want this to work, you have to build a single page website (for multiple 'pages' consider an Ajax page loading approach such as that used in the jQuery Mobile framework).
• This only works when you arrive at the web page via an application shortcut icon; if you navigate to the website directly from within Mobile Safari it has no effect.

Then there is styling the app status bar:
https://drupal.org/node/2225153

And, setting a startup image for iOS Safari:
https://drupal.org/node/2225151

Just some thoughts, but it might be nice to set a standard for Drupal out-of-the-box, and then allow users to customize whether these are added and in the case of the app status bar style, there could be a 3 item select dropdown for default, black, black-transparent.

I saw the most excellent presentation by Peter-Paul Koch (the quirksmode.org guy) at HTML5 DevConf on exactly what the intialscale meta tag did on different devices. Unfortunately, the video for his presentation is not yet online, it would be at https://www.youtube.com/playlist?list=PLAIXSzgkhDs6K1VjhryO4iGw5FKHgJ6lK, so keep an eye on it for it to be published later. The talk was called "Mobile Viewports" I believe. The closest thing I could find for reference was a recent blog post at http://www.quirksmode.org/mobile/metaviewport/.

I unfortunately can't recall all the details, but the short story is that you should use both device-width and initial scale (as recommended by the patch in #76).

In an attempt to summarize, basically "device-width" will only give you the portrait size "ideal" width on iOS devices but will give you the ideal width of whatever orientation you're in on others. This is why having device-width alone on an iOS device causes the page to render at the wrong zoom when in landscape mode.

However, if you set "initial-scale=1", then the device width reported to the browser will be correct on all mobile devices no matter what their orientation, except... dun dun dun, IE10. In which case it gives you the portrait ideal width all the time (basically the same problem as "device-width" on iOS devices).

If that's hard to follow I apologize, here's the chart summarizing the situation from that quirksmode blog post.

The savior for this situation is that apparently ALL browsers follow one rule: if both device-width and initial-scale are provided, calculate both and then choose the largest value. This makes it so that iOS will report the right width when in landscape mode by using initial-scale, and IE10 will report the right width by using device-width. Chrome, Opera, Blackberries, etc. will all report the right width using either value.

That's as best I can remember and research, but I'd suggest watching the entire original video when it becomes available on YouTube. In short, +1 for initial-scale from people who have extensively tested this already.

That's great. However, this is what it looks like on my iPhone 4S in Chrome & Safari:

Strangely, looks way better in Opera.

In that case, let's call it RTBC.

Awesome, thanks for the confirmation, quicksketch!

Committed and pushed to 8.x. w00t!