4 ms·

> This is because of animated GIFs. If you disable muted video people will just use GIFs instead and it'll chew up way more of your bandwidth than a video file

> This is because of animated GIFs. If you disable muted video people will just use GIFs instead and it'll chew up way more of your bandwidth than a video file would. I wish there was an option in browsers to prevent the downloading of GIFs (especially on mobile). It used to be useful for artwork, but PNG has taken that over.

dorgo 8y ago
img[src$="gif"]{ display:none; } edit: at least it prevents them from being displayed :P
- jefftk 8y ago
  That will match images whose name ends in "gif", but won't match "/foo.GIF" or simply a "/foo" that is a GIF. You can't tell what content type the server thinks the image is until you get the content-type header, and you can't tell what it actually is until it's been downloaded.
  - dredmorbius 8y ago
    It's a good 99% solution.
    - Anon1096 8y ago
      Most gifs being served on the web aren't .gif files anymore, but .webm or .mp4 files instead. That css wouldn't even stop half of the gifs most users see on a daily basis.
      - dredmorbius 8y ago
        I can assure you that: 1. The solution as posed works remarkably well. I know this because I use it myself.[1] 2. Extending the pattern to either be case-insensitive or include other animated image formats is pathetically trivial. ________________________________ Notes: 1. Specifically, in my "Annoyances" stylesheet, applied to all sites by default: /* gifs: So, it has come to this ... (xkcd) */ img[src$=".gif"] { opacity: 0 !important; transition-delay: 3s; transition-duration: 1s; transition-timing-function: ease; transition-property: opacity; display: block; } img[src$=".gif"]:hover { transition-delay: 0.3s; transition-duration: 0.3s; opacity: 1 !important; }
jefftk 8y ago
The browser doesn't know the image is a GIF (content-type header) until after it starts getting bytes back. At that point the only way (pre HTTP/2) to stop the bytes is to close the connection, but this is terrible for performance because you lose keepalive and need to open a new connection. If this was common, sites could also serve GIFs with an the content-type of a different image. Since browsers content-sniff between image formats, if the GIF was served as image/png then it wouldn't be until the image finished downloading that the browser would learn it was a GIF.
- codetrotter 8y ago
  > if the GIF was served as image/png then it wouldn't be until the image finished downloading that the browser would learn it was a GIF GIF has a header at the start of the file identifying it as such. It starts with one of two six byte long sequences identifying the version of the format that is being used. 0x47 0x49 0x46 0x38 0x37 0x61 ("GIF87a") 0x47 0x49 0x46 0x38 0x39 0x61 ("GIF89a") So as long as the file isn't served with additional compression obscuringly applied on top (gzip etc) you will have an indicator that the file might be a GIF after downloading just the six first bytes of it. Of course you could be unlucky and try to download a file that is not a gif but which happened to start with either of those two sequences of bytes. But you could: - Stop downloading it if the URL was loaded via <img>, and place something like an image of the word GIF with a cross over it in the img tag. - If it was loaded outside of <img>, let the user know that it was blocked as suspected GIF but allow them to override. At least as a first step toward some kind of anti-GIF thing.

dorgo 8y ago

img[src$="gif"]{ display:none; } edit: at least it prevents them from being displayed :P

jefftk 8y ago
That will match images whose name ends in "gif", but won't match "/foo.GIF" or simply a "/foo" that is a GIF. You can't tell what content type the server thinks the image is until you get the content-type header, and you can't tell what it actually is until it's been downloaded.
- dredmorbius 8y ago
  It's a good 99% solution.
  - Anon1096 8y ago
    Most gifs being served on the web aren't .gif files anymore, but .webm or .mp4 files instead. That css wouldn't even stop half of the gifs most users see on a daily basis.
    - dredmorbius 8y ago
      I can assure you that: 1. The solution as posed works remarkably well. I know this because I use it myself.[1] 2. Extending the pattern to either be case-insensitive or include other animated image formats is pathetically trivial. ________________________________ Notes: 1. Specifically, in my "Annoyances" stylesheet, applied to all sites by default: /* gifs: So, it has come to this ... (xkcd) */ img[src$=".gif"] { opacity: 0 !important; transition-delay: 3s; transition-duration: 1s; transition-timing-function: ease; transition-property: opacity; display: block; } img[src$=".gif"]:hover { transition-delay: 0.3s; transition-duration: 0.3s; opacity: 1 !important; }

jefftk 8y ago

The browser doesn't know the image is a GIF (content-type header) until after it starts getting bytes back. At that point the only way (pre HTTP/2) to stop the bytes is to close the connection, but this is terrible for performance because you lose keepalive and need to open a new connection. If this was common, sites could also serve GIFs with an the content-type of a different image. Since browsers content-sniff between image formats, if the GIF was served as image/png then it wouldn't be until the image finished downloading that the browser would learn it was a GIF.

codetrotter 8y ago
> if the GIF was served as image/png then it wouldn't be until the image finished downloading that the browser would learn it was a GIF GIF has a header at the start of the file identifying it as such. It starts with one of two six byte long sequences identifying the version of the format that is being used. 0x47 0x49 0x46 0x38 0x37 0x61 ("GIF87a") 0x47 0x49 0x46 0x38 0x39 0x61 ("GIF89a") So as long as the file isn't served with additional compression obscuringly applied on top (gzip etc) you will have an indicator that the file might be a GIF after downloading just the six first bytes of it. Of course you could be unlucky and try to download a file that is not a gif but which happened to start with either of those two sequences of bytes. But you could: - Stop downloading it if the URL was loaded via <img>, and place something like an image of the word GIF with a cross over it in the img tag. - If it was loaded outside of <img>, let the user know that it was blocked as suspected GIF but allow them to override. At least as a first step toward some kind of anti-GIF thing.