malchata/yall.js

Browser loading the <noscript> image files by default even if they are hidden by 'display:none'

Badhumvee opened this issue · 5 comments

HI malchata,

We are using your suggestion of noscript elements everywhere we are using lazy loading using yall.js. We noticed that yall.js seems to be working as expected when the browser can run javascript. BUT, it seems those lazy loaded images are all being preloaded any way by the browser because of how the browser treats the noscrip elements. Apparently, when the browser can run js, the noscript elements still makes the browser/chrome to download the image inside the .

...

<img class="lazy sampleimage" data-src="image1.jpeg" src="PLACEHOLDER-IMAGE.png" alt="This is a image when browser can do js.">
<noscript>
        <img src="image1.jpeg" class=" sampleimage" alt="This is image when browser cannot do js.">
</noscript>

...
I was thinking we can add a simple js-code to just display:none all elements so they will not require their child images to be loaded by the browser. Also, when the browser cannot run js, this code will not run and we will have the element to fall back to display the img

While it seems to be a quick fix, I am not sure if this is the best approach. I'd like to have your opinion on how to handle the issue of browser loading the image files by default.

Hi, thanks for logging this.

Which browsers are you noticing that images within <noscript> are loading? It's been my knowledge and experience that browsers don't evaluate the content within <noscript> as HTML unless JavaScript is actually turned off. Additionally, I can verify in all browsers installed on my machine (Chrome, Firefox Developer Edition, Firefox Nightly, Edge, IE 11, Safari, and Safari Technical Preview) that image resources referenced within <noscript> do not download when JavaScript is turned on through the network panel in each browser's dev tools.

Additionally, a CSS display value of none does not guarantee whether inline resources referenced from <img> are downloaded. Using this Codepen example, I can verify that even though the stylesheet sets display: none; for all img elements, the referenced image still downloads in Chrome, Firefox (dev and nightly), Edge (17), Safari (stable and Technical Preview). That this is the case tells me that this is likely conforming behavior for browsers.

I would ask you check and verify in the network panel of your browser's dev tools that images within the <noscript> elements are actually downloading when JavaScript is on.

I understand your point about how browsers will not evaluate the content inside noscript element if javascript is turned ON. But for some reason its not working like that in my code.... until I just noticed that the code I had shared earlier is actually wrapped inside an 'a' element like below on my end. Would this have anything to do with the images inside noscript element being loaded? I am trying to show an image inside an 'a' link element. Does noscript element work differently inside 'a' element?

I guess I am asking if the noscript have to be the immediate child of body element for it to work properly? Seems like noscript can only go directly under body tag and not under any other div/a elements.

<a href="samplepage.html">
<img class="lazy sampleimage" data-src="image1.jpeg" src="PLACEHOLDER-IMAGE.png" alt="This is a image when browser can do js.">
<noscript>
        <img src="image1.jpeg" class=" sampleimage" alt="This is image when browser cannot do js.">
</noscript>
</a>

I have since removed all the noscript tags from my code and it seems to be working fine.

Thanks a lot Malchata.

It shouldn't matter where <noscript> is placed. One thing I remember is that you use yall.js in an Angular single page app, so I wonder if some strange interaction is occurring there. Do you have a minimal reproducible test repo where this occurs?

not really...
I went ahead and removed all the noscript items that were not direct children of body and it is working now. Thanks a lot for your help.

OK. I'll go ahead and close this. If you decide you'd like to have me look at a test repo with this issue, just let me know in this issue, and I'll reassess. Thanks for being patient, and for your help. 😄