Discussion: v0.9.0 and further developments

[lqez]

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.

• [WIP] Preparing 0.8.19 #4151
• [WIP] Clean up files #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.

[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.

[1der1]

Thank you lqez and the team for an awesome HTML editor. I used other editors before but after a lot of research, I choose SummerNote for 1der1. 1der1 is a website builder and it uses SummerNote as a nucleus for many extensions.

The website builder uses a lot of interfaces to other software, and it is painful when an interface changes later on. When I started using SummerNote, it came with Font Awesome. When the SummerNote team invested huge efforts to get rid of Font Awesome, I kept the latest version and continued developing it.

While I am no longer using the newer versions, I keep connected and I am happy to help solve issues, I already solved for the 1der1 version,

[DennisSuitters]

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.

[DennisSuitters]

I've noticed some weird issue that happens in all of the versions of Summernote I could test today, BS3, BS4, BS5, Lite, and Skunkworks, where some of the formatting during normal editing gets elements added, in strange ways. For e.g.

<p>This is some test text</p>

If i then add a line break by pressing enter after the is, I get in code the following:

<p>This is</p><p><br></p><p> some test text</p>

This is wrong, and shouldn't happen, it should, theoretically do:

<p>This is</p><p> some test text</p>

//or

<p>This is<br> some test text</p>

If think this is something that needs addressing as well.

[lqez]

@diemendesign

If think this is something that needs addressing as well.

I tested this today (develop branch) but failed to reproduce.
(macOS, Chrome 95) What was your env?

[DennisSuitters]

Linux, Chrome. Using both the Skunkworks version (based on Lite), and BS4, and Lite versions built on my machine for testing the latest changes.

[DennisSuitters]

I just now had a thought on the dialog/modal problem with too many modals loaded into the DOM producing large pages for those that use multiple instances of Summernote on one page.

What if we used the <dialog> feature that modern Browsers now support, with a fallback for Browsers that don't support the native functions?

I'm thinking we could have one dialog/modal instance that gets populated when the need to use one is needed. It may mean moving the code embedded markup into the functions for each dialog where they are initiated, but I'm also thinking that may help with maintaining the code easier as everything for that function will be together, rather than spread across multiple files. I think this may also resolve what dialog/modal belongs to what instance of Summernote as well, as we can more closely tie them together with each Summernote instance having it's own dialog/modal instance.

[1der1]

@diemendesign
I agree. I have removed all modal UI because it is an annoyance, IMHO. I have chosen one instance for every dialog, so when you open the dialog for another instance of Summernote, an existing instance of the dialog gets closed. If you destroy an instance of Summernote, every dialog opened by it (and referring to it) gets closed.

[DennisSuitters]

Yes, that could be another way, and would make cleaner markup, esp. for those that don't need to use them, making the footprint even smaller. There's no reason they couldn't be generated as needed. Maybe the same for the popovers as well.

[sjw-pc]

I think we should pay more attention to function rather than style. According to the use of users, they can modify the style freely to make it look more beautiful, because the style modification is simpler and will not affect the practicability of the editor.

I think we should pay attention to the optimization of functions, such as the execcommand() function mentioned in @diemendesign . This function has many uncontrollable factors, which will pollute the style of the editing area in some cases. If possible, I hope that the code of summernote can realize functions similar to execcommand().

I investigated TinyMCE about plug-ins. I think they did a good job. We can also refer to their ideas. We can provide more APIs (such as selection area, current cursor position, insertion line, button or toolbar status...) to allow users to combine freely to realize their customized functions, but this is a huge project.

[DennisSuitters]

Styling the current interface of Summernote isn't that easy, and has to be accomplished mostly by overriding styles in another stylesheet. What I've been working on, mostly with the Skunkworks version (based on the Lite version), is modifying how the styling works, so it uses the var options that is available now with stylesheets, that way, restyling only requires changing the vars values, rather than having the override existing styles, as mostly changing the look is about changing the colours.

[sjw-pc]

Thank you for your advice!
But I think the style should be modified by users themselves, so as to conform to the overall style of their HTML. At most, we just make it easier for users to change, because the style changes are very rich. We shouldn't fix it with some parameters. Users need to overwrite the original style of summernote through CSS files to achieve the desired effect. At least I have achieved the effect I want in this way.
This is part of the effect picture I modified

Because the styles are very rich, we can't predict the needs of users at all, so we should give users enough freedom. Maybe we can adjust the weight of styles to make it easier for users to cover them.
Why do I think so? I haven't encountered any problems in modifying the style, but there are some bugs in the function.

[DennisSuitters]

That's pretty much what I'm talking about, but making it easier, so extra styles don't need to be added, helping keep the overall footprint smaller, and making changing the look easier, even on the fly, as javascript can modify the variables that affect the styling directly. It also means we can provide multiple styles people can just, as they would only require changing the values to achieve different looks while keeping the functionality of Summernote consistent.

[DennisSuitters]

Oh, and it also means anyone wanting to create their own look, don't have to sift through all the styles to make the changes they need.

[netsevdam]

I've noticed some weird issue that happens in all of the versions of Summernote I could test today, BS3, BS4, BS5, Lite, and Skunkworks, where some of the formatting during normal editing gets elements added, in strange ways. For e.g.

<p>This is some test text</p>

If i then add a line break by pressing enter after the is, I get in code the following:

<p>This is</p><p><br></p><p> some test text</p>

This is wrong, and shouldn't happen, it should, theoretically do:

<p>This is</p><p> some test text</p>

//or

<p>This is<br> some test text</p>

If think this is something that needs addressing as well.

Same issue hapening for almost all tags #4303 (comment)

[mu-hun]

Variably set font-size, line-height, letter-spacing... value by number input text in the toolbar UI.

I want to set these style variably by number input text in the toolbar UI. (Rather than a list of fixed font sizes.) 🥺

ref issue: #4319

[VangelisP]

First of all, I would like to thank everyone for this amazing work that you guys did so far. Wonderful product!
While I admit that I am relatively new to using summernote, here are my points:

What I love:

• Very lightweight ! It can even run via CDN!
• Extremely easy to use
• Does what the packaging says, true WYSIWYG (I had a huge frustration on using CkEditor5 with emailing templates).
• Quick configuration of toolbars and options (no hidden stuff)

My 2 cents on this discussion:

• Go from min to max: Ditch bootstrap3/4/5 and keep the lite as the main (core) version (I use the lite version even on a bootstrap theme). On the same note, add the possibility for someone to be able to write a plugin for Bootstrap4/5/6/x to make the package compliant with it. In plain words: separate the styles from the core. That would give you a focus on the core and allow other contributors to add their own style (be it Bootstrap, be it something else)
• Jquery and extension ecosystem: Obviously, you'll need to draw a line here and say for example that Summernote 1.x will be incompatible with the existing plugins. Plugin authors should be having at least 2 branches (I am not implying to maintain both branches), one that worked with the JQuery $.extend and to be considered obsolete outdated and the current branch, the one compliant with Summernote 1.x. I do understand that this is huge work for the contributors but it's the only way if you guys want to evolve this editor into something bigger.
• Renovation of plugin system: Well, on that part I am not an expert. What i could propose is some sort of flagging/categorizing. Eg plugins should be categorised into some very basic categories like 'untested', 'outdated' (in the case that there was no upgrade being done and the plugin fails to render), 'beta', 'stable', or a combination of all those. As for the management repository, I cannot suggest anything at the moment.

I hope the above helps a bit on your discussion on how to move forward.

Cheers

[DennisSuitters]

Thanks for your thoughts @VangelisP you bring up some interesting points, a lot that I agree with.

I've been working on the summernote-skunkworks repository, which is based on the lite version. I have recently set the repository to public, but as of yet, no releases of that version, it currently needs to be built to be used. I have so far completely removed the dependence on Bootstrap, which was mostly styling, and added mostly colour control variables to make themes easier to produce. There are also some sizing variables added, mostly to do with padding and margins for some elements. There has also been extensive remodelling of the modals, which can now be closed via Esc, or by clicking on the background. Plus a lot of other improvements and fixes were added, for testing and fixing issues brought up in the main repository. The styling has also been namespaced better, along with making sure things like "active", "dropdown" which use similar classes to Bootstrap have been namespaced and the relevant code modified to work, further removing interference from other frameworks.

jQuery, as you mentioned there are some functions that are exclusive to jQuery that Summernote currently relies on, making it hard to simply remove the dependence on jQuery easily. I do, however, want to start modifying code that will for now be easily removed and can be done in Vanilla Javascript.

We do have a repository for the plugins "awesome-summernote". Thinking about it, maybe a new repository could be called summernote-plugins would make more sense, and maybe also summernote-themes might also be an idea. And within those, we have a tagging system that indicates exactly which version of summernote the plugin or theme works with. We could also have on repo for both, but I'm not sure what we could call that.

At this stage, I think we can drop Bootstrap, from my testing, the skunkworks version works fine inside it, without interference (though someone may find something to fix, but that is to be expected), it also works inside tailwind. I have yet to test other frameworks, but it wouldn't be hard to fix those.

[hldvuong]

I'm frustrated that summernote doesn't add Font-family like ej2 syncfusion richtexteditor :

       var rteditor = $('#rteditor').summernote({
            fontNames: [
                'Source Sans Pro',
                'Segoe UI',
                'Arial',
                'Arial Black',
                'Courier New',
                'Georgia',
                'Impact',
                'Lucida Console',
                'Tahoma',
                'Times New Roman',
                'Trebuchet MS',
                'Verdana'
            ],
            height: 400,
        });

        //////////////////   ej2 syncfusion richtexteditor   //////////////////////////////
        var richTextEditor = new ej.richtexteditor.RichTextEditor({
            fontFamily: {
                default: "Source Sans Pro",
                width: "80px",
                items: [
                    { text: "Source Sans Pro", value: "Source Sans Pro" },
                    { text: "Segoe UI", value: "Segoe UI" },
                    { text: "Arial", value: "Arial,Helvetica,sans-serif" },
                    { text: "Courier New", value: "Courier New,Courier,monospace" },
                    { text: "Georgia", value: "Georgia,serif" },
                    { text: "Impact", value: "Impact,Charcoal,sans-serif" },
                    { text: "Lucida Console", value: "Lucida Console,Monaco,monospace" },
                    { text: "Tahoma", value: "Tahoma,Geneva,sans-serif" },
                    { text: "Times New Roman", value: "Times New Roman,Times,serif" },
                    { text: "Trebuchet MS", value: "Trebuchet MS,Helvetica,sans-serif" },
                    { text: "Verdana", value: "Verdana,Geneva,sans-serif" }
                ]
            },
            height: 400,
        });
        richTextEditor.appendTo('#rteditor');

Please add this feature to summernote.

[DennisSuitters]

@hldvuong Do you mean like this: https://summernote.org/deep-dive/#custom-fontnames

[hldvuong]

@hldvuong Do you mean like this: https://summernote.org/deep-dive/#custom-fontnames

Yes, it does not same ej2 syncfusion richtexteditor feature.

[DennisSuitters]

But it does it in a different manner, yes?

[Ninja-man07]

I can't get it to save any of my changes, like adding a video or image. When I navigate to another section of the course it looses all the changes I made for my edit. How can I keep the changes I edit? How do I save my progress?

[DennisSuitters]

@Ninja-man07 could you create an issue for this, your comment doesn't really have anything to do with the Topic, thanks.

[MohamedKarrab]

Drop jquery please, it's about time.

[DennisSuitters]

PR's are welcome to convert code away from jQuery.

[1der1]

It sounds reasonable to get away from jQuery. I have already seen a lot of talking about it for years.

However, the modern JavaScript replacements are not so forgiving, and you write wrapping code that does all the checking. Your wrapping code is not a standard like jQuery.

Additionally, browser-emulating components like bots and scrapers often don't support some new JavaScript features and will fail.

Does anyone know a major project that stripped jQuery usage?

Keeping jQuery would reduce the to-do list significantly, freeing up many resources.

[DennisSuitters]

@1der1 agreed, hence why we haven't just jumped straight in. Plus there are some functions that rely on jQuery. That said, however, there's no reason we can't slowly migrate code to vanilla Javascript that allows. Oftentimes, it speeds up code execution as well, as we're not relying on third-party code that the browser can do natively. For me, despite the increase in speed of execution, it would help put Summernote into more projects that don't use jQuery. Also, as I've noticed with some other projects (Fancybox, Fullcalendar) that have moved away from jQuery, they have options that allow initialising their functionality using jQuery.

[nasirkhan]

will there be any future releases?
It shows a number of recent commits/merges in the repo but the release version has not been updated since October 2021.

[DennisSuitters]

There is intention for it, it's just getting it done. The number of commits, recent or otherwise, isn't an indicator that a release should or will happen.

[nasirkhan]

There is intention for it, it's just getting it done. The number of commits, recent or otherwise, isn't an indicator that a release should or will happen.

Thanks for your reply.

[andrii-kasparevych]

@DennisSuitters @lqez do you guys need any support in making the new release happen?

There's a few fixes already in the develop branch, which people (myself included) look forward to have, but a new package version is required. I think the project is just awesome, and it would be so nice to see a couple of updates there!