Open GeoffCapper opened 7 months ago
Could work, I think (from memory) that it was calculated on text length was for forms that shouldn't have HTML elements in them.
Wouldn't Summernote content always have HTML in it?
Not always.
Given that, I'll add a setting "limitType", with text & html options, defaulting to text to preserve the existing behaviour. Calculations and limit behaviour will depend on that setting. Does that sound suitable?
Do you prefer changes like this as a new branch?
Pushing to the main is ok.
Is it important that the skunkworks version be updated to mirror the primary file? I see there are a few other differences between them and I'm not familiar enough with the whole system to know what should be what. I can shoehorn the new code into it, but can't reliably test it out.
There's mainly a couple interface differences, such as the status bar being named differently. If you don't wish to update the skunkworks version that's ok, I can do that when I get a chance. You can if you wish try the Summernote Skunkworks version out, the build process is exactly the same, only it is based on the lite version only, and has a few features not in the main repository. Like smaller footprint for the dialogs, along with the ability to add animations for opening/closing, closing on clicking the background or pressing Esc. It also contains a Zoom feature for the editor content. There's a few other smaller things, that escape me atm.
All of the limit management functionality is using the text without HTML, yet any form submission is going to include that HTML and therefore exceed back-end max length limits.
I propose changing these functions to use HTML-inclusive length for calculations.
It would be possible to introduce a setting to allow switching between the two, but I can't see a use-case for the text version, so wonder whether it's worth doing that.