I'm developing a personal website, http://www.miketurley.com.
In any Webkit browser (Chrome, Safari) or Firefox, when you mouse-over the text on my site's opening screen, you get a slick animation which slides the text around and reveals the menu ("waking up" my website.) This may not be too necessary, but I like it and I think it's appropriate to showcase skills like that on my portfolio website.
Anyway, if you go to my website in Internet Explorer, the animations do not appear at all. The same duration of time goes by, and then the page "snaps" into the post-animation state in one frame, with no motion in between.
How can I fix this?
An explanation of this particular animation along with source code is available here: http://www.miketurley.com/index_explain.html
Leaving eval aside, you site is failing to quirks mode in IE. Using dev tools I switched to different Document Mode and the animations ran just nice. Can't find out what activates quirks right now but you have an issue to investigate. Start with passing the strict validation or moving to transitional or html5 <!doctype html>
Related
I'm working on a wordpress website that uses the fullpage.js plugin.
My main goal is to make it go fullscreen on iOS devices, latest versions are the main targets. By making it go fullscreen I mean getting rid of the ugly top and bottom bars, as you can see on this picture, in landscape mode those bars take up more than 25% of the space.
I've tried this, but of course all browsers are compatible except safari iOS.
I've also tried all tips I found on here like including the meta "apple-mobile-web-app-capable" but nothing seems to work.
On Apple devices in Safari, getting rid of the anchors option of fullPage.js will do the trick.
Not sure about other mobile phones or browsers, but it is well known browsers don't provide a way to deal with those bars and therefore there won't be much you can do about it.
I am using the jquery touch punch library to enable users to move images around via touch. This works fine in Chrome and Firefox but will not work in IE.
I find if I hold down on the image in IE a small square appears and I am able to drag the image within the boundaries of this square but no further. I guess this is the right click function kicking in.
I have looked around and most people are saying to add '-ms-touch-action: none' to the css of the draggable div. So I added that to the style attribute of the draggable div and it did nothing. I am still unable to drag in IE.
I've looked around for another alternative but am unable to find one. I have included jquery 1.8.1, jquery ui 1.8.23 and touch punch 0.2.2. Any help will be greatly appreciated.
I noticed the htm page I was launching containing the draggable div contained a meta tag which was emulating the page in IE9. 2 and a half days I spent on that! -ms-touch-action:none will definitely work in IE.
If you have come here and are experiencing the same issue but the above paragraph didnt fix it for you, try this:
In IE click the cog and go to Compatabilty View Settings and uncheck the box for Display intranet sites in Compatability View.
Chrome used to improperly exclude the scroll bar in its media queries. This means that with 1000px of visible space and a 17px scroll bar, other browsers would report 1017px as a width so far as Media Query is concerned, but webkit browsers (such as Chrome and Safari) did not do this.
These browsers could hit a specific size where a scroll bar would appear in one resolution, then change resolutions to another where it would appear, then it would go back to when it didn't... the solution caused an ugly blank space to appear where the scroll bar should, but it did not. It came out looking like a glitch, and the DOM resize events did not fire properly so it was not something you could react to properly in JS.
However, now in Chrome 29, this appears to have changed. Now they are going off of how the specification works and including the scroll bar in their media query calculations... just like Firefox and Internet Explorer (and how the specification says they should have all along). This fixes the bugs, but causes another problem in that the JS to try to detect the Chrome/Safari issue now will have false positives, because it is not a concern with newer versions of Chrome and I assume eventually Opera and Safari as well.
In light of all of this, I cannot find any information anywhere on when this was fixed in either Chrome or Webkit. I hate having to resort to browser version testing in my JS to work around these flaws, but I am just guessing blindly on Chrome 29+ for the moment as a temporary patch and would love an authoritative answer... I have tested in Safari 6.0.5, but the old method is still being used...
Does anybody know in what version of Chrome and/or Webkit this was fixed?
Chrome is no longer using the webkit engine as of Chrome v. 28 it now uses the Blink Rendering Engine. So no need to be detecting this for chrome unless you need it for previous versions.
For more on Blink: Blink Documnetation
For more on the Release: Next Web Article on Webkit/Blink Switch
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I have recently used a JQuery plugin called cycle to create slides of general HTML content in my homepage (www.inspirastudios.com). Everything looked OK in Firefox and Chrome but while browsing the site with a client I got the ugly surprise of Internet Explorer 7 rendering my slides within an ugly gray background. Do you know:
how to solve this, or
any decent javascript slideshow/carousel/slider library that supports general HTML (not only images), previous and next slide activation buttons?
Nivo slider has all the features that you are looking for. http://nivo.dev7studios.com/
You might be facing the following problem: jquery cycle IE7 transparent png problem