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

[Kolen Cheung <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- 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 --]