Earth Notes: On Website Technicals (2020-05)

Given Firefox's aggressive image-loading laziness (deferring anything not actually in the viewport), I am making all the images on the home page lazy, bar the first big one (which may get inlined for lite/AMP anyway).

I am also aiming to adjust the image insert mechanism to allow me to place such carousel images in tables etc (eg not as floats).

The warm up to this is inserting a hero image for the most popular page of the selection inserted automagically in the foot of each non-lite page.

There is now a respsml class for responsive images (up to) 33% of main container width, that will be resized down if necessary, and that will have a srcset and a wrapper link created. This is in test on a couple of pages. There are still some rough edges to fix.

For visitors to the full-fat / desktop version of the site, I am considering enhancing select images for displays with a pixel density greater than 1, ie more physical pixels than CSS pixels.

The most obvious candidates are the page-top hero images, which are there to be pretty, and could be made prettier for such devices.

For reference: my MacOS Air laptop is 1440x900 (pixel-ratio 1), and my Fairphone 3 is 2160x1080 landscape (pixel ratio 3).

In portrait, which is probably how most smartphones are used, according to MyDevice the widest smartphone screen listed is 1440 physical pixels.

It may therefore be worth providing a 1440w image (x1.8 for the 800 hero) option for those devices with ratio greater than 1.

I probably do not want to inflate my existing byte limits per image (absolute and per CSS pixel). So I should not try for a larger image where the x1 image is at or close to the limit.

I also do not want to falsely inflate an image, so would not do this where the source image is no larger than the CSS render size (eg 800px). In fact, probably not unless it is at least the inflated intrinsic size (eg 1400w).

In any case something like this might form part of a media query (min-device-pixel-ratio: 1.5) or the newer (min-resolution: 1.5dppx) in sizes or on a source line in picture.

A simple first step may be on desktop mode to only use the 640px image if the viewport width is 640px or less and the resolution is not (much) higher than 1 eg (max-resolution: 1.5dppx). Or maybe use (max-resolution: 280dpi) for the latter for wider support, and to better pick out high-end devices where users may be less bandwidth-sensitive. (I could also throw in a maximum height so that the hero does not take too much of the vertical display area.) Older browsers that do not recognise dppx may wastefully pull in the full 800w image.

Testing the water, I am now selecting the 640w hero image with (max-width:640px) and (max-resolution:280dpi).

Podcast RSS Images

As a second experiment for today, I am including each episode's primary SQTN, if any, in the podcast RSS feed entry for that episode. Possibly I should restrict to those that are square and in a reasonable size range (1400w to 7000w). But for now I am assuming that most feeds won't use such an image at all, and that others will quietly ignore anything that they do not like.