Don’t forget the notch!

Namaste!

The new iPhone cometh, and with it comes a new design challenge. The dreaded “notch”! Although the whole phone is a screen, Apple has placed what is essentially a Microsoft Kinect at the top to house cameras, microphone, and infrared sensors. This means that anything top dead-center in the screen will be blocked. What is a designer to do!

Luckily, the good people at Apple have given us some options. One is to use the viewport meta tag. Huh? What’s that? Well, if you open up the inspect tool on your browser and look at any web page you’ll see something like:  

<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=0">

So let’s break this down. First, using the name="viewport" we are telling the browser that we are going to issue some instructions about controlling the page dimensions and scale. Next, within content="" we pass in our parameters. In this, case we are saying that the width of our page should be the width of the browser/device using width=device-width. For some layouts, we could pass in a specific viewport size like width=600, or set the height with either device-height or height=300. The next parameter initial-scale tells the browser that we want the page displayed at normal size, not zoomed in or out. This is a little bit of an untruth when we consider higher-resolution screens where a pixel is not a pixel. Finally, we have minimum-scale,maximum-scale, and user-scalable. These parameters control whether or not the user can scale and what the limits of scaling should be. The other place that these are used is in regulating how your pages will display when a mobile device is rotated.

So, getting back to the initial problem. With the new iPhone, our current Divi pages will have a chunk taken out of the top-middle by the notch. We have two challenges – first, we have to stop Divi from injecting the viewport meta, and second, we have to put our own in its place.

Challenge 1

As of Divi 3.0.76, the viewport info in added to the head with the following function.

function et_add_viewport_meta(){
    echo '<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />';
}
add_action( 'wp_head', 'et_add_viewport_meta' );

Basically the function just squirts a line of code into the header using echo. The code is being added using the wp_head hook. If you aren’t sure what that means you can look back at one of my earlier tutorials. We will start by eliminating this action using the cleverly title WordPress function, remove_action. There are several ways that this could be done. In the past, I’ve advocated placing it into your child theme ‘functions.php’ file. Some experts say that this isn’t correct because if you inactivate or change your theme, those changes will also disappear. In this particular case, if we de-activate Divi, we also remove the function that is injecting the viewport meta, so a child ‘functions.php’ file is actually the right place. However, in the spirit of teaching, I’ll bring up another way that will maintain your changes, even with a theme change.

We are going to set-up our new function as a plugin, more specifically, a “must-use” plugin that won’t appear in the plugin list. Navigate to your WordPress installation ‘wp-content’ folder. If there isn’t a ‘mu-plugin’ folder, create it. Within that folder create a file called ‘custom-functions.php’. This name isn’t essential, it will just remind you what is actually being stored there, name it what you would like. Now within that file you need to put in a header to tell WordPress to load in your custom functions.

<?php

/**
* Plugin Name: Custom Functions Plugin
* Description: This plugin contains all of my awesome custom functions.
* Author: Robert Means
* Version: 0.1
*/


/* Your code goes here. */

?>

Next, we will add in our code.

add_action('wp_head', 'replace_the_viewport', 9);
function replace_the_viewport(){
    remove_action('wp_head', 'et_add_viewport_meta', 10);
}

First I put in an add_action to pass WordPress when I want my function called during the page creation cycle. In this case, I am passing in the $tag, wp_head. As you can see in the picture, wp_head hooks your function in near to the end of the head. When we actually look at the priority, the Divi function is running with a default priority of 10. This is important because we need to tell the WordPress engine that we want to remove the Divi function before it is able to run. So, I’m loading in my custom function with a priority of 9 and passing my function as the callback, ‘replace_the_viewport’.

Unlike add_action, remove_action must be called from within a function rather than being passed a callback. So, we have placed it within the ‘replace_the_viewport’ function. We are passing in three different arguments to the remove_action. The first is the $tag hook where the action we want eliminated is being hooked, in this case, wp_head. Second is the actual name of the action, ‘et_add_viewport_meta’. The third is a priority value that has to match the priority of the original action, or 10. So to recap, hook your custom function in before the action you want to remove, but pass the same priority as the action to be removed to the add_action function.

Okay, if we save this and fire up a page from our site in the browser we should see that the viewport meta has been removed.

Challenge 2

Next, we have to add back meta data appropriate for the new screen. In this case, Apple has written a new meta tag into iOS 11, viewport-fit. This tag can recieve three different values: contain, cover, and auto. The third and the first are essentially the same at the moment. Both restrict fixed elements within the “safe” area, essentially not allowing display of fixed elements where the notch is located. This can cause problems with properly displaying those fixed position elements. The second,cover, says to use the whole viewport, including the area under the notch.

Depending on your design, you can decide which of these to use. Luckily, Apple has given us some additional CSS parameters to facilitate using cover which I will explain in later in the article.

Now we need to inject our own viewport meta back into the pages. We can do this by adding an echo line to the same function we used to remove the Divi meta. Simply place the following line after the remove_action():

echo '<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />';

I have chosen to use cover and allow users to zoom. From an accesibilty standpoint, I think this is more proper. Saving and reloading our page will now show the new viewport meta being injected into the head.

If we decide to use cover, we still have to think about the silly notch.

Unknown Challenge

Along with the new meta, Apple has delivered some CSS constants to help out. They are:

There meanings should be fairly clear. These values can be used in padding or margins to make sure that your element isn’t cut off by the notch. You can also add it directly to the body of the page. ‘But wait!’, I hear you yell. ‘Why not just use contain then?’ Well, contain will place bars on each side of the browser to prevent problems with the notch. If you have a colored background this will result in potentially ugly white bars on each side of your content. ‘Simple!’, you say, ‘Just color them the same as your background.’ All well and good if your whole page has the same background color. Depending on the design of our page, using cover along with the new constants can give us the best look.

As always, I’m always up to answer any questions. Hit me up by email or in the comments section.

Metta!