This problem occurs in Firefox and Chrome, but Safari is fine. IE8, however, in compatability mode or not, doesn't load the overlay over the top (it just sits at the top, scrolling the content down - although I guess this is because the overlay is at the top of the markup).
It also doesn't show the image I'm attempting to show, but shrinks the overlay loading image to nothing in the top left of the screen. I am using the standard colorbox-min and the CSS that goes with that.
Inspecting the markup in the IE8 dev tools seems to hint that the content is not actually loaded into the cboxLoadedContent div.
$(document).ready(function() {
$('a[rel="preview"]').colorbox(
{
photo: true
, maxWidth: '95%'
, maxHeight: '95%'
, photoScaling: true
}
);
});
basically the page is a list of media images and when you click one it gives you the preview and allows you to scroll through ones on the page
well at least it does in FF took a little screenshot as it was shrinking the overlay thingy http://dumpt.com/img/viewer.php?file=7s2zwoxozzf7666h0fzc.png
Anyone have any ideas?
I expect my explanation is not great, so maybe I could take a movie of it or something if needed.
Is your code wrapped in a ready function? I've seen instances where code that works in FF/Safari fails in IE because IE seems to load the DOM more slowly. In those cases it almost always turns out that I've failed to wrap the code in a ready function.
$(function() { // the important bit
$('.colorbox').load('...').colorbox();
});
Try an XHTML strict doctype...?
I've experienced the exact same symptoms - but in my case it extended to all browsers.
One cause was that I didn't include the CSS file that I use for pages that use colorbox.
Another cause was I updated to the newest version of jQuery, but didn't upgrade colorbox. (Also, if you update your jquery include, make sure that you also update your jquery vs doc - if you're even using it).
Hope that helps.
Search through your colorbox files for this:
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader
There will be several instances of it, each pointing to a png. Make sure the path to that png is correct, then test it again.
I'm pretty sure I had this exact problem at one point, and fixing the paths was all I needed to do. However, it's been a while so my memory is a little fuzzy.
I had the same issue. I also had a problem with the image being only 10px wide due to IE not liking CSS max-width being set to 100%. To alleviate the problem I add the following to my CSS.
.cboxIE img
{
max-width:none;
_max-width:none;
}
Related
I'm writing my own site as a hobby (any html/css/js I know is self taught), but I've run into a issue that I can't seem to really understand (and thus I don't know how to fix it). I can't handle/fix this by myself unfortunately.
I tried taking away as much unneeded code as I could, reducing the site to the bare minimum where it still exhibits the unwanted behavior. I'm sorry for amateurish/hacky code, I'm not doing this professionally after all.
Here is a jsfiddle showing the code. It exhibits my wanted behavior: Click on any of the "Folders" and it expands and shows the "content". So far, so good.
If I now load the exact same code onto a site (I'm using netlify here), it still behaves as I want it to: Netlify link
If however I access it on a mobile browser (for reference I tried it on Google Chrome, Firefox and Brave browsers, all on Android) I get some behavior that I don't want:
If I expand one Folder, it works as intended, but if I expand the second folder as well the Folder name and its contents seem to change font size (they get noticeably bigger). If I close the normal one and reopen it it also changes size. For reference,
this is what it looks like.
It almost seems like me switching the display property to block changes the font size to something else, but I only defined one font size in the whole css.
I really don't know why this happens and I'd appreciate any help that explains it or points me in the right direction.
Thanks.
Edit: I managed to contact a third party who tried the site on their phone (iOS) and there the site did not exhibit the same weird/unwanted behavior. I'm not sure what exactly to do with that information.
I might have finally found a working solution to this weird and unexpected behavior. In your CSS, in the body section, add the following rules:
font-size-adjust: none;
text-size-adjust: none;
-webkit-text-size-adjust: none;
Those rules do not really have wide-spread support, apparently, and might change or their support get dropped at some point. One works only for Firefox, the other only for Chromium-based browsers, and yet another seems necessary for legacy Chromium-based. See:
https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust
https://caniuse.com/?search=font-size-adjust
https://caniuse.com/?search=text-size-adjust
Only with all three of those rules did I successfully prevent this font scaling for mobile Chromium, mobile Firefox Quantum (the old Firefox <=68 was not affected), both on Android, and for Chromium mobile mode on a Linux desktop. At least as far as my tests indicate.
Although I still fail to understand how and why such a rule would even be necessary: There definitely is no other conflicting rule in your example to affect rendered font size. My very wild guess would be that, under certain circumstances, some mobile browsers do not apply font-size rules correctly to hidden elements, causing this obscure cascaded font scaling.
Not at all the answer, but the described behavior can be reproduced even on a computer (Ubuntu Linux in my case; non-android device) using the given netlify link in Chromium, when using the mobile mode in Chromium DevTools. Maybe by reproducing it this way, somebody gets behind the cause of this behavior.
Upon opening the second folder, the font-size is indeed set to something 42.073px or something similar, depending on the responsive mode selected in the mobile mode. This is only shown in the "Computed" tab of DevTools, but there is no rule for this size in the "Styles" tab. I don't see any apparent cause for this text size change, sorry.
A few notes, however, on your HTML code (though none of the below seems to solve your problem):
Better put the <script> tag inside the <body> tag, right before the closing </body>. Or put it inside the <head>, but then make sure it get executed after page load. Outside <body> or <head>, your <script> is somewhat in limbo – unexpected side-effects included.
Similar goes for your <meta> tag. Put it inside the <head>.
For valid code and to reduce and even avoid unexpected side effects, surround your complete HTML code with an <html> tag, and define a doctype, e.g. <!doctype html> at the beginning of your HTML. Validate your HTML, for example here: https://validator.w3.org/#validate_by_input
I am using a JavaScript library to arrange few images on the webpage. The following browsers:
Firefox
IE 11
Microsoft edge
render the page as it was planned, the problem occurs with Chrome browser. It messes up the complete layout.
The above browsers don't load any content unless all the images have been downloaded, until then it shows a blank white screen, and all of a sudden it will show all the content rendered perfectly. And in case of Chrome, the browser displays content on the go, as in you can see the images appearing in a scanline fashion.
I've tried calling the function that arranges these images inside:
$(window).load(function() {})
and it didn't fix the issue, I tried calling this in the <head></head> and also just before closing </body>, that didn't fix it either. Is this a Chrome related issue?
What should be the correct point in time where the function should be called?
There is a nice library on the web with a comprehensive name imagesLoaded designed to fix your issue! It is supposed to work cross-browser of course, so no differences in behaviour in Chrome or other browsers.
With its help, you can run your code at the moment when all images loaded in specific DOM element or elements controlled by jQuery selector. Like:
$('body').imagesLoaded( function() {
// images have loaded
});
There are also .done, .fail, .progress callbacks supported if you need, so check the docs.
In some cases you have to wait until the image loads to get a parameter not specified in the <img> tag, such as height for example. Then you may use $(window).load
In other cases, for example, adding some classes to the images, you can do it before the image load.
If you want to load the images after the page loads completely or when the user really scroll and see each image, Lazy Load is a good plugin and it support callbacks.
Images should load First as hidden, Then your script should run like
$(document).ready(function(){
// here do the scripting may be showing them one by one
});
I have a list in my footer with few links, and when I click on my last listed element i.e "See more links" It replaces my list to new members using jQuery slideToggle().
But with this I see my footer bottom go a bit down and up again.
Thanks to user George and this issue was solved, using jQuery, by setting the height of #col on page load, here is my code:
$('#col').height(function(_,v){ return v; });
But with this solution, I'm getting a another issue that I am not able to understand
I have 5 versions of my design using media queries, above I have an image of my mobile version. As you can see my link "See more links" is almost completely hidden.
Also on Internet Explorer I have this issue almost in all media queries of my project...
Do you see why this can be happening?
I have here my full example: http://jsfiddle.net/jcak/4ma6es6h/8/
If you set min-height instead of height, your div will never be too small and won't collapse below the min-height.
But this still doesn't solve why your height is too small.
You might want to look into your box size. Look at the schema here on what is count as height and what is not:
http://api.jquery.com/innerheight/ and http://api.jquery.com/outerHeight/
maybe you have padding/margin/border that is not accounted for.
Use min-heightto avoid the hidden issue.
In older IE, IE < 9, media queries are not supported, you can use Respond.js, it will add media queries to IE 6-8, it's recommended by twitter bootstrap.
If you have further problems with IE, check you js using linting for es3, check jshint and use some polyfills, like es5-shim if you need something from es5.
I don't think this is to do with media queries, since you're having the same issue without them. The function 'function(_,v){ return v; }' is returning the height without margins or padding, which might be cutting off the link at the bottom. Perhaps try this instead:
var $col = $('.col4');
$col.height($col.outerHeight(true));
EDIT: I've just noticed your comment above, where you say that refreshing sometimes makes it work. This issue may be caused by the page not being fully rendered when your code is executed, so the wrong height is being called.
Also, you're using the same ID ('col') for multiple elements. IE will HATE this and will probably throw silent errors. IDs should be completely unique!
Older versions of IE could cause this problem to occur, maybe you could try and restrict them or add a notice that it's not working properly because "you're using an older version of Internet Explorer" or so.
Works fine in Mozilla Firefox, Chrome and newest Internet Explorer.
I'm having a bit of trouble with an if statement.
I've got a little lightbox popup error message running on the site. It works fine across everything except my windows phone where the popup load at the top of the screen (apparently ie mobile doens't like absolute positioning).
My solution is to simply scroll to the top of the page to display this (but only on ie-mobile.
Here's my code:
function checkiemob()
{
if (navigator.userAgent.match(/iemobile/i))
{
window.scrollTo(0,0);
}
}
If I remove the if statement this works fine. I've also tested the if statement with simply inserting text and that works too.
Cheers
I've been working some time on Hybrid applications, and i can tell that it's not worth it if you're not CSS professional and know everything about differences in browsers.
Don't know about absolute, but maybe it will give you a hint:
position:fixed - attaches element to the specified position on the page. ( HTML standart ). Works fine in Safari and Google Chrome.
But in IEmobile this position fixes the element to the display!
I think there might be same problem with you'r absloute
That means if i try to move whole page - in google and safari this fixed element will move along with the page, remaining on the same place, but in IEmobile it will stay on the same place
Problem: A div with visibility:visible inside a parent div with position:fixed and visibility:hidden causes rendering problems in Google Chrome. Images and examples can be found here.
A week ago you could just add the -webkit-transform:translateZ(0) to the parent div and bug solved. But it isn't working anymore:
Without -webkit-transform
With the hack.
Both are bugged.
So, is there any solution? When you resize the window, it repaints the divs, also when you open the developer tools the bug disappears.
So I've been trying to force a repaint with javascript (jQuery):
jQuery(window).scroll( function() {
jQuery("#parentDiv").addClass("nothing");
jQuery("#parentDiv").removeClass("nothing");
});
And it sometimes works (when a textfield is displayed inside the inner div). Really weird. Also tried hiding and displaying the div, adding css properties (fixed, bottom:0...)
But nothing works fine.
Any ideas?
EDIT2: Seems like it only happens to me: 2 friends, using windows and the latest version (17.0.963.79) don't see the bug in the second link. But I still see it. I've reinstalled chrome under windows, and the bug is still there.
I also have cleared the cache, but nothing changes. Am I the only one????
from my own experience when working with scroll(), all form-elements behave strangely, or do not function anymore.
You solution -webkit-transform:translateZ(0) will fix it for webkit browsers, but all others browsers will trow a translated layer above all form-elements, result is that form-element are not accessible anymore.
scroll() is a great solution for just plain info (text- images), not for forms.