Discussion: v0.9.0 and further developments

This is a discussion about the future release v0.9.0.

About the legacy

Summernote began its journey in 2013 — it was the time Bootstrap 2 was getting popular and jQuery widely used, so Summernote was built on them. The first commit message was simple but grand, ‘summer is coming’ by @hackerwins.

As a WYSIWYG web editor, Summernote got popular. And most of its popularity came from its ease-of-use on Bootstrap-themed sites.

It was fine for a while. But Bootstrap released its version 3 and we’d decided to drop Bootstrap 2 and replace it with Bootstrap 3. At that time, it was not a bad choice. The difference between version 2 and 3 was not that huge and did not need to be changed many parts in most cases, almost drop-in replacement.

At the same time, we’d got a lot of requests about using Summernote without Bootstrap. So @hackerwins made a lightweight version, and we named it lite. We got two versions.

And Bootstrap 4 had released two years later. It was pretty different from its ancestor. So we couldn’t apply the same strategy. Not everyone wanted to upgrade their Bootstrap styles to version 4. Therefore, we decided to support both Bootstrap versions together. Three versions.

Meanwhile

Since 2018, most maintainers and committers have been away. Only @DiemenDesign and @easylogic have been struggling with fixing bugs and answering issues over and over again. @hackerwins is now busy with a new opensource project (Yorkie), and I (@lqez) quitted and retired from my job – losing confidence and motivation to maintain the project as diligent as years ago.

Meanwhile,

• JavaScript world is covered by new libraries – React, Vue, and so on, not jQuery.
• Component-based web design system is the new standard.
• Bootstrap 5 was released, but they are losing users.

Yes, Summernote lost many chances stepping forward.

Now

I’m preparing v0.8.19, which includes minor bug fixes and updates for broken and outdated build/test chains.

• https://github.com/summernote/summernote/pull/4151
• https://github.com/summernote/summernote/pull/4155

And it’s a good time to say goodbye to Bootstrap 3. At least we should not use version 3 as default. I thought to set Lite style as default and replace the default summernote.js and summernote.css with it. But I would like to hear other opinions.

Future

From the very beginning till 2017, I’d considered strength points of Summernote to be;

• Built-in styles (Bootstrap)
• Ease-of-use for jQuery users (friendly syntax)

But to continue the journey of development, below things should be addressed first;

• Independence from Bootstraps (no removal, but Lite as default)
  • Taking Lite as the default style, adding more styles – like Bootstrap 5, Tailwind, Tachyon, etc.
• Embedding jQuery (or remove it)
  • To use Summernote in nowadays frontend JavaScript libraries, we need to provide jQuery as a global object. (e.g. webpack.ProvidePlugin) I think this is not intuitive. It doesn’t need jQuery as much as years ago. We can use modern JavaScript syntax itself and Babel with polyfills. But there is a problem – most plugins depend on jQuery’s $.extend function.
• Renovation of plugin system
  • awesome-summernote holds plugins by categories, but we don’t know anything about the qualities and compatibilities of plugins, or even they works or not. We’re not that big as React, so Pelican plugin style could be an alternative way to manage plugins.

[DiemenDesign]

Here are some of my thoughts of some things I think are important, or where I would like to see the development path taken:

• drop Bootstrap, while allowing Summernote to be compatible. By this I mean that Summernote should be able to work with whatever framework the user decides to use in their project. Summernote should be agnostic. I’ve pretty much done this with the Skunkworks version, but I don’t think the Lite version in the main repository is completely free of issues when used with Bootstrap.
• drop jQuery, there are other WYSIWYG editors that don’t use it, so I don’t think it’s necessary, but testing should be done so the Summernote API works with other Javascript Frameworks, which will allow Summernote to be used in more projects. From my understanding, it’s jQuery’s each() function that is one of the biggest hurdles.
• Renovate the Plugin System, as mentioned by @lqez. Some things like the plugins I’ve made, can be embedded into the API, such as the image-attributes, or video-attributes, and possibly some others.
• Easier themes, As I’ve done in the Skunkworks repo, I’ve used a more modern approach to the styling by using the var css option, which should make themes much easier, as only the settings in the :root element need changing. This way, we could also drop SASS/LESS, which will also make the build process simpler for that area.
• Remove the dependency of using the document.execCommand(), primarily as it’s usage is now considered deprecated, and we already have (sort of) in place the range functions that we should expand on. There are quite a few bugs that I have added in the Projects area, which I think could be resolved by removing the execCommand() dependency as I believe most of those issues are due to Browser incompatibility, and trying to resolve in code those issues per Browser.
• In the case of @1der1 , we should allow the ability to use other fonts, or icons easily. This would allow, at least in Lothar’s case, to use the latest Summernote, which will help with security issues, and even though he seems to manage things quite well, it will lessen the maintenance and issues on us for people using older versions due to reasons they can’t upgrade.
• Dialogs that open after Summernote initialises. Dialog’s should not be pre-rendered, but rather added to the DOM when called for. This will achieve a few things.
  • A smaller DOM footprint when intitialised, and case in point, I have some instances of Summernote in my CMS that don’t use dialog’s, but are still present in the DOM, making the page much larger than it needs to be.
  • Should (hopefully) remove the issue where Dialog’s open beneath other elements, as we can append Dialog’s at the bottom of the DOM.
  • When a Dialog is opened, an ID can be programmatically assigned to that Dialog to be matched with the instance of the Summernote editor that called for the Dialog to be opened.
  • Explore whether we can use the <dialog/> element, we would need to see what the Browser supporting ecosystem is at. Chrome supports it, but others like Firefox don’t (not without enabling it in options). Not sure about other browsers, but it would mean using a polyfill, and relying user’s also adding that to their markup, though we could programatically check if it’s present and add it if it isn’t. But as usage varies between browsers, we may better sticking with what we already have.

Here’s some things that are different in the Skunkworks repository, some are new features, some are fixes:

• Dialogs, can now be closed using Esc, or clicking on the background. And now uses a smaller element footprint, as not as many elements are needed for Dialog’s.
• The image Dialog now contains options to have a “Browse Files” button appear next to the URL input, along with the ability to use a third party option such as elFinder.
• @IgnacioHR has added a PR which was merged that adds a page zoom capability, and toolbar buttons with plus/minus and an input that displays the percentage of page zoom.
• The CodeView is now resizable.
• On the Links Dialog, there is now an option to allow a dropdown list which can contain links that are populated via options. I use this to allow my client’s to create internal links on their sites that go to other pages, or content. This Dialog also now contains a rel attribute option.
• Tooltips are now completely CSS controlled, so there is now no need for code to make Tooltips appear. They now also use the aria-label attribute, rather than the title, making them easier to disable, and their position now has an option to control how they appear (top|right|bottom|left). I would like to see if we can have these auto-adjust so they adjust their position to not appear offscreen.
• Allow Dropdown’s to appear as Dropup via options.

There’s been other fixes added from issues from the main repo, which I’ve marked as skunked to indicate those have been added.

Those are just some of my thoughts, off the top of my head, obviously they can be expanded on, or forgotten about.

[lqez]

Please leave a comment to help us! ❤️ We would like to know about the reason why you use Summernote and what was the pain point while using it.