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

21–30 of 106 posts

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

#21

Post by chuckdries »

anilgulecha wrote: post #4

This is cool :) That said (and not to take thunder away from your page), this is possible because the HTML spec itself allows for any element to be made into a "WYSIWYG" editor by adding the "contenteditable" attribute. What most other larger editors are doing is working around some of the horrendous non-standardized versions of execCommand which varies across browsers. Ideally a web standards body should come out wi…

Minor nitpick: Generally speaking you use execCommand and contentEditable together, otherwise you;re reimplementing execCommand with the selection API

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

#22

Post by simias »

anilgulecha wrote: post #4

This is cool :) That said (and not to take thunder away from your page), this is possible because the HTML spec itself allows for any element to be made into a "WYSIWYG" editor by adding the "contenteditable" attribute. What most other larger editors are doing is working around some of the horrendous non-standardized versions of execCommand which varies across browsers. Ideally a web standards body should come out wi…

Wouldn't it make more sense to just add a standard API to invoke an external editor instead of yet again reinventing the wheel? It might be more interesting to standardize a certain type of rich text markup that could then be produced and consumed by a variety of software, both online and off.

There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs and then copy/paste it in the box.

Regular editing on the web is not generally a pleasant experience (I just had to grab my mouse to extend the comment area so that I can actually see what I'm typing) but rich text "WISIWIG" editors are even worse because the edition shortcuts always intersect somewhat with the regular browser shortcuts (sometimes in fun and interesting ways), they're slow and generally simply not up to par with stand alone editors.

Why does everything need to be in the browser? It's a complete anti-pattern as far as I'm concerned. Emacs is often mocked as the "emacs OS" because of how extensible it is but generally this is done by calling external programs, not reimplementing everything in elisp from scratch.

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

#23

Post by anilgulecha »

simias wrote: post #22
anilgulecha wrote: post #4

This is cool :) That said (and not to take thunder away from your page), this is possible because the HTML spec itself allows for any element to be made into a "WYSIWYG" editor by adding the "contenteditable" attribute. What most other larger editors are doing is working around some of the horrendous non-standardized versions of execCommand which varies across browsers. Ideally a web standards body should come out wi…

Wouldn't it make more sense to just add a standard API to invoke an external editor instead of yet again reinventing the wheel? It might be more interesting to standardize a certain type of rich text markup that could then be produced and consumed by a variety of software, both online and off. There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs an…

Agreed. Hence my point that a web standards body is best placed to solve this once and for all by providing a common (reference) component/API.

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

#24

Post by Tade0 »

roryisok wrote: post #20
Tade0 wrote: post #15

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.

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.

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

#26

Post by _wmd »

simias wrote: post #22
anilgulecha wrote: post #4

This is cool :) That said (and not to take thunder away from your page), this is possible because the HTML spec itself allows for any element to be made into a "WYSIWYG" editor by adding the "contenteditable" attribute. What most other larger editors are doing is working around some of the horrendous non-standardized versions of execCommand which varies across browsers. Ideally a web standards body should come out wi…

Wouldn't it make more sense to just add a standard API to invoke an external editor instead of yet again reinventing the wheel? It might be more interesting to standardize a certain type of rich text markup that could then be produced and consumed by a variety of software, both online and off. There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs an…

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

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

#27

Post by mattmanser »

djm_ wrote: post #8
_ao789 wrote: post #2

1k does sound quite appealing. But: most of the time a WYSIWYG editor is called is when in 'admin pages' where little to nobody gives a shit about page load time. It's more about CRUD performing as expected.

>where little to nobody gives a shit about page load time. If it has an end user that is not yourself, I can guarantee you they do care - even if it's not a conscious realisation.

Depends on your target audience.

If it's 10 internal admin users on desktops, the only time they're going to have to redownload the bundled js is when there's a change.

And if you're sensible you'll have multiple bundles, one of which will be a bundle of rarely updated external libraries, including that editor. So once every couple of months they have to wait an extra second or two for a page to load.

Some of the internal apps I've written for clients have a core bundle that almost never changes and then a js file almost per page (which each append a hash of their contents to the URL to ensure efficient cache busting, managed with an in memory cache of the hashes).

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

#28

Post by arethuza »

simias wrote: post #22
anilgulecha wrote: post #4

This is cool :) That said (and not to take thunder away from your page), this is possible because the HTML spec itself allows for any element to be made into a "WYSIWYG" editor by adding the "contenteditable" attribute. What most other larger editors are doing is working around some of the horrendous non-standardized versions of execCommand which varies across browsers. Ideally a web standards body should come out wi…

Wouldn't it make more sense to just add a standard API to invoke an external editor instead of yet again reinventing the wheel? It might be more interesting to standardize a certain type of rich text markup that could then be produced and consumed by a variety of software, both online and off. There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs an…

"standard API to invoke an external editor instead of yet again reinventing the wheel"

Not a bad idea, but for a lot of users they'd want that external editor to be MS Word rather than emacs and I suspect that would cause a lot of other issues....

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

#29

Post by simias »

_wmd wrote: post #26
simias wrote: post #22

Earlier quoted context omitted.

Wouldn't it make more sense to just add a standard API to invoke an external editor instead of yet again reinventing the wheel? It might be more interesting to standardize a certain type of rich text markup that could then be produced and consumed by a variety of software, both online and off. There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs an…

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 since they're not needed to purely "browse" the web.

If you want performance while handling big files you also need to optimize the way you stream data from the disk, something browsers are terrible at. Is there any web-technology-based editor that handles big files decently? Last time I've seen a benchmark it was pretty abysmal. Not that Emacs is great at it (it was pretty bad for a long time actually, especially pre-64bit computers) but it still was orders of magnitude faster than Atom for instance: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

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

#30

Post by jwr »

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 to a style template.

Post reply on HN