Open janishutz opened 10 months ago
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
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)?
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
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.
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
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.
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
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.
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.
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.
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! 🥇 )
@jorisvanzundert Do you think it is a problem, as TS compiled to JS with barely any changes?
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.
What I like to see is:
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).
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).
Thanks, I'm aware of this, but this example is still linear, as in there is only one implied direction...
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.)
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.
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
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
Other considerations
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.