News for hackers. Stuff that matters.
Re:Faster Images using HTTP2 and Progressive JPEGs by ge96 on Wednesday December 28, 2016 @05:15AM (#13269629)
I'm curious, this would probably be better than using an image preload/loading icon as far as delay or even blank spots/placeholders.

I think I've seen this before but I've used an overlay loading gif which was shown over the image while the image loaded then when it loaded the loading gif would be hidden.

Re:Faster Images using HTTP2 and Progressive JPEGs by nothrabannosir on Wednesday December 28, 2016 @05:20AM (#13269646)
I'm always happy when sites don't mess with <img> like this, since it completely breaks down for non-JS browsers. :/ There are ways to do this without breaking, but it's not always done. Apparently.
Re:Faster Images using HTTP2 and Progressive JPEGs by ge96 on Wednesday December 28, 2016 @05:39AM (#13269696)
Oh man, that's one of those things with web that sucks you gotta factor it in. I don't know the percentage but say on average, 70% of a basic web gets most of the users. Then you have to factor in blind users, non-javascript, internet explorer... Ahhh

It bothers me because I know it's something to address.

So regarding non-javascript, most interfaces are built with JavaScript so what percentage are you addressing?

I've only had the non-javascript come up personally regarding using Tor. I don't know/use Tor much.

I don't ever put <noscript> alerts in ahhh I should though.

I use AdBlock too, not sure if that affects what the desired end-result of non-javascript

Re:Faster Images using HTTP2 and Progressive JPEGs by nothrabannosir on Wednesday December 28, 2016 @06:21AM (#13269849)
I was talking about myself, in this case. Quite selfish, unlike your comment :)

I use noscript and disabled JS on iOS Safari, for battery life and security. Not a fanatic noscript user at all, it just seems slightly less bad than full js at this point.

Graceful degradation is a better choice than <noscript> tags, where possible. Which, for <img>, it is.

thanks for considering the minority, even if it doesn't pan out :)

Re:Faster Images using HTTP2 and Progressive JPEGs by ge96 on Wednesday December 28, 2016 @06:27AM (#13269868)
I don't know if it's a futile battle regarding accessibility. I guess if you're a big enough company/group you'd have experts in that area.

Hmm yeah I guess I'm not as up to date with mobile(the stuff you mentioned)

Re:Faster Images using HTTP2 and Progressive JPEGs by the8472 on Wednesday December 28, 2016 @05:53AM (#13269752)
some sites also have silly JS breakage when you block 3rd-party domains while allowing same-origin requests. They blindly assume that stuff loaded successfully.
Re:Faster Images using HTTP2 and Progressive JPEGs by edraferi on Wednesday December 28, 2016 @06:22AM (#13269852)
> some sites also have silly JS breakage when you block 3rd-party domains while allowing same-origin requests. They blindly assume that stuff loaded successfully.

Oh yeah, that's the worst. I use uBlock Origin to block third party JS by default, then selectively enable domains I trust (mostly CDN services). This is usually a happy medium between raw and noscript, but it definitely breaks a lot of pages.

Re:Faster Images using HTTP2 and Progressive JPEGs by patates on Thursday December 29, 2016 @05:36AM (#13276641)
I have uMatrix installed just for that, didn't know uBlock origin could also block third party scripts. Oh well, I also love to block all cookies and only allow first party cookies on sites that I've an account with.
Re:Faster Images using HTTP2 and Progressive JPEGs by nishs on Wednesday December 28, 2016 @06:04AM (#13269791)
Medium.com does something similar (blur the image while waiting for it to load), but it appears they have a <noscript> fallback.

  <noscript class="js-progressiveMedia-inner">
    <img class="progressiveMedia-noscript js-progressiveMedia-inner" src="https://cdn-images-1.medium.com/max/800/1*vY3BMZ9BrxgkD7je7f-Ckw.jpeg"
  </noscript>
Re:Faster Images using HTTP2 and Progressive JPEGs by vladdanilov on Wednesday December 28, 2016 @06:32AM (#13269880)
Had to do it for the project website. The solution was to generate inline placeholder images and substitute original src attributes with them when DOM is loaded, then back on scroll and click events.

The placeholder images are JS-generated solid color PNGs downscaled to just keep the same aspect ratio. SVGs could be much easier but less supported probably.