Problem/Motivation

In order for legacy desktop-based websites to work in mobile devices, mobile browsers implement a virtual viewport that is much larger than the actual dimensions of the device. If you just use media queries to create CSS layout to be used for different device dimensions, the mobile browsers will ignore the media queries that match the actual device dimensions (because they are using a virtual viewport.)

In order to get mobile browsers to ignore their default virtually-large viewport and instead use the actual device dimensions for the viewport, you have to set some special meta tags. These meta tags are documented, but not standardized. Lewis gives a quick summary in the original issue description below.

The best meta tags for broad-device support, usability and accessibility are:

<meta http-equiv="cleartype" content="on" />
<meta name="MobileOptimized" content="width" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="HandheldFriendly" content="true" />

Since Drupal 8 will be released in 2013 and could have a 3 year lifetime, we really need to assume that 99% of sites built then will be responsive. So adding this tag should be the default, but still overridable for the 1% use-case.

Proposed resolution

So how do we add these meta tags to core? And who are the developer groups that need to work with these meta tags?

  1. Theme developers creating a new theme and who are fine with the defaults. They could potentially copy/paste PHP snippets (though we'd like to avoid this).
  2. Theme developers creating a new theme who want to tweak the defaults.
  3. Module developers that want to provide a configuration for these tags or need to alter these tags for other reasons.

So let's step through the problem:

  1. If we put the meta tags in each theme's template.php via drupal_add_html_head() or #attached, then:
    • For themers who like the defaults, they have to manually copy the PHP snippet examples from core themes and create their own template.php. — SAD PANDA
    • For themers who don't like the defaults, ditto above — SAD PANDA
    • For module developers, they'll use the hook_html_head_alter() as normal — WIN
  2. If we put the meta tags in system.module via drupal_add_html_head(), then:
    • For themers who like the defaults, they are already available without any work — WIN
    • For themers who don't like the defaults, they'll have to use implement hook_html_head_alter() in template.php and change a render array — SAD PANDA
    • For module developers, they'll use the hook_html_head_alter() as normal — WIN
  3. If we hardcode the meta tags in system's html.tpl.php, then:
    • For themers who like the defaults, they are already available without any work — WIN
    • For themers who don't like the defaults, they can override html.tpl.php as normal and make their changes — WIN
    • For module developers, they'll be unable to alter the meta tags without hook_theme_alter() hackery. — SAD PANDA
  4. If we add <?php if ($default_mobile_metatags): ?> around these specific meta tags in system's html.tpl.php file:
    • For themers who like the defaults, they are already available without any work — WIN
    • For themers who don't like the defaults, they can override html.tpl.php as normal and make their changes — WIN
    • For module developers, be able to set the $mobile_metatags variable to false and then they'll be able to use drupal_add_html_head() or #attached as normal — WIN

#4 is a compromise, but its still a win for all types of users of these tags.

apple-mobile-web-app-capable removed based on comment at #50

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.

Remaining tasks

  • Patch review
  • Simple tests — Add tests to check that setting $mobile_metatags to false turns off the meta tags.

User interface changes

None.

API changes

Adds a $default_mobile_metatags variable that's available in HOOK_preprocess_html().

Original report by lewisnyman

Common tags include:

// W3C best practice http://www.w3.org/TR/mwabp/#bp-viewport
// Supported by: iOS, Android, Palm Pre, Blackberry, Windows Phone 7
<meta name="viewport" content="width=device-width, target-densitydpi=160dpi, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"> 
//Non standard
<meta name="HandheldFriendly" content="True" /> //For older dumb phones. Palm and Blackberries.
<meta name="MobileOptimized" content="320" /> //Older "Windows Mobile" Phones
<meta name="apple-mobile-web-app-capable" content="yes"> //iOS only, runs in full screen mode when added to the home screen. https://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html
<meta http-equiv="cleartype" content="on" /> //Enable clear type for Windows http://www.microsoft.com/typography/whatiscleartype.mspx

The only controversial one is "user-scalable=no". I think it makes sense for and 'app' theme but not for a content focused theme. I'm happy to leave it out for now if it means we can get this in sooner.

Files: 
CommentFileSizeAuthor
#76 viewport-initialscale-1468582-76.patch1.22 KBmgifford
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 66,694 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
#64 mobile-meta-tags-1468582-64.patch4.49 KBjanusman
PASSED: [[SimpleTest]]: [MySQL] 35,467 pass(es).
[ View ]
#57 mobile-meta-tags-1468582-57.patch5.15 KBdcmouyard
PASSED: [[SimpleTest]]: [MySQL] 36,289 pass(es).
[ View ]
#54 mobile-meta-tags-1468582-54.patch4.03 KBdcmouyard
FAILED: [[SimpleTest]]: [MySQL] 36,270 pass(es), 4 fail(s), and 0 exception(s).
[ View ]
#49 mobiletags-1468582-45.patch4.56 KBedward_or
PASSED: [[SimpleTest]]: [MySQL] 35,816 pass(es).
[ View ]
#45 mobiletags-1468582-44.patch4.59 KBtstoeckler
PASSED: [[SimpleTest]]: [MySQL] 35,728 pass(es).
[ View ]
#42 mobiletags-1468582-42.patch4.6 KBSchnitzel
PASSED: [[SimpleTest]]: [MySQL] 35,743 pass(es).
[ View ]
#40 interdiff-36-40.txt3.72 KBSchnitzel
#40 mobiletags-1468582-40.patch4.61 KBSchnitzel
PASSED: [[SimpleTest]]: [MySQL] 35,746 pass(es).
[ View ]
#36 mobiletags-1468582-35.patch5.02 KBSchnitzel
PASSED: [[SimpleTest]]: [MySQL] 35,740 pass(es).
[ View ]
#35 mobiletags-1468582-35.patch5.02 KBSchnitzel
PASSED: [[SimpleTest]]: [MySQL] 35,722 pass(es).
[ View ]
#33 ab-1468582-reposive-meta-33.patch3.78 KBalanburke
FAILED: [[SimpleTest]]: [MySQL] 35,702 pass(es), 5 fail(s), and 0 exception(s).
[ View ]
#32 mobiletags-1468582-31.patch3.97 KBSchnitzel
FAILED: [[SimpleTest]]: [MySQL] 35,687 pass(es), 5 fail(s), and 0 exception(s).
[ View ]
#31 ab-1468582-reposive-meta-tag.patch3.21 KBalanburke
PASSED: [[SimpleTest]]: [MySQL] 35,684 pass(es).
[ View ]
#30 ab-1468582-reposive-meta-tag.patch3.22 KBalanburke
PASSED: [[SimpleTest]]: [MySQL] 35,687 pass(es).
[ View ]
#29 mobiletags-1468582-28.patch3.41 KBSchnitzel
PASSED: [[SimpleTest]]: [MySQL] 35,686 pass(es).
[ View ]
#27 mobiletags-1468582-27.patch2.84 KBSchnitzel
PASSED: [[SimpleTest]]: [MySQL] 35,688 pass(es).
[ View ]
#17 seven-mobile-meta-tags-1468582-17.patch2.28 KBdcmouyard
PASSED: [[SimpleTest]]: [MySQL] 35,644 pass(es).
[ View ]
#12 seven-mobile-meta-tags-1468582-12.patch2.67 KBdcmouyard
PASSED: [[SimpleTest]]: [MySQL] 35,146 pass(es).
[ View ]
#10 seven-mobile-meta-tags-1468582-10.patch2.27 KBLewisNyman
PASSED: [[SimpleTest]]: [MySQL] 35,118 pass(es).
[ View ]
#7 seven-mobile-meta-tags-1468582-7.patch2.04 KBLewisNyman
PASSED: [[SimpleTest]]: [MySQL] 35,111 pass(es).
[ View ]
#5 seven-mobile-meta-tags-1468582-5.patch2.06 KBLewisNyman
PASSED: [[SimpleTest]]: [MySQL] 35,084 pass(es).
[ View ]
#2 seven-mobile-meta-tags-1468582-2.patch1.78 KBLewisNyman
PASSED: [[SimpleTest]]: [MySQL] 35,071 pass(es).
[ View ]
#1 seven-mobile-meta-tags-1468582-1.patch1.77 KBLewisNyman
PASSED: [[SimpleTest]]: [MySQL] 35,074 pass(es).
[ View ]

Comments

Assigned:Unassigned» LewisNyman
Status:Active» Needs review
StatusFileSize
new1.77 KB
PASSED: [[SimpleTest]]: [MySQL] 35,074 pass(es).
[ View ]

I've gone and made a patch! Let's see what happens....

StatusFileSize
new1.78 KB
PASSED: [[SimpleTest]]: [MySQL] 35,071 pass(es).
[ View ]

I've removed the white space errors.

Assigned:LewisNyman» Unassigned

Assigned:Unassigned» JohnAlbin

Something for John to take a look at.

Issue summary:View changes

Added explanation comments

StatusFileSize
new2.06 KB
PASSED: [[SimpleTest]]: [MySQL] 35,084 pass(es).
[ View ]

I've created a new patch with explanation comments in the code.

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.

StatusFileSize
new2.04 KB
PASSED: [[SimpleTest]]: [MySQL] 35,111 pass(es).
[ View ]

For anyone who is unaware there is a bug in iOS where the zoom does not get reset when switching orientation. This creates a disorienting experience. There are three options:

  1. Do nothing and just let the bug stay.
  2. Add min and max scale. This fixes the bug at the expense of removing the ability to zoom in on the page. This is common across 'web apps' but is slightly controversial. (The previous patch does this)
  3. Add a javascript fix for the problem.

I think it's essential we get the other parts of the viewport tag in soon, so we can begin creating a better mobile experience. I'm going to resubmit the patch going along with option one. I think we should come back to this orientation issue down the line. This bug might not exist a year from now.

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.

Assigned:JohnAlbin» Unassigned
Status:Needs review» Needs work
  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!

Status:Needs work» Needs review
StatusFileSize
new2.27 KB
PASSED: [[SimpleTest]]: [MySQL] 35,118 pass(es).
[ View ]

Brilliant. Thanks John. Here's the updated patch based on your comments.

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.

StatusFileSize
new2.67 KB
PASSED: [[SimpleTest]]: [MySQL] 35,146 pass(es).
[ View ]

Just fixed a few minor coding style issues.

Status:Needs review» Reviewed & tested by the community

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...

Assigned:Unassigned» dcmouyard
Status:Reviewed & tested by the community» Needs work

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.

Assigned:dcmouyard» Unassigned
Status:Needs work» Needs review
StatusFileSize
new2.28 KB
PASSED: [[SimpleTest]]: [MySQL] 35,644 pass(es).
[ View ]

Status:Needs review» Needs work

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.

It's also important to scale the touchscreen targets. We don't want them getting any smaller on high dpi android devices.

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

Status:Needs work» Reviewed & tested by the community

#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.

Status:Reviewed & tested by the community» Needs work

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.

Title:Add mobile friendly meta tags to the Seven themeAdd mobile friendly meta tags to the html.tpl.php

Updating title.

StatusFileSize
new2.84 KB
PASSED: [[SimpleTest]]: [MySQL] 35,688 pass(es).
[ View ]

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 :)

Status:Needs work» Needs review

Issue summary:View changes

Missing http://

Issue summary:View changes

Expand issue summary

StatusFileSize
new3.41 KB
PASSED: [[SimpleTest]]: [MySQL] 35,686 pass(es).
[ View ]

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

Component:Seven theme» system.module
StatusFileSize
new3.22 KB
PASSED: [[SimpleTest]]: [MySQL] 35,687 pass(es).
[ View ]

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

StatusFileSize
new3.21 KB
PASSED: [[SimpleTest]]: [MySQL] 35,684 pass(es).
[ View ]

StatusFileSize
new3.97 KB
FAILED: [[SimpleTest]]: [MySQL] 35,687 pass(es), 5 fail(s), and 0 exception(s).
[ View ]

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

StatusFileSize
new3.78 KB
FAILED: [[SimpleTest]]: [MySQL] 35,702 pass(es), 5 fail(s), and 0 exception(s).
[ View ]

Some whitespace fixes

Status:Needs review» Needs work

The last submitted patch, ab-1468582-reposive-meta-33.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new5.02 KB
PASSED: [[SimpleTest]]: [MySQL] 35,722 pass(es).
[ View ]

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.

StatusFileSize
new5.02 KB
PASSED: [[SimpleTest]]: [MySQL] 35,740 pass(es).
[ View ]

doublepost

Status:Needs review» Needs work

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 =)

Status:Needs work» Needs review
StatusFileSize
new4.61 KB
PASSED: [[SimpleTest]]: [MySQL] 35,746 pass(es).
[ View ]
new3.72 KB

updated the patch with Johns inputs. thx!

Status:Needs review» Needs work

+++ 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...

Status:Needs work» Needs review
StatusFileSize
new4.6 KB
PASSED: [[SimpleTest]]: [MySQL] 35,743 pass(es).
[ View ]

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

Status:Needs review» Needs work

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.

Status:Needs work» Needs review

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).

StatusFileSize
new4.59 KB
PASSED: [[SimpleTest]]: [MySQL] 35,728 pass(es).
[ View ]

Sorry, forgot the patch.

Status:Needs review» Reviewed & tested by the community

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 :)

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new4.56 KB
PASSED: [[SimpleTest]]: [MySQL] 35,816 pass(es).
[ View ]

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.

Status:Needs review» Needs work

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.

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.

Here's the concurrent issue from HTML5 boilerplate.

We should rip it out.

Status:Needs work» Needs review
StatusFileSize
new4.03 KB
FAILED: [[SimpleTest]]: [MySQL] 36,270 pass(es), 4 fail(s), and 0 exception(s).
[ View ]

Status:Needs review» Needs work

The last submitted patch, mobile-meta-tags-1468582-54.patch, failed testing.

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.

Status:Needs work» Needs review
StatusFileSize
new5.15 KB
PASSED: [[SimpleTest]]: [MySQL] 36,289 pass(es).
[ View ]

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.

Test Pages:
Stark - Home page
Seven - /admin/structure
Bartik - Not tested because it is still fixed width.

Expected behavior:
Page fills the whole of the mobile screen without horizontal scrollbars.
Pages are zoomable.
No weird orientation bug on iOS devices

Tested in:
iOS Simulator Safari (4.3.2)
Opera Mobile Emulator (HTC Desire presets)
iPhone 3GS Safari (iOS 5.1)
iPhone 3GS Opera 7
iPhone 3GS Dolphin
Ripple Emulator (Blackberry Curve 9300)
Nokia N900 Maemo default browser (Gecko based)
Nokia N900 Maemo Firefox
iPad 3 Safari (iOS 5)

All these tests passed. Sadly my Android test unit has bitten the dust so if anyone could help out there we should be good to go.

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

Status:Needs review» Reviewed & tested by the community

Ok my Android came back to life and worked great:

Sony Ericsson X10 Mini (Android 2.1)

+++ 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!

Status:Reviewed & tested by the community» Needs work

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.

Status:Needs work» Needs review
StatusFileSize
new4.49 KB
PASSED: [[SimpleTest]]: [MySQL] 35,467 pass(es).
[ View ]

Rolled new patch.

Status:Needs review» Needs work
Issue tags:-mobile, -#d8mux

The last submitted patch, mobile-meta-tags-1468582-64.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+mobile, +#d8mux

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

Status:Needs review» Reviewed & tested by the community

Thanks, looks good!

Status:Reviewed & tested by the community» Fixed

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

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

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

Issue summary:View changes

Improve formatting.

Issue tags:-#d8mux+d8mux

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).

Issue summary:View changes

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" />

Issue summary:View changes
Status:Closed (fixed)» Needs review
StatusFileSize
new1.22 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 66,694 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

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.

I'm happy with this change. I'll for some others to weight in before RTBC.

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 :(

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.

Status:Needs review» Needs work

The last submitted patch, 76: viewport-initialscale-1468582-76.patch, failed testing.

Initial scale does allow for zooming. It's the min/max scale values and user-scalble that disable it.

Status:Needs work» Needs review

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.

Status:Needs review» Needs work

The last submitted patch, 76: viewport-initialscale-1468582-76.patch, failed testing.