Hehe, that's awesome, so glad to hear that! Mathjs is really great with units out of the box, and they also have a custom unit feature that I may use in the future to beef up the unit library.
The last thing I want for notable developers of high quality WYSIWYG editors is to get upset. Take this with a grain of salt. Continue doing the great things you do with ProseMirror and your other valuable open source contributions. But don't get upset. Try getting inspired, to move with the times, to trust browsers more, to make YOUR projects smaller, lighter, and easier to use.
P.S. Just because something is small, doesn't mean it's a crude afternoon hack :)
> The last thing I want for notable developers of high quality WYSIWYG editors is to get upset.
While I'm certain you have good intentions, the size comparison chart at the top of the README is a bit misleading. It would be fair to list out the trade-offs on going ahead with ContentEditable so that users can know what they are getting if they choose Pell.
To clarify, Pell looks awesome and I don't intend to diss on your project or your hard work, just that the way the project's README is laid out I feel @marijn's response is not totally unwarranted.
Do you genuinely believe he has not explored that approach? How is one meant to get inspired by something they have already explored? Please don't be rude and wrong at the same time.
Hi everyone, author of pell.js here, thanks for all the positive AND critical feedback. Hey, this is Hacker News, how boring would it be if everyone's comment was just "Cool" or "Good job"? I love hearing the gripes and individualized complaints of smart people that have worked on similar (and much larger) projects.
I'd like to mention a few things about pell.js and it's goals:
- It was not made to be the most full-featured editor out there
- It was not made to fight with or worry about browser inconsistencies (browsers are converging, quickly too)
- It was made to demonstrate the underlying simplicity of something that looks like magic to most beginner developers (including myself) and to teach people how to use `contentEditable` and `execCommand` via a tiny, extremely readable codebase
- It was made for people who need just a basic WYSIWYG editor in their app/site/whatever and who care about bundle size (PWA's anyone?)
Over time, many of the inconsistencies and issues will get fixed or implemented in pell, but the goal of remaining tiny yet functional will always remain paramount.
I wonder if you had branded this project along the lines of "You Might Not Need jQuery"[0] you might not have gotten so many comments dismissing it as not a "proper solution" since it "only uses contentEditable"...
I think it's good to showcase new ways of solving old problems using the latest in browser tech.
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.
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.)
And those evergreen browsers are still doing terrible things when it comes to contentEditable, and they don't really have a lot of choice, because it's an underspecified poorly conceptualized idea that really doesn't leave them much room to things right. There's some work happening on the W3C editing taskforce to improve the concepts involved, but that's also moving at a glacial pace, and having to struggle with browser vendors at every steps.
So again, don't suggest we (editor implementors) are clueless or behind the times. We happen to have spent quite a bit of time on this stuff. We know it.
Again, you are getting offended. Not once did I suggest editor implementors are clueless. They're likely some of the best and sharpest developers out there. Please, as I mentioned earlier, take this project with a grain of salt.
By "fallen behind" I meant still making the assumption that many users are still using outdated browsers. This is not the case anymore, especially in the last year. And because of this fact, many WYSIWYG editors might be implementing a lot of cross-platform bloat that just isn't necessary any more. Rather than raging, perhaps browse through the ProseMirror source and see what you can remove as "obsolete" code.
ProseMirror was started 2 years ago, initially only targeted evergreen browser, and has recently grudgingly added support for IE11 because customers asked for it. But yeah, I guess for some parts of some of the older projects this may apply.
I'd also be optimistic about a future with sane browser WYSIWYG editing, but it has been an uphill battle. I know the W3C Editing task force [0] has been trying to push the limits, but very few successful outcomes so far.
There is a GitHub issue for keyboard accessibility, although I don’t see this as a necessity it shouldn’t be too hard to add, so I will probably get to it at some point. Thanks for the feedback.
This is true about the notification potentially not being close to the action point - though the way I thought of it is that the user should know what action they just took therefore will understand the message they just got. Especially if the site uses this library throughout, the user will be used to this kind of feedback on their actions. It also makes it a bit more friendly for responsiveness as the developer doesn’t have to worry about placement or if the alert will fit on the screen properly.
I try to keep related interactions near each other so showing notifications near the source turned out to be more problematic than having a single place for notifications (like near the top where there useful information can be seen but no interactions occur)
It was apparent after just a simple mockup that the notifications would get int he way if the user was makign many rapid interactions.
In my paricular application the notifications could be used as a history of interactions that could be opened up and examined in more detail.
You’re very right, I guarantee there is a certain level of bloat to the .js file - the repo you see in there at this moment is not far off of the version 1.0 that I created just to achieve the desired functionality. As you’ve noticed - there are probably a lot of optimizations and improvements to be made.
You're welcome, it was fun to make! It is a good idea to add detail to the browser compatibility and I will eventually do so. It was before this repo gained popularity that I did the quick browser testing to warrant that statement. Thank you for the suggestion.
