@gareth Thank you for pointing this out. It’s been solved in the newest version.
The enqueue of pagination CSS was actually intentional, with the following logic: stylesheets are supposed to be loaded in document
<head>; however, in most themes, it’s too early at that point to know if the page content will need the styles or not, because the content (and any included template) is rendered inside
<body> which comes later. Many plugins enqueue all their CSS files on every page for this reason, and they’re cached by the browser.
This issue doesn’t apply for JS assets, because it’s best to load them at the bottom of the document. By that point, any templates have already been rendered so we know what assets are needed.
I did confirm that it’s technically possible to use a
<link> tag within document body instead of head.
<link> element can occur either in the
<body> element, depending on whether it has a link type that is body-ok. For example, the
stylesheet link type is body-ok, and therefore
<link rel="stylesheet"> is permitted in the body. However, this isn’t a good practice to follow; it makes more sense to separate your
<link> elements from your body content, putting them in the
– From MDN: <link> The External Resource Link element
So it’s a compromise between following best practices (put all stylesheets in head), and loading the minimal amount of assets needed for a page.
In this case, I decided to try the latter approach. I updated the enqueue logic so the paginator CSS is conditionally loaded (once only) just before it’s needed in a template. It’s working fine, so I’ll consider applying the same technique to other modules in the plugin that require CSS.