Major Refactor

[janishutz]

V3.0

Since I will again have much more time to spend on other projects in the near future, I wanted to do something I had wanted to do for a long time, which is making impress.js much more flexible. Since this requires some major rewrites, I am strongly in favour of making this a breaking change, meaning that some APIs will go away / be replaced by new ones as well as some additional ones coming to impress.

New features

• For example, to enable more flexibility in transitions, I would like to expose a movement API such that all the positioning / transitioning (I haven't thought about how exactly to do it just yet) will be handled in plugins to allow for more versatile transitions like zoom-in zoom-out or zoom-out zoom-in between the movement.
• Work to reduce the amount of open issues by trying to address all suggestions and bugs in them
• Migrate to eslint from jshint
• Update all plugins to the new api
• Update all the unit tests to work with the new APIs
• Update the demo
• Update the examples
• Update website to allow for switching between impress.js versions for docs
• Optimize docs building script by enforcing certain md restrictions like only allowing for absolute links to other docs
• Add option to customize mouse-navigation (click to go to next step or click onto a step to go to that one (like a simple toggle))
• Clean up plugins (merge similar ones)
• ensure that keylisteners are in the main impress function (or one of them) and it calls functions in plugins if they request a certain key.

Other considerations

• I would argue that still supporting the V2.0 series would be something that is required to do, but only for bug fixes.
• I will be adding a guide to migrate both plugins and presentations to the new version. Though, presentations will NOT be needed to update to still work, they should continue working in the same way as they do now with the new version, only that there will be more features available.

Final thoughts

If you have any suggestions or concerns, please let me know. I am planning to start on this in December 2023 or January 2024.
I am also planning to use this as an opportunity to drop support for IE and use more modern web APIs to make it more flexible and to speed things up.

[henrikingo]

Hi again...

That's a good list. Great to hear you'll have time in 2024.

For refactoring, see #742
Second, most current plugins don't have any tests. Adding test coverage would be hugely valuable.
From the pending PRs, finishing #781 would be very interesting. This could open the way for some kind of "edit mode", similar to what I was building in https://github.com/henrikingo/impressionist

[janishutz]

Yeah #781 is on my list. Essentially, I will refactor it to what you had mentioned in #748. This seems like a logical step. What do you think of adding the option to do mouse navigation in two modes (go to step clicked on or to next one)?

[janishutz]

I will also add unit tests for the plugins that don't have that yet as I will have to rewrite them for core anyway

[henrikingo]

What do you think of adding the option to do mouse navigation in two modes (go to step clicked on or to next one)?

Only now saw this... Isn't this how it already works? Note that you need to be mindful about pointer-events in the css.

[janishutz]

I don't think so, but I could be wrong. And I won't be using pointer-events in CSS to control this, but rather in JS with click event listeners on the steps and on a helper div depending on the mode

[henrikingo]

This is a good time to start educating you on some key impress design philosophies - stuff that bartaz patiently kept explaining me over a decade ago.

A design goal of impress.js is to leave such things, as much as possible, to the end user = author of presentations. And specifically, whenever possible, leave such things to be handled by HTML and CSS, but no JS. (While impress now supports plugins, writing any line of JavaScript would fall somewhere on the spectrum of hack/advanced usage/extending impress.js functionality. Typical author experience should only require HTML (or Markdown) and CSS.)

This means you MUST NOT* use JavaScript to implement anything that could be implemented in CSS and HTML, because in that case the JavaScript implemented by you will override the CSS supplied by the end user (e.g. pointer-events: x;)

A similar but differet rule is that when something is possible in CSS,then we should use that standard mechanism directly, because embracing standards is a good thing. Note also that impress never supports backward compatible functionality through JavaScript libraries. We support the standard functionality available when you upgrade to the newest browser version.

• = https://datatracker.ietf.org/doc/html/rfc2119

[janishutz]

That very reasonable. There are still some features that are not fully supported in Safari for example, so we won't use those (yet and I'll just add a note in the source that this would be an option in the future)

Additionally, I think we should, if necessary drop support for IE. Quite frankly, this browser is so far outdated, that it's just a pain to keep support for it alive, at the cost of features we could otherwise support. And impress.js V2 won't go anywhere, so if one would REALLY need IE, that'd still be an option.

Thanks btw for giving me this information

[henrikingo]

Your welcome and really I'm just passing it along :-) I'm sure there will be more over the next years.

Continuing from my previous message, I also don't think we are committed to supporting any particular browser, nor all of them. And there are no tests for IE and Safari. So if something works on Chrome and Firefox, and specifically if it is standardized already, there's no reason to hold back for the benefit of Safari or IE users. Let them upgrade to a browser that supports the latest and greatest, and let impress.js be a showcase for what can be done with standard HTML and CSS.

[janishutz]

What do you think about going the TypeScript route for impress? This would probably prevent a few bugs from happening. It will obviously just compile to JS, so it'd still be called impress.js for the end user.

[janishutz]

I also thought about giving the users a "impress.css" file, which includes the most common cusomizations added to a impress presentation, including notes, fallback message hiding, etc.

I am also currently testing a few ways to make customizable transitions using vanilla CSS (so no data- attributes), but I'll have to see if that will actually work out as I expect.

[jorisvanzundert]

Can I drop my two cents on the TypeScript suggestion? I would keep to plain vanilla JavaScript (even if it might make you miss some bugs with every release). The advantage of plain JavaScript is that you allow end users to tinker themselves, as many of them have some JavaScript but no TypeScript skills. Imho this would adhere more to Impress.js' original open and lightweight ideas. (Just saying. And allow me to add a big thank you for keeping Impress.js maintained! 🥇 )

[janishutz]

@jorisvanzundert Do you think it is a problem, as TS compiled to JS with barely any changes?

[henrikingo]

What do you think about going the TypeScript route for impress?

I personally don't know TypeScript, so maybe I lack the capability to appreciate its benefits. But I would say rewriting a codebase like impress.js in another language, would make it a different piece of software. It should have it's own repo, just to avoid confusion.

If you want to avoid future bugs, then the obvious low hanging fruit area to invest in is more unit tests. We have only a handful, and most plugins and features are completely untested.

[cmahnke]

What I like to see is:

• More natural touch interaction. Currently one is required to swipe left or right (on the demo page), swiping down should work as well.
• Related to this is better "scroll snapping" for touch, currently the seems to be the requirement to swipe a certain distance. Wenn not swiping the whole distance the animation starts but returns to the starting position if not completed. I like to have a setting like "Once animation started always finish".
• On the desktop scroll events should be supported
• A grid mode would be nice as well: Having the possibility to allow non linear slides like Reveal.js vertical slides. My idea would be to use it to implement something something like the Compiz Desk cube (dinosaurs might remember).

[henrikingo]

A grid mode would be nice as well: Having the possibility to allow non linear slides like Reveal.js vertical slides. My idea would be to use it to implement something something like the Compiz Desk cube (dinosaurs might remember).

https://impress.js.org/examples/cube/#/step-1

[cmahnke]

A grid mode would be nice as well: Having the possibility to allow non linear slides like Reveal.js vertical slides. My idea would be to use it to implement something something like the Compiz Desk cube (dinosaurs might remember).

https://impress.js.org/examples/cube/#/step-1

Thanks, I'm aware of this, but this example is still linear, as in there is only one implied direction...

[henrikingo]

You can use arrows (and of course links) to deviate from the linear flow.

(As illustrated more explicitly in https://impress.js.org/examples/2D-navigation/ which I'm sure you're also aware of.)

[cmahnke]

Thank's I did't know that, so it's just an UI issue. This should be reflected by other controls (scroll, swipe) as well.

[janishutz]

I will add this to consideration when developing the "flow" plugin. Essentially, what will change is that the flow of the presentation will be controlled by a plugin