Problem with headjs resizer - javascript

I have been playing around lately with head.js but I have found a stranger behavior that I think is not normal. When I'm using the screen size detector for resizing functionality the classes for the size doesn't change as it was expected to adapt to the new size (when you change the size of the window).
Have anyone experienced a similar problem with head.js?
Thanks!
EDIT: Head.js answered the ticket on Github and the problem is fixed:
This is now fixed:
https://github.com/headjs/headjs/commit/91324d8e676fd7a7f22c9f51f5482db0cb155f1b
NOTE: I did not update the minified
version of the file at this point.
Thanks!

Playing around on the headjs.com website, it doesn't seem as if its updating the classes as I resize my browser (which it is supposed to do according to the description). Perhaps a bug report is in order?

Related

Issue with masonry + img srcset

I am using Masonry 4.2.2 (current version) by David DeSandro that is bundled with WordPress.
When I put images into it that have "srcset" and "sizes", it loads the proper size, BUT ALSO the maximum version -> a lot of wasted data. Happens in both Firefox and Chrome.
I made a simple set of two test pages (= deleted almost everything else), so it is simple to compare that behaviour:
1)
https://www.pastel.cz/temp/test_gallery_simple.php
Masonry initialization commented out, in Inspector I can confirm that only single size is loaded. For my browser window around 2 MB is transferred.
2)
https://www.pastel.cz/temp/test_gallery_masonry.php
Everything identical, only this time Masonry is properly initialized at the end. A lot of new image versions are loaded, for me it is over 7 MB of downloaded data.
Is there a way to Am I doing something wrong here? Or should I report it as a bug? Thank you for any pointers.
Known issue
I think I found the answer, it is a known bug of imagesLoaded - a library that is used together with masonry to react on lazy loaded images. The bug is open from 2015, probably not many people noticed the behaviour :)
https://github.com/desandro/imagesloaded/issues/175
Workaround
Anyway, since I specify the image sizes in advance in the HTML and thus the grid can be fully constructed during the init phase without loading the actual images, it seems that I can disable the imagesLoaded library and the issue vanishes.

How to find out what is affecting the elements on a page?

I am currently building a site. When I refresh the page (as seen below), the two boxes with the brown outline start out at what seems to be 100% width, but then they re-size after about 1-2 seconds, and there is a small gap on the right hand side.
I'm pretty sure this isn't happening via the CSS, as there is a delay and I've looked through it all myself and can't find anything.
I am using Google Chrome's Developer Tools - is there any way that I can view any related JavaScript being ran on refresh that may be affecting these elements?
You can use a chrome extension to quickly turn off javascript. If the problem dissappears, you know that javascript is causing the problem. If the problem is still there, then it is a CSS issue (which I think is the case, but we can't solve that for you as you didn't provide the code).
here is a link to the javascript switcher extension:
https://chrome.google.com/webstore/detail/quick-javascript-switcher/geddoclleiomckbhadiaipdggiiccfje

Debugging CSS (Possibly JavaScript or JQuery) Issue

Issue: I have problems with this page: http://kivusandcamera.com/blog/ The page loads with a proper layout, but then the two blog entries "jump" to the left behind the navigation bar. I have spent a good bit of time trying work through the various CSS, inspecting it with developer tools, etc..., but I have reached a point where I feel like I need some help. Any advice would be appreciated.
Background: This is just a basic Wordpress theme that I am trying to customize for a website, so I am not 100% sure how
Additional Information: Though I am passingly familiar with CSS, I have done hardly any work involving responsive design, media queries, etc... Basically, I am saying (1) I would not be surprised if it is something really simple that I am missing, and (2) if something could be done a better way, please feel free to let me know.
UPDATE - It looks like this issue might be Javascript or JQuery related. Basically, a style attribute is getting injected into one of the div tags. The style attribute used an absolute position, with a certain width, and I have no idea how to modify it.
UPDATE #2 - It appears the issue happens with any pages I set in the theme to "Full Width" (see also the http://kivusandcamera.com/about page.) I think those pages must get processed differently by JS layout framework that is used. Again, I still haven't figured out how that is all happening.
Turns out there were two separate issues:
(1) The JQuery auto-layout framework was resizing the various page columns with the assumption that the navigation bar was the same size as the individual columns of blog entries. That caused an issue that had to be solved.
(2) The full page CSS had to be updated to reflect the lack of a resizing navigation bar.
Ultimately, these issues were very specific to the this particular Wordpress theme, so I doubt full description of the solution would provide much of a benefit to the community. Thank you to everyone who helped lead me to the solution.

Mobile Safari on iOS crashes on big pages

I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.
I get the same problem on both iPhone and iPad.
What are the best way to troubleshoot mobile pages to find the error? Are there any known problems that might crash Mobile Safari?
I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none; and probably never ran the opacity transition.
The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?
So the bottom line is: -webkit-transition crashed the page on mobile safari.
Had the same issue, for me it was -webkit-transform: translateZ(0); that caused the crash of Safari.
I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:
As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZ or anything else.
However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.
What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.
The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.
Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.
In any case, to give more up to the point suggestions, more information about your page would be really great.
By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:
General
About
Diagnostics & Usage
Diagnostics & Usage Data
If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).
Otherwise, it might tell you what is wrong...
Hope this helps.
There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.
See Apple's documentation for more info.
I recently had an issue with mobile safari crashing on web-app pages containing a lot of images (30+ were enough) and a few transformations for the menu. After a lot of trial and error, I settled with a solution similar to what LinkedIn does, but for infinite scrolling using angularjs. I used requestAnimFrame and two expanding/shrinking divs (with js style attributes) on the top and bottom of the list to remove all image containers (with other stuff overlayed on top) except for a few ones which are close to the viewport. Scrolling performance (native, no js) is fine and memory consumption is in check.
I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).
After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.
Adding a little timeout solved the problem. My application was also using iframes.
$(document).ready(function () {
window.setTimeout(function () { ready(); }, 10);
});

Jquery Load function issue in IE6

i am using IE6 as a browser and when i call upon a local HTML file as an overlay by using Load function it loads the page but, following things happens
1: shows a loading status bar all the time
2: All the javascript in the called page(overlay) stopped working.
this is the call code
$("#mainoverlay").load("card1.html");
IE6 has known issues with transparent images (IE6 has A LOT of issues). There are numerous javascript fixes for this - but they all work basically the same way with a 1x1 pixel GIF. If you have the ability to go with JPGs or GIFs instead, that would save you a lot of heartache - but I would guess you would have already gone that way if you could have.
One way I've dealt with it in the past is to detect the browser and swap in a non-transparent image (GIF/JPG) if it is IE6. This is approach has many challenges as well and will end up being a significant effort.
The bottom line is that IE6 is just a pain in the rear. You might want to try one of the other IE6 transparent image solutions to try to avoid the conflict, but I wouldn't be optimistic on coming up with a clean execution.
use DD_Belated.png to fix PNGs in IE6 and this may fix this secondary issue: http://www.dillerdesign.com/experiment/DD_belatedPNG/

Categories

Resources