very happy with the removal of all the duplicate settings, although the extension stuff could go inside fix-up easily. Just add a separator and whack 'em at the bottom.

I do find the names extend footnotes until next footnote and extend footnotes until next header or footnote a bit too overwhelming. I would suggest something more like extend footnote selection/content up to next footnote and extend footnote selection up to next header.

unrelated to this PR but, shouldn't that font size stuff be a SpinWidget?

I've rebased out the footnote extension changes, let's keep that discussion in #13554. Just means I'll need to rebase whichever one of these is merged first.

If we can, I'd be all for getting rid of the "smaller" stuff, as it is redundant with choosing a font size (80%) in the "In-page footnote font size" submenu.

But please have a look at (no time myself to re-read all that - and this PR - this evening):
#5863 (comment) (where I removed them)
#5863 (comment) (where I put them back)
and see if how you manage and migrate that solves all my worries.

unrelated to this PR but, shouldn't that font size stuff be a SpinWidget?

These font size items works with each their own id - styletweaks are not dynamic, they are just stored as IDs to static bits of CSS. Having a SpinWidget would need a lot more work to pick the right ID or need some more dynamic CSS spitting, not worth the effort (and I like these menu items, easier that having to play with a SpinWidget).

Pushed an alternative that allows getting rid of "smaller" while keeping all current behavior/combinations in #13639. Not sure if it's worth it though or if this simplification is enough.

Looks like you'd be migrating only global tweaks.
What about tweaks set specifically for an already opened book ? The won't be there when that book is reopened ?

Good point, will look into migrating per-book settings as well. (and fix the hint name)

In the mean time, thoughts on either of these menu placements? (and of course hint names, I'm bad at those)

"Smaller footnotes" is just the current 80% setting on top-level footnote blocks, the various sizes would be the same hint with different values. (whereas the "Force" variants are the hint with inside-inpage-footnote that applies to all blocks inside a footnote).

Everything in the submenu would conflict to reduce confusion.

Annoyingly, sometimes "small" footnotes are bigger if the body text sets a font smaller than 0.8rem... I guess the only way to fix that would be a -cr-scale-font: 0.x that scales the font after regular font-size computation, but I don't want to bloat this PR further.

I personally hate both those screenshots, but hate the left one a lot less, does it really need to use word “force”?

All the style tweaks are about forcing things, so indeed that seems redundant at best.

I personally hate both those screenshots, but hate the left one a lot less

Forget about how it looks. But what does it do? ;-)

I'm not quite sure what this is trying to say. What's the same hint with different values?

"Smaller footnotes" is just the current 80% setting on top-level footnote blocks, the various sizes would be the same hint with different values. (whereas the "Force" variants are the hint with inside-inpage-footnote that applies to all blocks inside a footnote).

Sorry, I should have elaborated a bit more. I pushed the left version without the wording change.

I just moved the "smaller footnotes" hint, which is

*, autoBoxing {
    -cr-hint: late;
    -cr-only-if: inpage-footnote;
        font-size: 0.8rem !important;
}

Into the footnote size submenu. This keeps the same behavior that's in master right now if you select one of the duplicated "smaller" in-page footnote options. (i.e. within footnotes, relative font-sizes work)

I wanted to find some wording that distinguishes this from the footnote font-size tweaks, which override the size of each (block) element in the footnote to e.g. 0.8rem. (i.e. almost everything in the footnote is forced to the same size)

This has always been confusing in my opinion. If you select the smaller footnotes, what do the footnote font-size hints do? Maybe "override" would be a wording that's more consistent with other tweaks?

In any case, I just split out the duplicated "smaller" part from the footnotes and moved it to the submenu for now (and specified that it's 80%, because all the other size options also specify the size).

@poire-z

If we can, I'd be all for getting rid of the "smaller" stuff, as it is redundant with choosing a font size (80%) in the "In-page footnote font size" submenu.
But please have a look at (no time myself to re-read all that - and this PR - this evening):
#5863 (comment) (where I removed them)
#5863 (comment) (where I put them back)
and see if how you manage and migrate that solves all my worries.

This doesn't quite get rid of it. I don't think it's possible without fundamentally changing behavior as you were worried about and I think it's valuable to have a tweak that just changes the size at the top level of the footnote (or some way to scale the font-size of a whole block in crengine).

This should at least be less cluttered than the duplicated "smaller" footnote hints and correctly does conflicts to make it clear that the font-size tweaks override the "smaller" variant.

Ok, I prefer this one.

I couldn't find any context for why it's set up this way

Initially, we only had the pairs "normal" and "smaller", which were not "forcing": no inheritance to sub elements (because otherwise it would have killed any superscript in the footnote), so possibly having no effect if there's nested block elements and the publisher sets a font size on the sub element.

Later, I added support for -cr-only-if: -inline, which allowed me to target all nested block elements (with inside-inpage-footnote), while preserving inline (superscripts) relative font size.

The 2nd behaviour is probably the best, and could be the only one.
I would have been ok killing the 1st one, and just forcing the 2nd to users, they would probably not notice - and those who do can make their own book style tweak when it has unwanted effect.

But as you are keeping this 1st behaviour (that I'm willing to call legacy) buried inside the "Footnote font size" submenu, I'm quite fine with this PR.

No idea if the migration will handle all cases, or prevent some combinations (smaller FB2 but normal EPUB ? probably rarely used), so trusting you.

No idea if the migration will handle all cases, or prevent some combinations (smaller FB2 but normal EPUB ? probably rarely used), so trusting you.

I tested many different combinations, but this obviously limits possibilities compared to what's in master. e.g. you can't have regular size EPUB footnotes and smaller classname footnotes as default. (or in a single book if such a book exists)

As you say, probably rarely used though and the newer footnote font-size tweaks already work the same way and affect all footnotes, so this is probably better anyway.

Fine with the latest comments and changes.

Remaining, from my previous review comments:

#13613 (comment)

Looks like you'd be migrating only global tweaks.
What about tweaks set specifically for an already opened book ? The won't be there when that book is reopened ?

#13613 (comment)

onetimemigration also handles global settings. It was introduced by you in April 2021.
settings_migration has had minor stuff added after 2019, but given that it's driven since Apr 2021 by your PR with a last_migration_date < 2019 condition, it has had no effect and use.
I'd be for keeping everything in onetime_migration.

#13613 (comment)

May be it could have a more verbose description, mentionning it's limited (no inheritance, so possibly no effect - the reasong why you qualitied the others with "force" all along).

settings_migration handles global and per-book settings. I switched to using that and this branch now handles both correctly (that's where the false cases in the migration table come from, global tweaks are only true or nil as far as I understand)

since Apr 2021 by your PR with a last_migration_date < 2019 condition, [settings_migration] has had no effect and use.

I don't think that's quite correct. settings_migration is also called in readerui.lua each time any book is opened and actually re-runs the same migration each time even if it was already applied. I didn't want to touch the whole migration here because it would be a bigger change, but I'm happy to merge them into one place that handles both global and per-book (and actually also respects/sets last_migration_date for per-book settings)

Oh, you mean it's alright, and the correct place, to have per-book (docsettings) settings migration ?
And that if we hadn't touched that file for years, it's because we just haven't had the need to migrate past opened book settings ? Strange that we haven't had the need, but ok.
Ok then.

"This branch has conflicts that must be resolved". Letting you handle this.