The EPUB footnotes have been changed in a strange way

[cited89426582]

After the recent update to InDesign 19.4, I noticed some changes made to how InDesign handles footnotes for EPUBs. Previously, it used a <div> with <p> for footnotes, which worked fine. However, they've now switched to using a <list>, which is causing issues.

This change completely overlooked that InDesign footnotes also have numbering and preceding characters. As a result, the output is quite ridiculous. Of course, I can fix this by changing the list-style to none in the _idFootAndEndNoteOLAttrs style, but the update mentioned, "Version 19.4 provides fixes for important functional, stability, and performance issues," yet the EPUB part seems to be a mess... I don't know what to say.

I'm using the Traditional Chinese environment, and I'm not sure if other language versions of InDesign 19.4 have similar issues.

[HARSHIKA_VERMA]

Hi @cited89426582,

We are sorry to hear about the issue. Would you mind telling us if it's happening with all files or with this specific file? Does that happen with other language as well? Is it possible for you to share the file with us for investigation? If yes, please share the file with me over a private message so that we can check at our end.

We will try our best to help.

Thanks,

Harshika

[MY371439287cqn]

Any further updates on this issue? Thanks.

[James Gifford—NitroPress]

What precisely is the issue?

I confirmed (after some mixed results) that v19.4 is indeed using a different structure for footnotes and endnotes — as noted, the HTML list model instead of grouped paragraphs.

However, this passes EPUBcheck without a hiccup, and does not seem to bother Ace, either.

What issue do you see as needing further resolution?

(I am assuming this change was made in concert with, and with the approval of, the other accessibility changes noted in other topics. If it's in conflict with accessibility, Ace doesn't seem to mind and I've seen no other claims.)

[MY371439287cqn]

So that means there will always be a list number before the original footnotes' numbering, since v19.4 is using HTML list model rather than grouped graph?

Any action I can do if I need to take out the list number and retain the original numbering? I've tried to put a line  {list-style-type: none} in css to define, but that doesn't seem to work.

Thank you.

 

What precisely is the issue?

I confirmed (after some mixed results) that v19.4 is indeed using a different structure for footnotes and endnotes — as noted, the HTML list model instead of grouped paragraphs.

However, this passes EPUBcheck without a hiccup, and does not seem to bother Ace, either.

What issue do you see as needing further resolution?

(I am assuming this change was made in concert with, and with the approval of, the other accessibility changes noted in other topics. If it's in conflict with accessibility, Ace doesn't seem to mind and I've seen no other claims.)

By @James Gifford—NitroPress

What precisely is the issue?

I confirmed (after some mixed results) that v19.4 is indeed using a different structure for footnotes and endnotes — as noted, the HTML list model instead of grouped paragraphs.

However, this passes EPUBcheck without a hiccup, and does not seem to bother Ace, either.

What issue do you see as needing further resolution?

(I am assuming this change was made in concert with, and with the approval of, the other accessibility changes noted in other topics. If it's in conflict with accessibility, Ace doesn't seem to mind and I've seen no other claims.)

By @James Gifford—NitroPress

What precisely is the issue?

I confirmed (after some mixed results) that v19.4 is indeed using a different structure for footnotes and endnotes — as noted, the HTML list model instead of grouped paragraphs.

However, this passes EPUBcheck without a hiccup, and does not seem to bother Ace, either.

What issue do you see as needing further resolution?

(I am assuming this change was made in concert with, and with the approval of, the other accessibility changes noted in other topics. If it's in conflict with accessibility, Ace doesn't seem to mind and I've seen no other claims.)

By @James Gifford—NitroPress

What precisely is the issue?

I confirmed (after some mixed results) that v19.4 is indeed using a different structure for footnotes and endnotes — as noted, the HTML list model instead of grouped paragraphs.

However, this passes EPUBcheck without a hiccup, and does not seem to bother Ace, either.

What issue do you see as needing further resolution?

(I am assuming this change was made in concert with, and with the approval of, the other accessibility changes noted in other topics. If it's in conflict with accessibility, Ace doesn't seem to mind and I've seen no other claims.)

By @James Gifford—NitroPress

What precisely is the issue?

I confirmed (after some mixed results) that v19.4 is indeed using a different structure for footnotes and endnotes — as noted, the HTML list model instead of grouped paragraphs.

However, this passes EPUBcheck without a hiccup, and does not seem to bother Ace, either.

What issue do you see as needing further resolution?

(I am assuming this change was made in concert with, and with the approval of, the other accessibility changes noted in other topics. If it's in conflict with accessibility, Ace doesn't seem to mind and I've seen no other claims.)

By @James Gifford—NitroPress

[cited89426582]

I'm not sure about other languages, but both my colleague who produces EPUBs and I have experienced the same issue with version 19.4. Personally, I don't have any objections to the switch to using lists. I just hope that when exporting EPUBs with footnotes, the numbering from InDesign can be excluded. I understand that <ol> will naturally include numbering. Perhaps having an option during EPUB export to choose whether to include the numbering from footnotes in the EPUB would be beneficial.

[James Gifford—NitroPress]

I'd have to experiment (with the western English version), but that doesn't sound right. I typically use workarounds for footnotes, since few readers handle them well, but I don't recall them ever being structured as lists.

After a quick check, I can confirm that v19.4 is exporting footnotes as it always has, with the <div>/<p> structure... in a reflowable export, at least.

[Ruben Solér]

The exact same thing has happened to me, except I didn't know how to fix it. It appears to happen because of the new accessiblity functions for EPUB in 19.4. For those more technically minded than me, you can read more about the development of the new features here: https://github.com/ways2read/InDesignA11Y/issues/3

Hopefully these issues will be fixed sooner rather than later.

[ferformaat]

Out of the box, InDesign 19.4 is not suitable for epub footnotes and does unexpected things. It looks like it works for epub3, but only if you use the "popup" placement. You get an 'aside' paragraph. Well, maybe that's fine... 

But when you export it as normal footnotes, InDesign treats it as 'ol and li' text. And put an extra number in front of it and give a 'value' to the list - which no one wants, because you're choose our own values (fixed figures) in the InDesign footnote settings. That value is the link from note to note anchor - so it is he only number that counts.

When exporting to epub2 the same things happen.
Did they ever test this before launching?

The solution is, I think: to put a line in the CSS with:
ol {list-style-type: none} or more specifically an 'ol' only in the section 'notes'.
Hopefully, e-readers will recognize these CSS declarations.

Am I right? Or are there more settings we can use?

[James Gifford—NitroPress]

Handling of foot- and endnotes is 100% reader-dependent. Even if you apply the few feeble controlling options, any reader and any user settings can override them.

I am still not able to replicate the 'list item' format being reported, and suspect it's some subset of how notes are formatted, numbered etc. within ID. A selection of those seeing the change posting their end/footnote setup menus might help sort things out.

Strike that; for whatever reason, my exports now create <ol> entities for both footnotes and endnotes. So, definitely a change; how this affects, and is meant to affect accessibility, I have no idea. I can't believe it's a random or un-thought change, though  — my money would be on a misunderstanding somewhere or an incomplete implementation.

[James Gifford—NitroPress]

Test exports with both types of notes pass EPUBcheck without a single warning.

Ace shows some violations, entirely in the content.opf file.

Am I missing something? I cop to being only slightly familiar with formal accessibility requirements.

[cited89426582]

A more precise solution would be to use the following CSS:

._idFootAndEndNoteOLAttrs { list-style: none; }

Whether you choose to use the CSS generated by InDesign or not, simply override the style with this CSS afterward, and it will remove the styles preceding the list.

Making hasty modifications to software can indeed lead to more troubles, as seen with issues like adding linear="no" to the cover, causing failure to pass checks in epubcheck 5.0 and above. I believe this is also a significant problem.

[James Gifford—NitroPress · Accepted solution]

All right, I see it all now. The duplicate numbering is definitely a structural bug, an awkward attempt to bridge two presentation (and thus accessibility?) methods. Validation would of course show nothing wrong, since the fault is more or less in the content, not the structure.

However... if you look at the ID generated CSS, it already has that "none" declaration. It seems to work exactly as intended in both Kindle Previewer or Calibre Reader:

I suggest that faulty/double numbering is being seen in some less compliant reader?

All that said, I don't hew closely to accessibility issues, but this is definitely a bug/badly implemented feature and needs to be corrected.

I'll omit my usual sigh at the hyper-intense focus on one detail of a broken and outdated format. 🙂

[cited89426582]

I think I might have figured out my issue. My EPUB output uses CSS that I've written myself, as I don't rely on styles generated by Adobe. I've only aligned the class names, which is why this error occurred.

However, I'd like to point out that if Adobe were to change footnotes from <p> to <li> and then specify list-style: none; to remove the bullet points, it would be a completely nonsensical approach, as there is no issue with continuing to use <p>.

If the intention is to use lists, there should only be one way to do so, which is to utilize automatic numbering for lists. Therefore, there should be an option available during footnote export that allows us to choose whether to display the automatic list numbering (ignoring InDesign's footnote numbering) or to directly display InDesign footnotes.
Because the characters and numbering preceding footnotes provide bidirectional linking, if only automatic list numbering is used, I'm unsure how to navigate back after clicking on a footnote.

Thank you very much for all the responses!

[James Gifford—NitroPress]

I got lost on one of those turns; you seem to be objecting that Adobe (probably in conjunction with the Accessibility Squad) make any changes, but you can't decide which version of things you actually want. Maybe I misread you.

I agree that using a list and then suppressing numbering is an odd choice, but it is flawless from a code/structure standpoint.

I'd say that I'd rather have InDesign export the numbering in the document, regardless of the method, than hand it over for automatic list numbering. Content in print/e-book editions should be identical.

[ferformaat]

There is definitely an error in InDesign's export code concerning notes. There is a difference in the treatment of footnotes and endnotes.

For footnotes, the OL tag applies to 1 note (li) at a time. With the endnotes feature, the OL tag applies to the entire series of notes (all 'li' tags).
Furthermore, the CSS class '_idFootAndEndNoteOLAttrs' is only added to the first <ol li> in the footnote-export, so the CSS rule: " ol._idFootAndEndNoteOLAttrs {list-style-type:none;}" does not apply to the rest of the notes. That's a bug and/or a wrong CSS.
In other words. The CSS for the class "_idFootAndEndNoteOLAttrs"  only works for Endnotes and not for Footnotes.

Note: I'm surprised at how sloppy the release is on this topic. 😉

[Ruben Solér]

That was the fix I couldn't figure out myself, thanks!

[James Gifford—NitroPress]

And again — I am not seeing any of this behavior. I exported my (admittedly simple) endnote/footnote document (to EPUB3 reflowable — not sure if we've made sure we're coordinated on that) using "show footnotes as popups" and " show footnotes at end of chapter." I can't find any other meaningful structural options that might affect this process.

In the "popup" export, I got the original <p> structure for footnotes as a group.

In the "end of chapter" export, I got the new <ol>/<li> structure for footnotes.

In both cases, and for end notes in all cases, the '_idFootAndEndNoteOLAttrs' attribute was applied to all of the list-style components.

I am not seeing any oddities like those described above.

The one consistent problem I've seen, which I've bypassed so far, is that ID is writing the end notes to a list structure, and then putting the "Chapter 2" and "Chapter 3" dividing heads after this list structure, instead of separating the endnotes by chapter.

Just continuing from my long post below, I think there may be variant code out there in different (language?) releases of v19.4, which is why we're getting different results. I also think my simple file with no user CSS represents one case, and your legacy CSS and so forth might be still causing conflicts with the new methods. But in any case, there is something wrong with (at least) the end note export process. I suspect it's some very subtle code or processing problems that were not caught in testing of the new code and processes, and for one reason or another it's spinning off various faults under varying conditions.

I'm not really thrilled to set aside time to do a fully structured A-B-C test of this. 🙂

[ferformaat]

Well, James, other people do see the problem. So maybe you have to rely on that a bit too.
As I said, there is a difference in the treatment of endnotes and footnotes. (Endnotes are in InDesign a pain in the ass anyway.)
The problem doesn't only occur with 'my legacy' CSS. You also can see the problem with the CSS that InDesign itself creates and in the way the HTML files are composed. It's just not good enough, unclear, and not finished yet. It is also not documented in any way.
For exporting to epub2 it is an even more disaster. It places tags that don't belong there and leads to serious errors. So, you then have to restore everything in the html files. 

[noras12574007]

I can confirm that I get the problem of {list-style-type:none;} only being added to the first footnote without adding any CSS of my own. I did try making a fresh document where I inserted placeholder text and footnotes from within ID, and that produced the correct result with {list-style-type:none;} being applied to all footnotes.

Endnotes now default to being pop-up for some reason, even though they also appear at the end of the EPUB.

[ferformaat]

You are right! Thanks.

With a new fresh document, the export for footnotes is different and better. Very confusing. I don't know yet what the reason is for this strange behavior. But it has to do, in my case, with the settings of a footnote in InDesign: the paragraphstyle in the panel 'Options Footnote'. Some styles gives the wrong ol-li export, some styles the good one....

[James Gifford—NitroPress]

That's what I meant by an "A-B-C" analysis... this fault needs to be mapped against all the alternative numbering, positioning etc. settings at both the Footnote/Endnote setup level and the export level. Even in my limited experimentation, there are variations and I can't really make sense of what was/what is/what's being reported by others.

That the results invariably pass validation and accessibility checks is really neither here nor there — the feature/s are not really working right for EPUB export any more.

[James Gifford—NitroPress]

If your takeaway is that I'm in any way dismissing this issue, I think you're misreading my posts here.

And if your projects are anything like mine, extensive CSS tweaks could and would cause further unpredictable behavior on top of underlying export code changes.

[James Gifford—NitroPress · Accepted solution]

Testing Summary 3 Mar 2024 — ID v19.4, Win11

Okay, I've run several tests on footnotes and endnotes under v19.4, and the short version is that while the internal structure has been changed (from <p> elements to <ol>/<li> elements)... it all works exactly as it should under all conditions I can check—

• I can set any footnote/endnote numbering options, and they pass through to the exported EPUB. This includes numbering type, starting number, location etc.
• I see no duplicate numbering in either note list.
• EPUBcheck passes the result without a single warning.
• Ace passes the result with no relevant warnings (a few correctable ones related to the TOC).

Since this new system all turns on an ordered (numbered) list that then has the numbering suppressed (an approach which I cannot decide is a hack, a straightforward use of cascading style control or a brilliant workaround), and it was noted that adding the number-suppression statement fixed things for at least one user, I have to conclude—

• There may be some faulty versions of 19.4 that did not include the number-suppression statement; the solution is to look at the exported CSS file for that _idFootAndEndNoteOLAttrs { list-style: none; } statement.
• If that statement is present, check that it is applied to the <ol> list structures for footnotes and endnotes;
• If the duplicate numbers are being seen in any one EPUB reader, check the file in a standard/vanilla one such as Calibre, Thorium or Kindle Previewer.

Other than that, any fault may be in original source material and setup. The file I tested was created for other purposes before v19.4, but when I made some of the testing changes I had a sense that something global might have changed. If the source files in question are long-existing, it may be worth resetting or re-formatting both foot and end notes to force some internal structural update that results in a more compliant export.

So, TL;DR... there does not seem to be a problem here. If anyone is still seeing faults in the footnote/endnote export process, or in their accessability, feel free to continue the discussion but with as many details of the versions, doc, faults, validation and accessibility checks, readers used, etc. It won't help to just say "I'm still seeing the problem." 🙂

[PETER DE GREEF · Accepted solution]

quick fix would be to add this to your generated css file:

li._idFootnote {
list-style-type:none;
}