public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: Gwern Branwen <gwern-v26ZT+9V8bxeoWH0uzbU5w@public.gmane.org>
To: pandoc-discuss <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
Subject: Proposed new HTML5 feature: lazy loading images (#6197)
Date: Thu, 19 Mar 2020 13:29:11 -0400	[thread overview]
Message-ID: <CAMwO0gxQ_RbLCe_XzV0xBci7TzbhDtVqrJbsGcnV+LYvN8jjOQ@mail.gmail.com> (raw)

Copied from https://github.com/jgm/pandoc/issues/6197#issue-584108358
for additional discussion:

--------

There is a newly-standardized HTML5 feature, image lazy loading, which
allows images in a web page to be loaded only shortly before they
would come on screen, potentially greatly reducing bandwidth
consumption and page loading speed (and which replaces the many nasty
JS hacks used before\*). One simply adds an attribute `loading="lazy"`
to tags such as `<img>` tags.

I think Pandoc should generate HTML5 which does lazy loading by
default. There are few downsides, and a huge upside, and users should
receive the benefit of it automatically\*\*. It is

1. fully backwards-compatible; it does not break any existing browsers
or degrade any functionality in browsers that do not recognize it
2. [fully standardized &
accepted](https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes)
([discussion](https://github.com/whatwg/html/pull/3752))
3. already widely available:
[Chrome](https://web.dev/native-lazy-loading/) shipped it by default
in Chrome 76 ~August 2019, and Firefox 75 [~February
2020](https://bugzilla.mozilla.org/show_bug.cgi?id=1542784) (current
global availability:
[>63%](https://www.caniuse.com/#feat=loading-lazy-attr))
4. saves a potentially enormous amount of bandwidth, particularly for
mobile users, who pay the most for bandwidth while benefiting the most
from lazy-loading due to small screens

    For example, on one [gwern.net page](https://www.gwern.net/Faces)
it saves something like 20MB. It also results in a much more pleasant
browsing experience in my experience. I've become much more willing to
include images in my pages now that I know lazy loading works.
5. reliable and bug-free

    I am not aware of any use-cases that lazy loading breaks other
than printing in Chrome (see below).

    I've had it enabled on all gwern.net pages/images since 19 Sep
2019 (see `staticImg` in
[`hakyll.hs`](https://www.gwern.net/hakyll.hs)), hundreds of thousands
of page loads ago, and no problems have been reported to me, nor have
I noticed any in my own browsing, aside from sometimes (with a 4k
fullscreened browser in portrait orientation) images flashing into
view when I page down too fast for it. (But it's rare and at first I
wasn't sure I had enabled lazy loading correctly until I set up the
network monitor to check when the image requests were made.)
6. easy to add: it's just adding an attribute to all generated
figures, with no IO or any logic involved. Just add an attribute in
`src/Text/Pandoc/Writers/HTML.hs`'s image-handling.

    I *think* it might go something like this (I actually implemented
my rewrite in Tagsoup as a post-processing step, because I didn't want
to reinstall my entire Pandoc stack just to check this would work):

    ```.Haskell
    img <- inlineToHtml opts (Image attr [Str ""] (s,tit))
    ```

    to

    ```.Haskell
    img <- inlineToHtml opts (Image (attr++[("loading", "lazy")]) [Str
""] (s,tit))
    ```

The main drawback I've found so far is that

1. printing: [in Chrome, printing may omit images which haven't been
seen yet](https://bugs.chromium.org/p/chromium/issues/detail?id=875403),
which is an open bug.

    They acknowledge it's a bug, so I hope they'll fix it since
Wikimedia is complaining about it, and printing partially-loaded pages
in Chrome is a pretty narrow and specific edge case with an easy
workaround for the user of just scrolling to the bottom before
printing. (There aren't any mentions of a bug like this for Firefox or
Edge; I guess no one ever tries to print image-heavy gwern.net pages
from Chrome, because it hasn't come up.)

\* nasty because most of them required breaking image loading entirely
for people without JS enabled. And then didn't even work very well - I
assume because they generally didn't use
[IntersectionObservers](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API)
to properly start fetching the image well before the user scrolled it
into visibility.
\*\* It can be stripped out of the HTML, if necessary somehow, with as
simple a rewrite as a call to `sed`.

-- 
gwern


             reply	other threads:[~2020-03-19 17:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19 17:29 Gwern Branwen [this message]
     [not found] ` <CAMwO0gxQ_RbLCe_XzV0xBci7TzbhDtVqrJbsGcnV+LYvN8jjOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-03-20  5:07   ` Kolen Cheung
     [not found]     ` <8cc5d71b-168a-4597-8d75-5a66723c2d82-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-03-20  7:00       ` Ross Woods
     [not found]         ` <00f697d7-dd56-4d0c-8631-cc87819e9c3e-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-03-20 11:13           ` Kolen Cheung
2020-03-20 11:48       ` BPJ
2020-03-20 14:11       ` Gwern Branwen
     [not found]         ` <CAMwO0gwkcoHdJLLhkzpyaDzuc3qmb4eXuhLAjpJs7dM_gj7R2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-03-20 16:26           ` John MacFarlane
     [not found]             ` <m2fte3ngbe.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
2020-03-20 16:39               ` Gwern Branwen
     [not found]                 ` <CAMwO0gyuMm6_M5SKrppRSQ9aXckW+sAYh+6jNdkjvGMB8RVooQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-03-20 17:52                   ` John MacFarlane
     [not found]                     ` <m2wo7encau.fsf-pgq/RBwaQ+zq8tPRBa0AtqxOck334EZe@public.gmane.org>
2020-03-20 18:20                       ` Gwern Branwen
     [not found]                         ` <CAMwO0gw_7BWLcVKG-Sa21dpRpzWx3v2T7hxs9YtRiHw6XP=sSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-03-20 18:42                           ` Daniel Staal
2020-03-20 23:08                           ` John MacFarlane
2020-03-20 22:12           ` Kolen Cheung
     [not found]             ` <dfe2404e-87d8-4425-8998-3965e0f5ddf8-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-03-20 22:35               ` Gwern Branwen
     [not found]                 ` <CAMwO0gywYpD13U29RqKzSD8mnYPPa7VvX1FnsnOorsmEbGxCyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-03-20 22:44                   ` Kolen Cheung
     [not found]                     ` <81771c0d-dc1c-48bb-ba49-6f8e28b0e47b-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2020-03-20 22:59                       ` Gwern Branwen
     [not found]                         ` <CAMwO0gxy49tC39rtmkPgjvOaUdVqbhnVKX1Yvu=FGhBK3oMoMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-03-20 23:47                           ` Kolen Cheung
2020-03-20 22:16   ` Kolen Cheung

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMwO0gxQ_RbLCe_XzV0xBci7TzbhDtVqrJbsGcnV+LYvN8jjOQ@mail.gmail.com \
    --to=gwern-v26zt+9v8bxeowh0uzbu5w@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).