Footnote reference number is subscript, not superscript

@rkupadhya

Just tested the “wp-Typgraphy” plugin. It does not affect the superscript footnote referrers in GeneratePress.

Please include theme information in your follow-up response. Many things work differently in one theme as opposed to another theme.

• This reply was modified 5 years, 4 months ago by pewgeuges.

@rkupadhya

Thank you. Sorry for mentioning the setting; you may change it back to Yes.

The fix involves two steps, both related to inline CSS:

1. In Footnotes’ Custom CSS:

Replace:

.footnote_plugin_tooltip_text {
	position: relative !important;
	top: .7em !important;
	color:red;
}

With:

.footnote_plugin_tooltip_text {
	color:red;
}

2. In Path theme’s Custom CSS:

Remove:

.footnote_plugin_tooltip_text {
	position: relative;
	top: -2em;
}

The first edit, in the plugin, removes the subscript. Then the same selectors in Path’s Custom CSS are not overridden any longer, and need to be deleted to lower the referrers’ vertical alignment. After both edits, referrers display as regular superscript.

My apologies for changing the plugin’s public style sheet. Footnotes contained three not cross-theme-compatible and not cross-browser-compatible rules that needed to be deleted as soon or late as for 2.0.6 on November 5, given they were causing exactly that same behavior in some browsers and in a number of themes:

.footnote_plugin_tooltip_text {
    vertical-align: top !important;
    position: relative !important;
    top: 0.6em !important;
}

Previously, your website’s footnote referrer display was correct because Footnotes’ style sheet had also this rule:

.footnote_plugin_tooltip_text {
    vertical-align: top !important;
}

But it cannot remain, because if alone, it raises the referrers above caps height.

Alternatively, you may leave everything as-is and just add the above rule, either in Footnotes’ Custom CSS or in Path’s Custom CSS (or in both). But as mentioned, that solution doesn’t warrant cross-browser compatibility. Therefore we need to ditch all these tweaks and revert to plain superscript.

• This reply was modified 5 years, 4 months ago by pewgeuges.
• This reply was modified 5 years, 4 months ago by pewgeuges.

@rkupadhya

You don’t need to do anything else, the custom CSS is fully functional. A string added in the new text area is saved and added as inline CSS in its place in the page header, in WordPress v5.6 for instance.

Thank you for reporting the bug of the “Settings saved” message. Current Footnotes v2.5.0 displays it still in WordPress v5.5.3, but in WordPress v5.6 it is gone, while other plugins (tested with wp-Typography) still show the message.

I need to investigate this bug, that I didn’t notice before you pointed it out. A Google search done for the purpose brings up an unrelated new bug under the same WP version: https://ww.wp.xz.cn/support/topic/weird-behaviour-after-recent-wordpress-5-6-update/ Apparently I missed out on a disruption; jQuery issues, declared as critical with v5.6, have been fixed in Footnotes. I still can’t figure out what this is about.

Beside that, as you are already having Custom CSS in Footnotes, the dashboard suggests to copy-paste it into the new text area and set the Boolean to No, for a clean and easy-to-use UI where the legacy boxes would disappear, and only the new one under its own tab will remain. (After being hidden, the legacy box and its mirror should empty automatically as undisplayed settings are zeroed.)

But the new issue about the missing confirmation message is new top priority since the disturbing lack of confirmation pulls UX down.

Thanks!

• This reply was modified 5 years, 4 months ago by pewgeuges.
• This reply was modified 5 years, 4 months ago by pewgeuges.
• This reply was modified 5 years, 4 months ago by pewgeuges.
• This reply was modified 5 years, 4 months ago by pewgeuges.
• This reply was modified 5 years, 4 months ago by pewgeuges.