Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pell – A simple and small rich-text editor for the web

github.com

Post reply on HN
Print view View original

41–50 of 106 posts

Re: Pell – A simple and small rich-text editor for the web

#41

Post by Tade0 »

jchw wrote: post #37
Tade0 wrote: post #24

Earlier quoted context omitted.

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.

I doubt this? contenteditable is pretty stable in Chrome/WebKit.

I don't know - you tell me.

Anyway we had our share of trouble with a customer due to an exotic rendering issue that occurred in two consecutive versions of Chrome and then disappeared, so yeah.

Re: Pell – A simple and small rich-text editor for the web

#42

Post by _wmd »

simias wrote: post #29
_wmd wrote: post #26

Earlier quoted context omitted.

98% of the difficulty in implementing a rich text editor is already present in every browser, its hard to call it wheel reinvention at that point. Drawing a caret and responding to key presses by mutating the dom is about the only thing left

IMO actually displaying text is not the big challenge in a text editor. The tricky part is the user interface, text transformation (sed, query-and-replace, pipe through external programs...), text parsing (for syntax highlighting and code folding for instance) and invoking external applications, for instance to compile code or post-process your document. Web browsers are not particularly good at any of these things s…

Accurately rendering text in an WYSIWYG HTML editor has equivalent difficulty to implementing the engine used in the web browser that will eventually be used to render that HTML, otherwise it can never truly be WYSIWYG

Re: Pell – A simple and small rich-text editor for the web

#44

Post by veli_joza »

marijn wrote: post #40

Nonsense, I've written a much smaller one: `function tinyEditor(element) { element.contentEditable = true }` 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 d…

Even as beginner in web tech, I was convinced of the same after glancing at the code. There's probably more project packaging description LoC than logic code, so SNR is quite low.

Re: Pell – A simple and small rich-text editor for the web

#45

Post by roryisok »

lmm wrote: post #38
roryisok wrote: post #20

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.

Which means you end up shipping a huge chunk of "bloat" to your end users - it may be a library or "runtime" rather than your own code, but it adds up to the same thing.

so in that case isn't it a good idea to try and reduce your overheads wherever possible? And in the case of windows store apps, the runtime is already on the users systems and they're just downloading the packaged JS/HTML

Re: Pell – A simple and small rich-text editor for the web

#47

Post by simias »

_wmd wrote: post #42
simias wrote: post #29

Earlier quoted context omitted.

IMO actually displaying text is not the big challenge in a text editor. The tricky part is the user interface, text transformation (sed, query-and-replace, pipe through external programs...), text parsing (for syntax highlighting and code folding for instance) and invoking external applications, for instance to compile code or post-process your document. Web browsers are not particularly good at any of these things s…

Accurately rendering text in an WYSIWYG HTML editor has equivalent difficulty to implementing the engine used in the web browser that will eventually be used to render that HTML, otherwise it can never truly be WYSIWYG

That's fair, I'm obviously biased by my general loathing of WYSIWYG editors but clearly I'm in the minority here. I guess when I think about text editors I think mainly of code editors.

Re: Pell – A simple and small rich-text editor for the web

#48

Post by anilgulecha »

marijn wrote: post #40

Nonsense, I've written a much smaller one: `function tinyEditor(element) { element.contentEditable = true }` 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 d…

Thanks for prosemirror, marijn! Big fan :)

Re: Pell – A simple and small rich-text editor for the web

#50

Post by roryisok »

jwr wrote: post #30

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…

Depends on your use-case I suppose. That's why most of these editors are customisable. When writing posts on SO, I've used bold, italic, and strike-through in the same post.

In every day usage, bold/underline/strike may be superfluous, but I would argue that italics are essential. Without at least the ability to emphasise a word in some way, your only option is uppercase.

Post reply on HN