Earth Notes: On Website Technicals (2018-11)

IMG tags on EOU can now take an alt attribute instead of trying to derive text from the final part of the image name (though that remains sufficient and easier in many cases). This especially helps for older images to avoid renaming them. Also it makes possible use of characters such as '/' and '-' otherwise unavailable due to the nature of the automated text extraction.

Because the alt text is going to be passed around between shell and HTML and who-knows-what, anything that looks like a significant metacharacter to any of those is forbidden, especially quotes, '&', '<' and dollar signs.

I have been having fun making the new IMG tag work with dynamically-generated images and with SVG images. (In neither case should resized copies be made.)

Also I have introduced a new respW CSS class, identical to resp, except that the IMG-support code allows images up to twice the target main container width on desktop. This works for large display images that are allowed to spill into the margins.

I have just adjusted the hero-banner HTML generation to be AMP-compatible. I am also for now suppressing the optional table of contents for AMP, since it uses details/summary which AMP rejects.

Upshot: I now have a normal body page with a hero banner and body photo(s) that passes AMP validation. Even with the hero image inlined! Hurrah!

I am plodding on with making pages more AMP-compatible, in particular dealing with common image use cases with EOU's new 'IMG' tag, which can be converted to something legal for AMP (amp-img). A helpful feature for the non-AMP pages it that IMG allows automatic pre-rendering and use of smaller versions of such images for non-desktop, and makes for some extra visual and HTML uniformity.

There are plenty of cases where something is "lost in translation" at the moment, such as alt text not auto-extractable from the image name. (There are also AMP-illegal inline styles in various places, etc.)

I also do not have a working validator tool for macOS, which means that auto-generation of pages cross-platform is not yet possible. Indeed I have opened a couple of issues with the AMP folk:

• amphtml-validator cli not created for macOS.
• Support for details / summary tags.

But I have today passed validation for a version of the 'about' page that contains an image. So I can be confident that auto-generated AMP versions of all the main pages should be possible.

(My current plan, if I put up an AMP page set, is to have any that cannot be correctly auto-generated, eg because of some AMP-illegal tag, be redirected to the mobile (m.) page in the interim.)

link rel best practice

In an enquiry about how to properly link rel different page variants (desktop, mobile, AMP) together, (AMP project issue: how to put canonical for website and mobile site) John M of Google said:

... In short, you link to the AMP page from your canonical, and you link back from the AMP page to the canonical. So to give an example, with separate mobile pages:

https://www.example.com/desktop/page.html (this is the desktop version of the page) has:
<link rel="alternate" media="only screen and (max-width: 640px)"  href="https://m.example.com/mobile/page.html">
<link rel="amphtml" href="https://a.example.com/amp/page.html">
<link rel="canonical" href="https://www.example.com/desktop/page.html">

https://m.example.com/mobile/page.html (this is the smartphone version of the page) has:
<link rel="canonical" href="https://www.example.com/desktop/page.html">

https://a.example.com/amp/page.html (this is the AMP version of the page) has:
<link rel="canonical" href="https://www.example.com/desktop/page.html">

So the canonical page links out to all alternates, and the alternates need only link back to the canonical (ie not amongst one another).

In the case where the AMP version of a page cannot (currently) be generated my current plan is to have it redirect (302?) to the m. page instead, and probably not get an alternate link from the desktop page.