Proposed new HTML5 feature: lazy loading images (#6197)

Proposed new HTML5 feature: lazy loading images (#6197)

[Gwern Branwen]

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

Proposed new HTML5 feature: lazy loading images (#6197)

[Kolen Cheung]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Would it causes the page typesetting change over time? Don’t know how to put this well, many things loading dynamically using JS will render very quickly but the “typesetting”, the location where text and images go, would be changing as it load, making the page rapidly changing in the first few seconds as it loads.

Also, from your introduction it seems Safari doesn’t support it yet. I think it is very important for the 3 major browsers to support it before making it a default behavior.

I agree with jgm that if made native in pandoc, it should be an option, but not a default.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/8cc5d71b-168a-4597-8d75-5a66723c2d82%40googlegroups.com.

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Ross Woods]

[-- Attachment #1.1: Type: text/plain, Size: 1360 bytes --]



On Friday, March 20, 2020 at 1:07:16 PM UTC+8, Kolen Cheung wrote:
>
> Would it causes the page typesetting change over time? Don’t know how to 
> put this well, many things loading dynamically using JS will render very 
> quickly but the “typesetting”, the location where text and images go, would 
> be changing as it load, making the page rapidly changing in the first few 
> seconds as it loads. 
>
> Also, from your introduction it seems Safari doesn’t support it yet. I 
> think it is very important for the 3 major browsers to support it before 
> making it a default behavior. 
>
> I agree with jgm that if made native in pandoc, it should be an option, 
> but not a default.


It's not a javascript feature, it's html5. Most browsers I know just ignore 
something if they don't recognize it,  it so it doesn't process as a 
glitch. They expect they all have different strategies for 
typesetting/layout.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/00f697d7-dd56-4d0c-8631-cc87819e9c3e%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1800 bytes --]

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Kolen Cheung]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

I guess to ease the transition it can be implemented as an option first, and then as more people are familiar with it then it can becomes a default.

Eg there used to be (May still have) an HTML (html4) and html5 writers, and if one specifies html then it defaults to html4. And for a long time it stays that way until a few years ago. And I think now it is actually XHTML5.

This change is much smaller than the example I have above, but I think the concept is similar. I agree it is a feature worth having, considering the bandwidth it saves for all pandoc generated contents.

Or may be we really worried too much and it can be the default right away. I think a short demo may help. It may as well exist already, just need for someone to link us.

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[BPJ]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

I'd guess that at least if you explicitly set the size in the img tag (in
some relative unit related to the page dimensions) there shouldn't be a
problem, but I'm thinking that since it's easy to add this attribute with a
filter that is probably what one should do if one wants to apply it
universally. At least until the Chrome printing problem is solved (although
I'm hard pressed to remember when I last printed a web page other than a
receipt. I'm old school enough to want to have those on paper.)

Den fre 20 mars 2020 06:08Kolen Cheung <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> skrev:

> Would it causes the page typesetting change over time? Don’t know how to
> put this well, many things loading dynamically using JS will render very
> quickly but the “typesetting”, the location where text and images go, would
> be changing as it load, making the page rapidly changing in the first few
> seconds as it loads.
>
> Also, from your introduction it seems Safari doesn’t support it yet. I
> think it is very important for the 3 major browsers to support it before
> making it a default behavior.
>
> I agree with jgm that if made native in pandoc, it should be an option,
> but not a default.
>
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/8cc5d71b-168a-4597-8d75-5a66723c2d82%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhC5znnxMVy3hgSsozP-ce2DJZNOCeVC6VRUchBU0eHHzg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 2965 bytes --]

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Gwern Branwen]

On Fri, Mar 20, 2020 at 1:07 AM Kolen Cheung <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Would it causes the page typesetting change over time? Don’t know how to put this well, many things loading dynamically using JS will render very quickly but the “typesetting”, the location where text and images go, would be changing as it load, making the page rapidly changing in the first few seconds as it loads.

Reflowing already happens with images, remember. If images do not have
height/width, the browser can't know how big the images are until they
download and are rendered. People who care about avoiding page
reflowing need to set the image width/height, as I do, and this has
been true for something like 20+ years now. (I believe Pandoc doesn't
do this automatically only because there's no way for it to, at
compile-time, know what images are being referenced or where they are
either on disk or the Internet, so it can't look them up and inline
the dimensions; so the user either has to specify dimensions manually
https://pandoc.org/MANUAL.html#extension-link_attributes or it has to
be left to a post-processing tool like Hakyll which knows where the
images are. I do the latter.)

Lazy loading doesn't change this: if you start at the top of the
screen and scroll down, the lazy loading will load the image before a
section becomes visible, and any reflowing triggered by unknown
dimensions becoming known *ought* to be 'downstream'/off-screen and so
the user doesn't see them. (I'd speculate that lazyloading might even
reduce such reflowing jumpiness, because by not spending
bandwidth/connections up front downloading all the images in order to
start layout/rendering, the browser can proceed through the HTML and
download all of the fonts/CSS/JS faster and get those done quicker.)

> Also, from your introduction it seems Safari doesn’t support it yet. I think it is very important for the 3 major browsers to support it before making it a default behavior.

As I said, it is backwards-compatible. Safari may not support it*, but
it will render pages with lazy-load attributes exactly the way it did
before (ie. wastefully downloading all images strictly). This is why I
was happy to make it default on gwern.net back in September when only
Chrome supported it - it was harmless and didn't hurt any other
browsers' users, and Chrome users benefited. Now that support is in
Edge/Chrome/Firefox/etc (>60% of browsers per CanIUse and set to
increase steadily), the advantage is even greater.

* Man, when does Safari support anything in a timely fashion? It's the
worst of the major browsers.

> I think a short demo may help.

As I said, all of gwern.net is already a demo of using lazy loading
with Pandoc-generated HTML pages, since September 2019 and ~880k
pageviews (to be more specific), and I linked
https://www.gwern.net/Faces as an image-heavy page which benefits
enormously from it. I have gotten no complaints about lazyloading, and
observed no breakage, and that's why I am bringing it up now. I would
not suggest anything I haven't already used myself.

It seems like a pretty mature tech at this point which almost all
Pandoc HTML users would benefit from. Making it an option for a while
would be fine, to be conservative and let people test it out and see
that it works as I claim it does, but it'd be a great pity to keep it
*permanently* opt-in and additional work, because you know that means
that only a tiny percentage of Pandoc users will ever know about
(there are so many features to remember) or be able to use it, because
they would have to update scripts or build processes (to which they
might not have easy access) to enable it. This is the sort of
universally-applicable optimization the tool should be opinionated
enough to do for you to make your life better.

> At least until the Chrome printing problem is solved (although I'm hard pressed to remember when I last printed a web page other than a receipt. I'm old school enough to want to have those on paper.)

I actually can remember printing something out in the past year -
photos for my grandparents! Also once in a while, airline tickets as
backups. Other than that, yeah, I'm hard-pressed to remember the last
time I printed out any kind of webpage which might plausibly have been
written in Pandoc. But workflows will differ: Wikimedia, I think, has
to cater heavily to lower education where students/teachers print out
a lot of stuff to work on in class etc.

-- 
gwern

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAMwO0gwkcoHdJLLhkzpyaDzuc3qmb4eXuhLAjpJs7dM_gj7R2A%40mail.gmail.com.

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[John MacFarlane]

One thing that is important to consider is whether the lazy
loading causes any problems in epub3 readers, since the html5
writer is used there as well.

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Gwern Branwen]

I can't find any explicit discussion of lazy loading & EPUB3, or how
EPUB3 readers handle unknown attributes in general.

It seems that EPUB3 readers usually use a browser engine for reading
the HTML5, and so would inherit the usual behavior of ignoring unknown
attributes; since lazy loading is now part of the HTML5 standard, at
some point they will have to be updated to explicitly accept lazy
loading? Although that doesn't really make sense for an EPUB file (are
they even allowed to load remote resources? I thought they had to be
self-contained, since they can hardly non-lazily fire off a book's
worth of requests every time they are opened, or when offline), so
it'd presumably become valid but a no-op.

-- 
gwern
https://www.gwern.net

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[John MacFarlane]

Technically EPUB3 is supposed to support HTML5 features.
In practice, readers seem inconsistent, or so I've heard.

Gwern Branwen <gwern-v26ZT+9V8bxeoWH0uzbU5w@public.gmane.org> writes:

> I can't find any explicit discussion of lazy loading & EPUB3, or how
> EPUB3 readers handle unknown attributes in general.
>
> It seems that EPUB3 readers usually use a browser engine for reading
> the HTML5, and so would inherit the usual behavior of ignoring unknown
> attributes; since lazy loading is now part of the HTML5 standard, at
> some point they will have to be updated to explicitly accept lazy
> loading? Although that doesn't really make sense for an EPUB file (are
> they even allowed to load remote resources? I thought they had to be
> self-contained, since they can hardly non-lazily fire off a book's
> worth of requests every time they are opened, or when offline), so
> it'd presumably become valid but a no-op.
>
> -- 
> gwern
> https://www.gwern.net

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Gwern Branwen]

Everything is always terrible in web development, so I assume EPUB3
readers are indeed spotty in support of features; but ignoring
'invalid' attributes isn't really a 'feature' in any conventional
sense. It's just what you need to do to have a EPUB3 reader which
doesn't break at the drop of a hat the instant someone makes a single
syntax error or HTML5 introduces a new attribute anywhere. It would be
crazy for any EPUB3 reader author to decide to, unlike most/all HTML5
browsers, be ultra-strict and break on encountering an unknown
attribute, especially given that HTML5 is far from done and is adding
new stuff all the time. (This being a case in point.)

-- 
gwern
https://www.gwern.net

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Daniel Staal]

On 3/20/20 2:20 PM, Gwern Branwen wrote:
> It would be
> crazy for any EPUB3 reader author to decide to, unlike most/all HTML5
> browsers, be ultra-strict and break on encountering an unknown
> attribute, especially given that HTML5 is far from done and is adding
> new stuff all the time. (This being a case in point.)

More likely than a decision to break would be an attempt to 
'intelligently' support this or some other attribute, which fails poorly.

Daniel T. Staal

-- 
---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 7800 bytes --]

Frankly I read through your initial issue on GitHub to the end, and have 
been a relatively long time pandoc users, but those are the things I missed.

I think it will be very important to emphasize that "not supporting this 
feature" doesn't break it normally (as it will be ignored.)

You can complain all you want about Safari, but it is still a major 
browser. And personally I will quit the website I was browsing that breaks 
on Safari, unless it is like some banking website that I have to rely on. 
Frankly Chrome, the most popular browser that even many other browsers are 
now based on including Edge, is a big problem of the internet (privacy 
issue.) Firefox is doing a great job to still put on a fight against it, 
being the only other major browser available on most OSes. I think 
diversity of browsers are very important for the open web, and the late 
trend of everything converging to Chrome is not a good sign. (I do use 
Chrome daily from Electron apps to JypyterLab, etc. but basically 
everything else Safari.)

Regarding default on or off, I shared the same view that it should not be 
default off forever, and pandoc's history shown that it probably won't. It 
is about having a transition period. You tested it well and you think it is 
not breaking, but we haven't. And you'll be (or may not) surprised that how 
many things are powered by pandoc, including RMarkdown and Jupyter 
Notebooks (e.g. export options.)

Another example question is how about `wkhtmltopdf` PDF output in pandoc. 
It may not breaks. But you didn't mention it and we didn't tested it. So it 
is another potential thing to test first.

And lastly, for all those questions people have for you, they are not 
opposing you. People (at least me) replies only because we are interested 
in that feature. But pushing for a feature has to be done carefully. Again 
you may have tested it well and understood its consequences, but we don't. 
It is your job to convince us if you want it happening. And I think we are 
sharing the same goal here by asking questions.

My suggestion is simple, implement it as an option first, then wait for a 
while to make it defaults (also true for some other pandoc features.) It 
has the benefit or not needing to know all cornering cases beforehand. 
However it is up to jgm to also judge if this is too ugly. Having too many 
options is not a good thing either (in codes, manual and our command line 
options.)

On Friday, March 20, 2020 at 7:12:30 AM UTC-7, Gwern Branwen wrote:
>
> On Fri, Mar 20, 2020 at 1:07 AM Kolen Cheung <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
> <javascript:>> wrote: 
> > Would it causes the page typesetting change over time? Don’t know how to 
> put this well, many things loading dynamically using JS will render very 
> quickly but the “typesetting”, the location where text and images go, would 
> be changing as it load, making the page rapidly changing in the first few 
> seconds as it loads. 
>
> Reflowing already happens with images, remember. If images do not have 
> height/width, the browser can't know how big the images are until they 
> download and are rendered. People who care about avoiding page 
> reflowing need to set the image width/height, as I do, and this has 
> been true for something like 20+ years now. (I believe Pandoc doesn't 
> do this automatically only because there's no way for it to, at 
> compile-time, know what images are being referenced or where they are 
> either on disk or the Internet, so it can't look them up and inline 
> the dimensions; so the user either has to specify dimensions manually 
> https://pandoc.org/MANUAL.html#extension-link_attributes or it has to 
> be left to a post-processing tool like Hakyll which knows where the 
> images are. I do the latter.) 
>
> Lazy loading doesn't change this: if you start at the top of the 
> screen and scroll down, the lazy loading will load the image before a 
> section becomes visible, and any reflowing triggered by unknown 
> dimensions becoming known *ought* to be 'downstream'/off-screen and so 
> the user doesn't see them. (I'd speculate that lazyloading might even 
> reduce such reflowing jumpiness, because by not spending 
> bandwidth/connections up front downloading all the images in order to 
> start layout/rendering, the browser can proceed through the HTML and 
> download all of the fonts/CSS/JS faster and get those done quicker.) 
>
> > Also, from your introduction it seems Safari doesn’t support it yet. I 
> think it is very important for the 3 major browsers to support it before 
> making it a default behavior. 
>
> As I said, it is backwards-compatible. Safari may not support it*, but 
> it will render pages with lazy-load attributes exactly the way it did 
> before (ie. wastefully downloading all images strictly). This is why I 
> was happy to make it default on gwern.net back in September when only 
> Chrome supported it - it was harmless and didn't hurt any other 
> browsers' users, and Chrome users benefited. Now that support is in 
> Edge/Chrome/Firefox/etc (>60% of browsers per CanIUse and set to 
> increase steadily), the advantage is even greater. 
>
> * Man, when does Safari support anything in a timely fashion? It's the 
> worst of the major browsers. 
>
> > I think a short demo may help. 
>
> As I said, all of gwern.net is already a demo of using lazy loading 
> with Pandoc-generated HTML pages, since September 2019 and ~880k 
> pageviews (to be more specific), and I linked 
> https://www.gwern.net/Faces as an image-heavy page which benefits 
> enormously from it. I have gotten no complaints about lazyloading, and 
> observed no breakage, and that's why I am bringing it up now. I would 
> not suggest anything I haven't already used myself. 
>
> It seems like a pretty mature tech at this point which almost all 
> Pandoc HTML users would benefit from. Making it an option for a while 
> would be fine, to be conservative and let people test it out and see 
> that it works as I claim it does, but it'd be a great pity to keep it 
> *permanently* opt-in and additional work, because you know that means 
> that only a tiny percentage of Pandoc users will ever know about 
> (there are so many features to remember) or be able to use it, because 
> they would have to update scripts or build processes (to which they 
> might not have easy access) to enable it. This is the sort of 
> universally-applicable optimization the tool should be opinionated 
> enough to do for you to make your life better. 
>
> > At least until the Chrome printing problem is solved (although I'm hard 
> pressed to remember when I last printed a web page other than a receipt. 
> I'm old school enough to want to have those on paper.) 
>
> I actually can remember printing something out in the past year - 
> photos for my grandparents! Also once in a while, airline tickets as 
> backups. Other than that, yeah, I'm hard-pressed to remember the last 
> time I printed out any kind of webpage which might plausibly have been 
> written in Pandoc. But workflows will differ: Wikimedia, I think, has 
> to cater heavily to lower education where students/teachers print out 
> a lot of stuff to work on in class etc. 
>
> -- 
> gwern 
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/dfe2404e-87d8-4425-8998-3965e0f5ddf8%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 10415 bytes --]

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 707 bytes --]

About the ePub3: does it really make sense to have lazy load images there 
even if ePub3 readers support it or fall back silently?

It may be another reason to support it as an option, where the ePub3 writer 
defaults off, and the html5 writer can defaults off now and defaults on in 
the future.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/1d9aa4f2-759d-4d36-9410-8211728beede%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1033 bytes --]

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Gwern Branwen]

On Fri, Mar 20, 2020 at 6:13 PM Kolen Cheung <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> You can complain all you want about Safari, but it is still a major browser. And personally I will quit the website I was browsing that breaks on Safari, unless it is like some banking website that I have to rely on.

Unless you have some reason to think that it breaks on Safari despite
no mention of that anywhere and my testing and standard browser
behavior, I am not sure why you keep going on about Safari.

> Another example question is how about `wkhtmltopdf` PDF output in pandoc. It may not breaks. But you didn't mention it and we didn't tested it. So it is another potential thing to test first.

If you use wkhtmltopdf enough that it is a concern, it would
presumably be the work of an instant for you to check using the
demo... I installed the latest wkhtmltopdf to check, tested /Faces
with wkhtmltopdf 0.12.5 and it appears to work just fine:
https://www.dropbox.com/s/sac9jeq2smmh4bl/2020-03-20-wkhtmltopdf-gwern.net-faces-lazyloadtest.pdf
(Parts of my CSS aren't rendered perfectly, unsurprisingly, but the
images themselves look fine.)

> About the ePub3: does it really make sense to have lazy load images there even if ePub3 readers support it or fall back silently?

The question there is whether we need to further complicate the HTML5
or EPUB3 code by specially disabling the lazy loading code just for
Markdown->HTML5->EPUB3. My point is that as far as can easily be told,
it should be completely harmless and therefore we don't need to
special-case the EPUB3.

-- 
gwern
https://www.gwern.net

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 3329 bytes --]



On Friday, March 20, 2020 at 3:35:55 PM UTC-7, Gwern Branwen wrote:
>
> On Fri, Mar 20, 2020 at 6:13 PM Kolen Cheung <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
> <javascript:>> wrote: 
> > You can complain all you want about Safari, but it is still a major 
> browser. And personally I will quit the website I was browsing that breaks 
> on Safari, unless it is like some banking website that I have to rely on. 
>
> Unless you have some reason to think that it breaks on Safari despite 
> no mention of that anywhere and my testing and standard browser 
> behavior, I am not sure why you keep going on about Safari. 
>
> You said

> Man, when does Safari support anything in a timely fashion? It's the 
worst of the major browsers. 
 

> > Another example question is how about `wkhtmltopdf` PDF output in 
> pandoc. It may not breaks. But you didn't mention it and we didn't tested 
> it. So it is another potential thing to test first. 
>
> If you use wkhtmltopdf enough that it is a concern, it would 
> presumably be the work of an instant for you to check using the 
> demo... I installed the latest wkhtmltopdf to check, tested /Faces 
> with wkhtmltopdf 0.12.5 and it appears to work just fine: 
>
> https://www.dropbox.com/s/sac9jeq2smmh4bl/2020-03-20-wkhtmltopdf-gwern.net-faces-lazyloadtest.pdf 
> (Parts of my CSS aren't rendered perfectly, unsurprisingly, but the 
> images themselves look fine.) 
>
> It is not my concern, but the communities'. You need to get this in order 
to push for any feature that is affecting a huge community, and arguably 
many communities (say including Rmarkdown and Jupyter Notebook.)
 

> > About the ePub3: does it really make sense to have lazy load images 
> there even if ePub3 readers support it or fall back silently? 
>
> The question there is whether we need to further complicate the HTML5 
> or EPUB3 code by specially disabling the lazy loading code just for 
> Markdown->HTML5->EPUB3. My point is that as far as can easily be told, 
> it should be completely harmless and therefore we don't need to 
> special-case the EPUB3. 
>
>
*should. But did you test it? Again the point is making it default will 
affects a lot of people, many communities. "Should" is not enough. (May be 
it is, because pandoc has been making unpredicted breaking changes to 
others as well. Often they are not foreseen though.)

Again, it is not my or your decision. Your job is to convince people it is 
ok. And my comment is that you're not good at your job.

I think my suggestion that takes a pragmatic approach (to make it an option 
first) is helping you to move this feature forward. Fine if you don't like 
it. But I think your defensive approach is not helping to make this moving 
forward.

Just my 2 cents. Leaving this conservation as I think I know enough and 
that's all I want to (and can) contribute to this issue.

> -- 
> gwern 
> https://www.gwern.net 
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/81771c0d-dc1c-48bb-ba49-6f8e28b0e47b%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5695 bytes --]

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Gwern Branwen]

On Fri, Mar 20, 2020 at 6:44 PM Kolen Cheung <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> You said
>
> > Man, when does Safari support anything in a timely fashion? It's the
> worst of the major browsers.

The question of when Safari will implement a new feature beneficial to
its users is irrelevant to our decision here, since Safari users are
no worse off if we enable it. As I have repeatedly said now, it is
backwards-compatible in that browsers which do not have this feature
implemented (Safari) will simply ignore it. If you have reason to
think that Safari does not despite lack of discussion and complaints,
you should say so, and not keep talking about how bad it would be to
break on Safari. I agree it would be unacceptable to break on Safari!
No one is disputing that would be a very bad thing! But pretty sure it
doesn't?

> Again, it is not my or your decision. Your job is to convince people it is ok. And my comment is that you're not good at your job.

And while we are making personal comments here, let me comment that
you have carelessly repeatedly failed to read things I explained
clearly or brought up as if not already discussed, and you have lazily
put the onus on me in many ways. You could have checked that
wkhtmltopdf worked in seconds and mentioned that it worked fine, but
instead you put it on me, so I instead spent several minutes learning
how to use wkhtmltopdf, discovered that Ubuntu ships a badly-broken
one, installed the latest version manually, ran it on the toughest
page on gwern.net, read through it looking at various images to
manually check, and uploaded the results for all to see.

-- 
gwern

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[John MacFarlane]

While I agree about "it would be crazy," I would want to be
confident that common actual EPUB readers don't break when
reading EPUBs with this attribute, before building it into
pandoc.

Gwern Branwen <gwern-v26ZT+9V8bxeoWH0uzbU5w@public.gmane.org> writes:

> Everything is always terrible in web development, so I assume EPUB3
> readers are indeed spotty in support of features; but ignoring
> 'invalid' attributes isn't really a 'feature' in any conventional
> sense. It's just what you need to do to have a EPUB3 reader which
> doesn't break at the drop of a hat the instant someone makes a single
> syntax error or HTML5 introduces a new attribute anywhere. It would be
> crazy for any EPUB3 reader author to decide to, unlike most/all HTML5
> browsers, be ultra-strict and break on encountering an unknown
> attribute, especially given that HTML5 is far from done and is adding
> new stuff all the time. (This being a case in point.)
>
> -- 
> gwern
> https://www.gwern.net

Re: Proposed new HTML5 feature: lazy loading images (#6197)

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 3565 bytes --]



On Friday, March 20, 2020 at 4:00:26 PM UTC-7, Gwern Branwen wrote:
>
> On Fri, Mar 20, 2020 at 6:44 PM Kolen Cheung <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
> <javascript:>> wrote: 
> > You said 
> > 
> > > Man, when does Safari support anything in a timely fashion? It's the 
> > worst of the major browsers. 
>
> The question of when Safari will implement a new feature beneficial to 
> its users is irrelevant to our decision here


But you did commented on it and you can't expect people to ignore your 
comment.
 

> , since Safari users are 
> no worse off if we enable it. As I have repeatedly said now, it is 
> backwards-compatible in that browsers which do not have this feature 
> implemented (Safari) will simply ignore it. If you have reason to 
> think that Safari does not despite lack of discussion and complaints, 
> you should say so, and not keep talking about how bad it would be to 
> break on Safari. I agree it would be unacceptable to break on Safari! 
> No one is disputing that would be a very bad thing! But pretty sure it 
> doesn't? 
>
> > Again, it is not my or your decision. Your job is to convince people it 
> is ok. And my comment is that you're not good at your job. 
>
> And while we are making personal comments here


It is not personal. I've been there when I first join the pandoc community 
and trying to push a feature with very long, elaborated essay trying to 
convince everyone it is the right thing to do. But it is not effective. As 
I repeatedly said, you can be much more effective if you are defensive and 
think we are against you. There's always some critics that are really 
missing the mark (sometimes because they are ignorant. Me in this case.) 
And you should trust the community (and practically just jgm) that they can 
discern that. Feedbacks are almost always good. Handling them well and your 
feature can push forward more effectively.
 

> , let me comment that 
> you have carelessly repeatedly failed to read things I explained 
> clearly or brought up as if not already discussed, and you have lazily 
> put the onus on me in many ways. You could have checked that 
> wkhtmltopdf worked in seconds and mentioned that it worked fine, but 
> instead you put it on me, so I instead spent several minutes learning 
> how to use wkhtmltopdf, discovered that Ubuntu ships a badly-broken 
> one, installed the latest version manually, ran it on the toughest 
> page on gwern.net, read through it looking at various images to 
> manually check, and uploaded the results for all to see. 
>
> Again I don't use that. In an ideal world I have plenty of time and can 
help testing that too. But I don't (and frankly you made me want to involve 
less so again you could have been more effective in drawing in people to 
help testing, not away.) But as it is going to affect users who use that, 
it should be tested too. (Or may be more educated people can say what it 
won't have a problem. But again that's something to be discussed.) Not 
breaking other people's workflow is a priority in the pandoc community. Not 
a requirement by me but I just pointed it out.
 

> -- 
> gwern 
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/e4bb24b3-c264-46d7-b7e6-e242a577c599%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5177 bytes --]