Intended behaviour of data-visibility="uncounted" with progress and slide numbers

[s-l-lee]

Dear @hakimel ,

In the 4.0.0 release notes, one of the changes is:

• Adds support for data-visibility="uncounted" to exclude slides from the progress bar and slide number count. Allow slides to be uncounted #2543 by lassepe

I just wanted to seek some clarification regarding the intended behaviour of this new feature and its interactions with the progress bar and slide number count. Sorry for the walls of text, please respond at your leisure (or not at all).

Thank you for your time and attention,
Sheng

Uncounted slides at the end of the presentation

Reading the original PR, it seems that the intended application of this attribute is to exclude backup/appendix slides at the end of the presentation from the denominator/divisor of the progress calculation. The change to getSlides() seems to be sufficient for this. It also has the effect of changing the total slides (the t in the slide number) when slideNumber is set to 'c/t' in the configuration.

However, there are also changes to getSlidePastCount() to exclude vertical and horizontal uncounted slides from the numerator/dividend of the progress calculation. It also has the effect of changing the current slide (the c in the slide number) when slideNumber is set to 'c' or 'c/t' in the configuration. If uncounted slides appear only at presentation end, these changes seem unnecessary for the progress calculation as current slides beyond the total slides (c>t) are ignored.

Currently, when slideNumber is set to 'c' or 'c/t' in the configuration, the current slide (the c in the slide number) does not increment for uncounted vertical slides but does increment for uncounted horizontal slides. The expression !horizontalSlide.dataset.visibility !== 'uncounted' always evaluates to true (strict comparison of boolean left operand and string right operand) in the change to getSlidePastCount() horizontal slide counting.

I am guessing this is a bug, but I wanted clarification before submitting a PR as continuing to increment current slide numbers in the appendix could be an intended behaviour.

Uncounted slides at start or middle of the presentation

The changes to getSlidePastCount() suggest to me that uncounted slides are not only allowed at the end of the presentation but also at the start or the middle as well. If that is the case, then !horizontalSlide.dataset.visibility !== 'uncounted' discussed above is clearly a bug as it can cause the progress bar to fill way before the presentation end as the total slides does exclude uncounted but the current slide does not exclude uncounted horizontal slides.

If uncounted slides can appear in the middle of the presentation, another bug can occur in getProgress() if the last counted (without the uncounted attribute) slide in the presentation with a series of uncounted slides immediately before it. The progress bar will complete as soon as it reaches the first in the series of uncounted slides before the last slide. This is because getProgress() checks that it has passed the penultimate counted slide (the counted slide before the last counted slide).

These may or may not be bugs depending if uncounted slides are allowed anywhere except the end of the presentation. Personally, I am using uncounted on title pages at the start and at some points in the middle of the presentation in addition to the originally intended backup/appendix pages at the end of the presentation. I have also modified the slide numbers to be hidden on uncounted pages as the repeated slide numbers become quite redundant.

Tangent: Progress on the last slide of the presentation

While experimenting with getProgress() to address the possible issues above, I noticed that it does not account for fragments if there are fragments on the last slide in the presentation. Instead, the progress bar will complete as soon as it reaches the last slide in the presentation. Again, this is because getProgress() only checks that it has passed the penultimate slide. Not sure if this is intended behaviour or not, I personally would expect the progress bar to complete on the last fragment of the last slide (if there are fragments on the last slide).

[hakimel]

Thanks for the detailed report! The issue was that the slide numbering naively assumed that it should increment the current slide number by 1 to account for the current slide. It didn't consider that the current slide may be uncounted. This meant that the first uncounted horizontal slide ended up increasing the count by one, even if subsequent uncounted slides were not counted. This issue has been fixed as well as the faulty condition you reported.

Fragments should be visible in the toolbar on the last slide. Will make a note to add that for a future enhancement.