Fixed Position Misbehaviour in Ie11

Fixed position misbehaviour in IE11

For a quick solution add transform separately for IE, in IE only css hack.

@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
  .header, #bar-left{
      left: 0;
      transition: all .5s;
  }
  .shiftnav-open .header, .shiftnav-open #bar-left{
     left:590px;
  }
}

How to properly apply a css hack for IE11 transition misbehaviour

Instead of the .fullscreen-container, can you try to apply the style to .forcefullwidth_wrapper_tp_banner class?

IE (11) improper handling of CSS multi-columns?

As I am myself very interested in this question I studied the spec and some examples of multi-column layouts.

First I have to say that the spec is horribly "imprecise"!

But it seems that any break definition has precedence over the column-count value (though I could not find it explicitly in the spec or anywhere else).

This only happens if, according to the multi-column pseudo-algorithm, the respective element, which sets the break point, is already part of the last column (as in your example fiddle).

The example given by @GCyrillus (see comments on question) just works, because the height setting forces the algorithm to first fill the given height before additional column boxes are created in the inline direction.

You can see the "original" effect, if you change the height from 20em to 10em!

So after all, I tend to say that it is not a bug and IE behaves correctly.

At least it might be an error or shortcoming of the multi-column algorithm to not recalculate or refill the columns so that despite any breaks the column-count value is respected. Logically this can only be done as long as the number of defined break points is one less than the column-count value.

As actually IE 10+ is the only browser supporting the multi-column module including the break-xy properties, it is hard to tell if the behaviour is right or wrong and how other browsers will handle this in the future!

For now, I would recommend to not use these properties at all.

Slider misbehaving

I've figured out somehow

.shiftnav-wrap { 
  margin-top: -1px; /* thank you very much @zgood, logotext / menu is not jiggling anymore :) */
}

html {
  overflow-x: hidden; /* adding this line to hide the horizontal scrollbar that appear on slider closing phase */
}

#scroll_totop {
  top: 850px; /* instead of bottom: 25px to prevent disappearing */
}

@media screen and (-webkit-min-device-pixel-ratio:0) { 
  .bar-side > div {
     position: relative; /* to keep in place the jiggling left sidebar */
     margin-top: 612px;
   }
}

.bar-side > div {
  position: relative; /* to keep in place the jiggling left sidebar */
}

Also, setting these transition-delay: .0s will make the slider translate in the same time with the wrapper and the sidebar text will remain uncovered by the slider in the opening phase.

@media screen and (min-width: 767px) {
    .shiftnav-open .shiftnav-wrap {
        -webkit-transition-delay: .0s;
        -moz-transition-delay: .0s;
        -ms-transition-delay: .0s;
        -o-transition-delay: .0s;
        transition-delay: .0s
    }
}

Javascript Misbehaving in IE until Dev Tools Opened - Not Console-Related?

This is because opening the developer console temporarily disable IE 11s caching mechanism when requesting an external file via the AJAX request.

Solve it by adding a simple timestamp so the request always appear to be fresh:

$.getJSON('?getdata=1×tamp='+$.now(), function(data) {

Why you have to do this, you ask?
Beats me. Maybe it lies within the realms of jQuery.

a script on this page is causing ie to run slowly

Get yourself a copy of the IBM Page Profiler:

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=61d74777-1701-4014-bfc0-96067ed50156

It's free (always a win). Start it up in the background, give it a few seconds, then refresh the page in IE. Go back to the profiler and it will list out all the resources used on the page and give you detailed profile information - in particular where JavaScript is taking a long time to execute.

It should be a good start to finding the source of your problem.

If the script tags are inline, I'd suggest creating a local copy of the file and separating out the script tags to separate files if you can.

---

Related Topics