31–40 of 106 posts
Try quoting the last paragraph in the editor. It's now impossible to ever escape from the quote. All new text at the bottom stays "quoted".
From a cursory test of the editor, it suffers from basically all the issues that contenteditable suffers from.
The reason other editors are so big is because the take editing behaviour into account.
!function(e,t){"object"==typeof exports&&"undefined"!=typeof module?t(exports):"function"==typeof define&&define.amd?define(["exports"],t):t(e.pell={})}(this,function(e){"use strict";var t,n=Object,i=document,o=prompt,r="pell-",a="button",u="className",l="appendChild",d="createElement",c="insert",s="rderedList",f="Horizontal",p="formatBlock",m="Enter the ",b=n.assign||function(e,i,o,r){for(i=arguments,t=1;tB","Bold",h("bold")),italic:g("I","Italic",h("italic")),underline:g("U","Underline",h("underline")),strikethrough:g("S","Strike-through",h("strikeThrough")),heading1:g("H1","Heading 1",h(p,"")),heading2:g("H2","Heading 2",h(p,"")),paragraph:g("¶","Paragraph",h(p,"")),quote:g("“ ”","Quote",h(p,"
")),olist:g("#","Ordered List",h(c+"O"+s)),ulist:g("•","Unordered List",h(c+"Uno"+s)),code:g("</>","Code",h(p,"")),line:g("―",f+" Line",h(c+f+"Rule","")),link:g("","Link",function(){(t=o(m+"link URL"))&&h("createLink",k(t))}),image:g("","Image",function(){(t=o(m+"image URL"))&&h(c+"Image",k(t))}),undo:g("↺","Undo",h("undo")),redo:g("↻","Redo",h("redo"))};e["default"]={init:e.init=function(e){var o=e.classes,c=e.actions,s=i.getElementById(e.root),f=i[d]("div"),p=i[d]("div");p.contentEditable=!0,f[u]=o.actionbar||r+"actionbar",p[u]=o.editor||r+"editor",p.oninput=function(t){return e.onChange&&e.onChange(t.target.innerHTML)},s[l](f),s[l](p),(c?c.map(function(e){return"string"==typeof e?L[e]:b({},L[e.name],e)}):n.keys(L).map(function(e){return L[e]})).forEach(function(e){t=i[d](a),t[u]=o.button||r+a,t.innerHTML=e.icon,t.title=e.title,t.onclick=e.result,f[l](t)})}},n.defineProperty(e,"__esModule",{value:!0})})
Of course, if you decide to abandon AMD/CommonJS support, you can quickly whip 210 bytes (100 gzipped) off, but that’s a change in semantics so I can’t count that despite it getting it under 1000 bytes.
Every time I see a new WYSIWYG text editor, I wonder: do people really need to set single words in bold, italic, underline, and strike-through? I feel like this is a leftover of the old times, back when first WYSIWYG editors appeared and these capabilities were impressive. I think these days what one needs is not bold/italic, but facilities for editing structure, inserting links, and positioning images, all according…
Earlier quoted context omitted.
sometimes, you can be sure of the browser / rendering engine ahead of time, and you don't need all that "bloat". For instance, react-native, electron or windows store apps.
In these cases you'd have to freeze the version of every layer beneath the editor(browser/env, OS and so on), otherwise any regression in these layers is going to break your app. But if you decide to freeze you run the risk of exposing your users to security issues.
You only need to check periodically whether new updates are ok. Same way you don't freeze all your non-editor dependencies for eternity.
And I doubt you need to care for layers below the browser ("OS and so on") changing when it comes to your WYSYWIG component in your Electron app.
Just for the fun of it, I dove in and manually minified the code further, without changing any semantics at all. With the following, I got it down from 2878 bytes to 2010 bytes which is a 30% saving: !function(e,t){"object"==typeof exports&&"undefined"!=typeof module?t(exports):"function"==typeof define&&define.amd?define(["exports"],t):t(e.pell={})}(this,function(e){"use strict";var t,n=Object,i=document,o=prompt,r=…
BIUS')">H1')">H2')">¶')">“ ”#•')"></>')">―↺↻Earlier quoted context omitted.
sometimes, you can be sure of the browser / rendering engine ahead of time, and you don't need all that "bloat". For instance, react-native, electron or windows store apps.
In these cases you'd have to freeze the version of every layer beneath the editor(browser/env, OS and so on), otherwise any regression in these layers is going to break your app. But if you decide to freeze you run the risk of exposing your users to security issues.
As a person who used to work for a company developing one of the more popular in-browser text editors I can tell you that all that "bloat" is there so that you'll get consistent results across browsers. Unfortunately there's no way around this short of not using contenteditable - which is even worse sometimes. Most editors feature customized builds which let you reduce the footprint of the editor. If you're looking f…
sometimes, you can be sure of the browser / rendering engine ahead of time, and you don't need all that "bloat". For instance, react-native, electron or windows store apps.
Every time I see a new WYSIWYG text editor, I wonder: do people really need to set single words in bold, italic, underline, and strike-through? I feel like this is a leftover of the old times, back when first WYSIWYG editors appeared and these capabilities were impressive. I think these days what one needs is not bold/italic, but facilities for editing structure, inserting links, and positioning images, all according…
Those of us who do care about semantic structure can often do without WYSISYG editors anyway, since we have much cooler alternatives such as Markdown and LaTeX.
That, plus a few crude buttons, is all this does. As several other comments point out, there's good reasons why real WYSIWYG packages are bigger—the user experience of working with a plain contentEditable element is still terrible, the output HTML still a complete mess. If you don't care much about that, you don't need an editor component, since setting an attribute and wiring up some buttons to call `execCommand` is easy enough to do from scratch.
Disclaimer: I work on one of those 'bloated' editors, http://prosemirror.net , and find it a little annoying when someone implies their crude afternoon hack is somehow equivalent and we're crazy for putting in all that effort.