4 ms·
It’s really something I don’t understand that the web browsers haven’t come out yet with a decent API to implement a WYSIWYG editor in a website. And browsers
by corentin88 6y ago
It’s really something I don’t understand that the web browsers haven’t come out yet with a decent API to implement a WYSIWYG editor in a website.
And browsers have taken the completely opposite way actually, with the recent deprecation of execCommand.
WYSIWYG is really the basic of tons of app, I would say as much as showing an <input> or using a <select>. And contenteditable hasn’t been of any help, it’s worse in fact.
Where I work, we decided to use Google Closure editor, which is really powerful, but is undocumented and adds like dozens of kbs to our app.
I really hope some day we wouldn’t have to rely on a third party dependency to implement an <input>. With how things have gone with WYSIWYG editor, I wouldn’t be so surprised though.
- wrnr 6y agoexecCommand was used to add rich text to web mail clients, it's fine for writing once but not exchanging documents between browsers because of different interpretations at to what the commands do and how they handle nested tags ala <i><b></b></i> or <b><i></i></b>. Anyway prosemirror has a schema that provides extra info to how the tags should be handled: https://prosemirror.net/docs/guide/#doc https://prosemirror.net/docs/guide/#doc Also this is a much bigger design area then you might think.
- hanspagel 6y agoI’d love to see a more stable implementation of contenteditable, but I think it’s great to have all those choices. Use cases vary just too much.
- xavierlint 6y agoAs use cases vary too much, I don't think this is the browser's responsibility.