Rule 'Transform: Translatey' in Menu Doesn't Work Properly When Menu Is Loaded in Multiple Pages Through Iframe

position:fixed not playing nice with off canvas menu in Chrome and IE

Here is a work-around that requires very little changes.

It works consistently in the latest versions of FF, Chrome, and IE11/10.

Updated Example

.sbContent-one {
  overflow: visible;       /* Or remove overflow-x: hidden */
}
.sbMainContent {
  overflow-x: hidden;
}
.sbMenuTrigger {
  position: static;        /* Or remove position: fixed */
}

The easiest way to resolve the issue in Chrome is to simply move the overflow from .sbContent-one to .sbMainContent. In doing so, you can't actually scroll past the .sbMenuTrigger element (which resolves the issue) since .sbMainContent is a sibling element.

There are currently many inconsistencies across browser around how fixed elements are positioned relative to elements that are transformed using translate3d. The issue in IE was due to the fact that fixed elements are positioned relative to the window without taking the elements that are transformed using translate3d into account. To solve this avoid fixed positioning completely, and add the element .sbMenuTrigger back into the normal flow by removing position: fixed (or overriding that with position: static, the default). In doing so, the sidebar expands as expected.

In other words:

Remove overflow-x: hidden from .sbContent-one (or override it with overflow: visible).
Add overflow-x: hidden to .sbMainContent.
Remove position: fixed from .sbMenuTrigger (or override it with position: static).

JQuery .load() function doesn’t work because file loaded contains small JS

The other page will be inserted after the script completes and the document is loaded, so the document.write will replace the current page.

Don't use document.write - use DOM methods to select and insert text instead, for example:

<p id="rights"></p>
<script>
  document.querySelector('#rights').innerHTML = `Copyright © ${new Date().getFullYear()}
  All rights reserved | This template is made with <i class="fa fa-heart-o" aria-hidden="true"></i> by <a href="https://colorlib.com" target="_blank">Colorlib</a>`;
</script>

(if all pages which include this subpage also use jQuery, you can use it instead of document.querySelector)

z-index is canceled by setting transform(rotate)

Let's walk through what is occurring. To start, note that z-index on positioned elements and transform by itself create new "stacking contexts" on elements. Here's what's going on:

Your .test element has transform set to something other than none, which gives it its own stacking context.

You then add a .test:after pseudo-element, which is a child of .test. This child has z-index: -1, setting the stack level of .test:after within the stacking context of .test Setting z-index: -1 on .test:after does not place it behind .test because z-index only has meaning within a given stacking context.

When you remove -webkit-transform from .test it removes its stacking context, causing .test and .test:after to share a stacking context (that of <html>) and making .test:after go behind .test. Note that after removing .test's -webkit-transform rule you can, once again, give it its own stacking context by setting a new z-index rule (any value) on .test (again, because it is positioned)!

So how do we solve your problem?

To get z-index working the way you expect, make sure that .test and .test:after share the same stacking context. The problem is that you want .test rotated with transform, but to do so means creating its own stacking context. Fortunately, placing .test in a wrapping container and rotating that will still allow its children to share a stacking context while also rotating both.

Here's what you started with: http://jsfiddle.net/fH64Q/
And here's a way you can get around the stacking-contexts and keep
the rotation (note that the shadow gets a bit cut off because of .test's white background):

.wrapper {    -webkit-transform: rotate(10deg);}.test {       width: 150px;       height: 40px;       margin: 30px;       line-height: 40px;       position: relative;       background: white;}.test:after {       width: 100px;       height: 35px;       content: "";       position: absolute;       top: 0;       right: 2px;       -webkit-box-shadow: 0 5px 5px #999; /* Safari and Chrome */       -webkit-transform: rotate(3deg); /* Safari and Chrome */       transform: rotate(3deg);       z-index: -1;}

<div class="wrapper">    <div class="test">z-index is canceled.</div></div>

Website responsive on desktop but not on mobile

It looks like you can solve your problem by adding this rule:

.navbar,
#home > .carousel-inner > .item {
    width: 100vw;
}

And it looks like you might need some further tweaks for those glowing particles on certain screen sizes.

Why are touch event listeners seemingly preventing the selection of google translate languages on the iphone or ipad?

The problem is that for the layout you've selected, the Google Translate widget opens the language options "dropdown" in a new iframe, and (long story short) hammer.js doesn't play nicely with iframe content (presumably reveal.js has the same issue).

You could try some pretty complicated means of working around the issue involving dealing with the events and the iframe content, but a much simpler solution is to use another layout that doesn't use the iframe, e.g. replace SIMPLE with HORIZONTAL or VERTICAL

function googleTranslateElementInit() {
  new google.translate.TranslateElement({
    pageLanguage: 'en',
    layout: google.translate.TranslateElement.InlineLayout.HORIZONTAL,
    autoDisplay: false
  },'google_translate_element');
}

I've updated your most recent fiddle here: http://jsfiddle.net/LfkLy/10/