Tutorial: HTML5 – the basics on stacking elements with position: and z-index:


Source Code & Working Example

If you’ve ever tried to make a popup window, like toast(), or a dialog, like alert(),  and you’ve been frustrated by the process, this tutorial should help. NOTE: This code will work in your webbrowser and a mobile device; adding config.xml will allow it to build with Phonegap Build.

When trying to do a popup window, there are three important things to know:

  • positioning
  • stacking (or z-index)
  • hiding the popup

In this article I cover, stacking – or when and how to use z-index. Reminder, “stacking” allows HTML elements to overlap each other. Hence, using stacking allows overlapping to take place. This tutorial will use the “Working Example” linked at the top of the article.

Previously, I covered positioning in another article Tutorial – Text Overlay on to an Image with CSS.

Hiding the popup will be covered in a future article. I will add that link here, when it is done.

Important Note on Using z-index

z-index will only work on an element whose position property has been explicitly set to absolute, fixed, or relative.

Setting Up the Popup



If you look in app.css, you will see:

#stack1 {left:50px;top:50px;}
#stack2 {left:70px;top:70px;}
#stack3 {left:90px;top:90px;}

From this code, it appears that the stack1 should start before stack2 and stack3, but with the image with the caption START, this does not appear to be the case.

A closer look at index.html shows:


A bug in wordpress requires me make this an image.

In this case, simple moving the <div> with id=stack1 above id=stack2 will solve the issue. However for this example we are going to use the z-index to place the element how we want it.

Simple Examples with z-index



However, when we do it the results are not what we expect. If we click the button labelled doit, the code below gets executed and the results are shown in the image DOIT. It is not quite what we expect. The order is correct, but for some reason the red element is transparent. (more on this later)


document.getElementById('stack1').style.zIndex = -1;


The alternative to this is to move the other two (2) elements so they are above the red element. If we then recycle the page and click the button labelled doit2, then we see the effect we have been desiring (DOIT2). The code below shows the method.



document.getElementById('stack2').style.zIndex = 2;
document.getElementById('stack3').style.zIndex = 3;

It is also worth noting that we could have set the z-index of both elements to the value of two (2) and gotten the same result.

Closing Comments

This very simple example was to show four (4) things that should now be obvious

  1. Overlapping HTML elements is available with the natural stacking order.
  2. When the natural stacking order of HTML does not work, use z-index.
  3. Sometimes things do not work as expected.
  4. Sometimes the longer approach works better.

To be clear, when you write HTML – the first element will stack below the second element, and the second element will stack below the third element, and so forth. This is called the “natural stacking order” (or the stacking order based on appearance). So when an element needs to overlap above other elements and it is not in the “natural stacking order”, use z-index. For more details on z-index see below.

Said another way, if you plan the order of your HTML elements correctly, you will not need to use z-index.

Lastly, above I said I would talk about the transparent issue. In the README.md there is a link to an article:

What No One Told You About Z-Index by Philip Walton

In this article, Philip presents the lesson as a challenge to solve a problem. He solves the problem by using opacity. As you read it, you’ll find out why we got a weird outcome earlier, and about “stacking context”. Note: opacity produces a side effect used with stacking.

Video: Top 10 Performance Techniques for PhoneGap Applications

Common Sense and Rocket Science

Common Sense and Rocket Science

In 2013 at Adobe MAX 2013, Christophe Coenraets – Developer・Speaker・Writer, and Developer Evangelist at Salesforce, did a talk entitled Top 10 Performance Techniques for PhoneGap Applications. The talk was video taped and is available on AdobeTV and his weblog.

This blog post is a break down of this video and the ten (10) techniques he spoke of. All ten (10) points are listed below in the order given. The numbers on the right hand side are approximate time marks where Chris discusses the subject.

  1. Don’t generate the UI on the server  ~ 5:00
  2. Don’t wait for the data to display the UI ~10:40
  3. Cache what you can
    1. Cache static data ~ 14:00
    2. Cache some dynamic data, appropriately
    3. Cache element (id) selectors ~ 17:40
    4. Pre-compile templates ~ 20:00
  4. Use CSS transition and hardware acceleration  ~ 23:00
    1. http://github.com/ccoenraets/PageSlider
  5. Avoid the 300ms delay & possibly use fastclick.js ~ 31:00
  6. Load images from one composite image ~ 37:45
  7. Limit shadows and gradients ~ 42:00
  8. Avoid reflow/re-rendering/re-layout/re-drawing the DOM ~ 43:15
  9. Do you need that framework? ~ 50:00
  10. TEST (with real data & real devices & a bad network) ~ 52:00

Summary of talk slide ~ 53:20

Slightly related to this topic is:

Crockford’s Javascript Style Guide from 2007

In this 2007 presentation at Yahoo!, which is meant to be the beginning of a three-course sequence (followed by “Theory of the DOM” and then “Advanced JavaScript”), Douglas Crockford explores not only the language as it is today but also how the language came to be the way it is.

Tutorial: HTML5 Dynamic Font Resize

Source Code & Working Example font-sizes

Every modern webbrowser today has variable font sizes. There are two reasons for this: 1. It was a fairly trivial addition for browser makers. 2. It made the web more accessible to people with disabilities. On the later, it is important to note as the population grows older, vision becomes strained – and therefore adding an option to resize fonts is an important feature.

NOTE: This Working Example works in your webbrowser and on your mobile device; adding config.xml will allow it to build with Phonegap Build.

Today with responsive web, it is a matter of a few lines of code. However, there are a few issues that you will run into.

  • One issue is where to hook the font-size change.
  • The other is margins and padding.

Both of those will be covered after a walk through the example. Note, if you have trouble with the buttons, recycle the webpage.

Initial Size

font-size = 100%

font-size = 100%

The default size set for the <html> element is font-size=100%. In the emulator, the page layout looks very similar to the image with the caption font-size = 100%.

Bigger Size

font-size = 125%

font-size = 125%

If you click the button [bigger], the entire page will have the all the fonts increased in size – to 125% of the original. The emulator results are visible in the image with the caption font-size = 125%. The code to change the font-size looks like this:

document.body.parentNode.style.fontSize = '125%';

Smaller Size

font-size = 75%

font-size = 75%

If you click the button [smaller], the entire page will have the all the fonts decreased in size – to 75% of the original. The emulator results are visible in the image with the caption font-size = 75%. The code to change the font-size looks like this:

 document.body.parentNode.style.fontSize = '75%';

Hooking the font-size Change

If you look at the code in app.js, you will see the modifications to the font-size made three (3) different ways. The code snippet below outlines the different methods. For all intensive purposes, the first two (2) lines are equivalent.

document.getElementById('allOfIt').style.fontSize = '100%';
document.body.parentNode.style.fontSize = '100%';
document.body.style.fontSize = '100%';

The first two (2) references above are for the document element – the one and only <html>. The third reference is for <body>. They will all do the same thing, when you make a change to fontSize.

However, if you change to <body>, you will notice that the [reset] for the first two (2) references (<html>) do nothing at all. This is because the changes are compounding (or inherited, or scoping – depending on your point of view). This means, if make the font bigger for <html>, then that makes the font bigger for <body>. IF THEN, the final font size is 125% bigger for <html> + 125% bigger for <body>. In px this means, we start with 16px, then increase by 125% for <html> – making it 20px, then increase by 125% for <body> – making it 25px!

In the end, <body> seems to be the better choice. However, even after making this decision. There is another hidden pitfall, namely – margins and padding.

margins and padding

When I design my pages I do NOT use px or percent (%); as px is fixed and would require me to hunt down every instance of px and change it — And percent (%) would require similar. I use em, but even this has the infamous css compounding problem (google search link).

So you should be aware that for dynamically font resizing, there are two (2) possible solutions – em and rem.

  • em is equal to the size of the font that applies to the parent of the element. (So, this suffers from compounding.)
  • rem is equal to the size of the font that applies to the root html element, not the parent element.

In general, em works for padding, and rem works for margin. However – excluding headers, I tend to stick to one font. So, you’ll have to make your own judgement – but be diligently consistent!

Sidenote, some designers use 0.625em as a design reference. This Google search will help you research this point.

Bottom Line

Having Dynamic Font Resize is fairly trivial, but requires diligence when design – even for mobile device.


Kerri Shotts has suggested also adding a user device preference from phonegap-plugin-mobile-accessibility.