Earth Notes: On Website Technicals (2020-07)

One thing that has been annoying me with responsive images in figure and similar, is that they only take ~90% of the container width (eg exactly 720px from the 800px desktop container, 560px of 640px mobile) because of wide margins.

I have now added a class resp90 to be a better approximation. (The image autogenerator builds a primary image with natural width 90% of that of the page container, plus lower- and higher- resolution versions as needed.) This may save ~10--20% of image bandwidth for such placements.

The rebuild out to 4x image density where possible is done.

I'm now umming-and-ahing about whether to extend this higher-density support to the (non-body, non-informational) hero images. Even for the 800w top-of-page heroes, more than 100 of them are far enough below the file-size (bytes) limit that at least some increased density is likely to be possible.

Supporting more dense heroes is likely to be messier than for body images.

I'm also still not clear how/if any of my visitors will actually benefit from the higher resolution rather than just getting higher data usage! Do they have better eyesight than me, for example?

Hootsuite re-enabled

Hootsuite has been abandoned for Vestemi's main social media work. There is a little time still to run on the annual payment already made. So I'm using it again to promote EOU articles, but on the @EarthOrgUK Twitter channel directly now.

Many new displays such as on smartphones and laptops have more than one pixel per CSS pixel. Common densities include 1x, 1.5x, 2x and 3x. (2.5x and 4x are fairly common too; I can add them later if I wish.) My ageing MacBook Air is just 1x. Newer 'Retina' Macs are higher. My Fairphone 3 smartphone has a pixel density of 3x.

I have started providing support for denser devices by adding wider images to the srcset, up to the 3x multiplier. I retain the same file size limit of ~80kB for desktop body images, which prevents some already large ones getting denser-display support.

This added support is only for the 'full' pages, nominally desktop, but fully responsive for smartphones (etc) too. The lite and AMP pages do not include these bigger image options, avoiding data plan nasties, and a bunch of extra HTML boilerplate too.

This is still very new, likely has many bugs to be squashed, and only applies to a subset of 'body' images, rather than the decorative hero images. I will likely extend a simplified version to them soon.

A typical image may now have six entries in its srcset, from the smallest mobile version to the largest dense-display version. More than 4x range in width, and ~20x in area.

Here is the HTML for one small right-float image, natural width 400 (CSS) pixels, in all its glory: <img class=respfloatr width=400 height=300 alt="voltage multiplier redux" title="voltage multiplier redux" style=background:#999 loading=lazy srcset="img/a/b/turbine-wind-tiny-voltage-multiplier-redux.l93374.1200x900.jpg 1200w, img/a/b/turbine-wind-tiny-voltage-multiplier-redux.l93374.800x600.jpg 800w, img/a/b/turbine-wind-tiny-voltage-multiplier-redux.l93374.600x450.jpg 600w, img/a/b/turbine-wind-tiny-voltage-multiplier-redux.l93374.400x300.jpg 400w, img/a/b/turbine-wind-tiny-voltage-multiplier-redux.l93374.320x240.m.jpg 320w, img/a/b/turbine-wind-tiny-voltage-multiplier-redux.l93374.270x202.m.jpg 270w" sizes="(min-width:800px) 400px, 50vw" src=img/a/b/turbine-wind-tiny-voltage-multiplier-redux.l93374.400x300.jpg>

Name Hash

I also put in a fix to handle long Gallery names for IMG such as http://gallery.hd.org/_tn/std/mechanoids/_more2007/_more09/turbine-wind-tiny-battery-end-monitoring-LED-and-optoisolator-and-smoothing-capacitor-and-Zener-spike-killer-and-dump-load-and-blocking-diode-circuit-in-plastic-box-in-shed-outhouse-connecting-to-battery-and-laptop-closeup-4-DHD.jpg by replacing all but the first word with a hash of the name.

This hash only has to be long enough and good enough to avoid collisions with EOU's auto-generated images. So I have used the venerable MD5 with its 32-hex-digit result, prefixed by the first word (hyphen-delimited) of the original name if that word is not too long. Any image with a base name of over 42 characters is subject to this process, so a few URLs will get shorter.

I could use SHA256 with a 64-hex-digit hash, but in that case I might start hashing the names at something more like 70 or 80 characters.

I have tweaked the way that I'm generating the sizes attribute alongside srcset for an IMG.

(Old unfashionable way: simply have sizes=${ImaxwidthPC}vw, where ImaxwidthPC = nominal Image max width as PerCentage of container.)

If the nominal image width is wider than the container, ie is allowed to bust out of the container and may be full bleed, then sizes is 100vw. (The v.Nu validator tells me that sizes cannot be omitted in this case, even though other sources suggest otherwise.)

Generally, however, a formula is used of the form (min-width:${FWPX}px) ${CALCMAXW}px, ${ImaxwidthPC}vw. Here FWPX = Full Width of the page container in CSS PiXels, ImaxwidthPC = nominal Image max width as PerCentage of container, CALCMAXW = the (maximum) CSS image slot width implied by FWPX and ImaxwidthPC.

That defaults to the appropriate fraction of the viewport, assuming that the viewport constrains the page container's width.

(This still is not quite right for layouts where there is a page margin, ie everything other than AMP, but fixing that is for another day.)

For (usually desktop) browser windows that have a viewport wider than the page container (the reason for having the container in the first place), the leading media-query formula limits the image slot width to that appropriate when the page container is at its maximum width.

But then finally, when the natural width of the image is less than the maximum allowed (eg an image that is allowed to be full width, but actually is not that wide in some or all page flavours), the media query is adjusted to limit the image slot width before the container hits its maximum, to reflect that.

Simples!

I hope that this makes for slightly more accurate requests from browsers. Though given the current setup, probably no bytes will yet be saved!

With luck this also helps me fold in support for higher-density browsers at some point...

EOU CSS assumed a desktop page and then tweaked different aspects of it down for lite and AMP pages. The lite pages were allowed to be as wide as desktop pages at 800px, to be 'lite' desktop pages, but that led to a number of anomalies and fixes, including extra CSS injected to support 'stretchy' lite hero images, and other CSS injected to avoid image distortion in AMP views.

The basic (maximum, container-enforced) page width is now 640px. Just the desktop CSS overrides that now, to allow 800px maximum.

(Other aspects had already been shifted to mobile-first. Eg all floats are right-only in mobile (lite and AMP) views, and the desktop adds CSS to allow the nominal-left floats to actually float left when the page is wide enough.)

In theory it should be OK to strip out any </p> to minify HTML.

In practice that does not play so well with <ins>...</ins>, which (at least in the W3C Markup Validation Service) wants to see the closing tag if there was an opening one.

This then requires a slightly more complex mechanism: defer inserting </p>, and drop it if the next thing is <p>.

Dropping these before a heading (typically h2) and div and a few other common cases EOU pages saves a little more space without semantic change.

I tweaked and re-ordered the CSS for AMP pages to be a tiny bit smaller (two bytes!) and compress better, and one page only is currently having to do without the social media buttons because of an overlarge header.

Since I have been itching to do it for a while, I'm now stripping out 'optional' HTML closing tags to help minify. To reduce the risk of accident, and in any case it covers most of my usage, I'm only stripping them out where they appear at the end of a line. I do allow a couple of passes though, since two may appear in sequence.

The magic optional tags for this round are: </th> </td> </tt>, and in practice </td> is the most numerous.

These changes tend to make a sub-1% reduction in HTML size, even less after compression.