MarkupEditor's First Beta Release

[stevengharris]

It's time to declare that the MarkupEditor is feature complete and ready for Beta. Or, as we used to say, "good enough to criticize". Beta 1 is the 0.5.1 release.

At this point, the MarkupEditor really just needs more people to consume it and use it. I am going to limit my own work on it except to respond to issues people raise and those I find when I am consuming it myself. I will release 0.5.x versions as needed during the Beta period.

What I would really love from the Beta period is feedback. In particular, I would like the MarkupEditor to be a polished product. For you as developers, it should be easy to integrate into your apps. I hope your use case will help me to sand down any rough edges you find, but you need to let me know. For your users, it should just work, without any surprises or issues. This means that your feedback will need to come with enough information to help me identify the problem, which might involve screen recordings. I'm happy to hear general comments, suggestions, or observations, too. Pull requests welcome :-).

Here are some things I am considering for the Beta period:

1. I will likely release 1.0.0 when the other app I am working on that consumes the MarkupEditor is ready to be exposed. Like you, I am a little nervous having a dependency on Beta open source software :-).
2. Sorry if this upsets anyone, but I am going to eliminate the support for iOS and MacCatalyst version 14. iOS 16 is just around the corner as I type this, and I'm not doing any testing on earlier iOS versions. The conditional code to deal with iOS 14 is a pain to sort out sometimes, and I definitely don't want to respond to issues associated with it. Thus, if you are living on the edge and consuming the MarkupEditor in an iOS or MacCatalyst 14 environment, you are going to have to deal with a branch from Beta until you come to your senses.
3. I am considering refactoring markup.js into multiple files. It's kind of ridiculous now, coming in at over 10,000 lines (including voluminous comments). I think I am the only one who really cares, but I can see that it might make life easier for anyone brave enough to submit a PR that crosses into the JavaScript world. In my defense, it was pretty well contained when I started out, but as we all know, these things have a way of getting out of hand. If I do this refactoring of markup.js into multiple files, they should all just get installed as resources with the package, so I don't think there will be any impact on consumers of the MarkupEditor.
4. On a related note, I am considering how best to use a JavaScript minifier as part of the build process. I can't even imagine maintaining this code without the comments I have in it, but it also seems ridiculous to cart them around in an app that consumes the MarkupEditor. If anyone has actual experience with using a minifier as part of their delivery process or other suggestions on this front, please comment in this discussion!
5. I'm still not overly happy with the touch device experience in the MarkupEditor. TBH, I never expected it to be great or overly useful on small format devices, but I want it to be usable. My principal use case is on a Mac, but I hope to use it on iOS devices myself, so may be inspired to do more to improve the experience on them. In particular, I hate the scrolling menu bar, which I am thinking of replacing with usage of iOS 16 ViewThatFits and Layout (another reason to jettison iOS 14). My Product Manager (haha) convinced me that shipping Beta was more important than making these changes.
6. I would like the font sizes, which are currently hardcoded in markup.css, to work properly with Dynamic Type. I haven't spent any time to look into this and hope it is not a huge change. Mainly I am concerned that MarkupEditor consumers who put effort into being good citizens in terms of accessibility (which I aspire to be) will not be able to use it. Again, suggestions (or even PRs!) on this front would be welcome.

Hope people find it to be useful!

- Steve