81–90 of 106 posts
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…
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…
Consider or . Useful sometimes, but implies too much standardization.
Earlier quoted context omitted.
> maybe you can build some stripped-down version of electron that contains only the parts you need if you're using electron in the first place, I think its safe to assume that re-inventing electron is not within your skillset.
Build in the sense of "compile" more than in the sense of "write"; I'm not advocating reinventing it from scratch, just customizing it a little.
You raise a good point though. If they could make electron more modular it would save on a lot of that bloat everyone always complains about. I bet half the apps could make do without audio, image processing etc
What I really want is a WYSIWYG/M editor which saves/reads from markdown. I suspect that one or more of the various editors out there can do it, but it seems that all I can find are editors that will substitute the wysiwyg part for MD rather than the HTML part.
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…
@marijn On prosemirror.net home page, typing "# " in the sample editor seems to break it.
It's great that it's small, but it suffers from the same horrible interactions that most other web editors also suffer from. 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 becau…
Works for me in Chrome 60. Just return twice, like a normal editor.
That's the same problem.
At the moment caret positions in browsers are limited only by char-positions. There are no carets in between box blocks.
Yet consider my question on SO : https://ux.stackexchange.com/questions/72309/caret-positioni...
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…
Earlier quoted context omitted.
Don't expect the browser vendors to fix contentEditable or inconsistencies for you, this has been the struggle of WYSIWYG editors for as long as they have existed and it really hasn't gotten a whole lot better. You will quickly find out that by the time your getting close to fix those inconsistencies, 4-6 years have passed and your right up there with the rest of the editors in terms of size and complexity. PS: Also…
I will most definitely expect browser vendors to perform these fixes. I think you've fallen behind on what's taking place in the browser world right now, a huge percentage of users are on evergreen webkit browsers (and increasing rapidly). The next 4-6 years of web will NOT look like the last 4-6 years of web. And this doesn't even account for bundled browser implementations (electron, etc.)