![Cover image for Designing the ultimate (INCLUSIVE) writing tool. [Part 1 - a WYSIWYG in 745 *Bytes*! 😱]](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Feozj8t064njtfkgm0set.JPG)
A WYSIWYG in just 745 bytes of JS (gzipped)? Check. A bonus JS syntax highlighter in 900 bytes of JS? Check. Combining the two? You bet! Things are...
For further actions, you may consider blocking this person and/or reporting abuse
I once wrote the engine for a small syntax highlighter in less than 140 bytes JavaScript for a code golfing competition: gist.github.com/atk/1084980 - it ran on the page that presented the code golfs.
The RegEx required for js is not for those faint of heart, though. 😉
I always enjoy seeing people "Golf" things.
I used a great version of pong in an article on steganography that was something like 460 bytes fully functional with scoring etc. as the thing I was hiding in the image. Blew my mind!
Love your solution.
"The RegEx"...singular? You mean the 10 I have so far 😋🤣
No, the one that is used for my version:
Yours is an example of readability by comparison. 😁
Yeah but I couldn’t work out how to also do different colours, unless I used match groups I suppose and increment the group in the loop...
Probably could be done but obviously the idea is this is a base for something useful so I don’t think I will even try it! 😜🤣
That's exactly what I did.
Ah yes, I see it now, being a non code golfer I didn't get that was a counter you had implemented!
Ironically this article rambles on a bit in places and isn't as well structured as I would like.
However, that is the whole point of this series, I will be using the tools I build to improve my own writing and take some of the thought process out of ensuring I use inclusive writing. I know my writing sucks sometimes! My apologies for that!
Over to you: if you have ever thought "I would like to see XXX" in a WYSIWYG to make your writing better or make it easier to create great content then let me know in the comments, all ideas are welcome (even slightly silly ones!).
Protip: change the syntax highlighter to highlight markdown, because no one is going to write JS in a WYSIWYG anyways
Nobody is going to write markdown in a WYSIWYG as the whole idea of a WYSIWYG is it looks like the end product and you don’t need to know Markdown, HTML etc 😜
Plus if you copy a code snippet in to a true WYSIWYG it is nice to see the syntax highlighting live!
I think I have made this all very confusing by combining the two for jokes! I think part two is going to need a lot of notes to cover this and the deprecation you mentioned in another comment!
However you have made a good point that Markdown import and export (that will be hard as some things aren’t possible in markdown that are in a HTML wysiwyg) needs adding to the spec list 👍
How about using pegjs to build a parser to do the syntax highlighting? Sure it's a bit more work, but I'm pretty sure there's a starter grammar out there that could help... like this one
Thanks for the suggestion, I will keep a bookmark on pegjs as if this evolves then it could be useful, but at the moment I want to understand every nut and bolt of what I am building.
I presume pegjs is purely a generator and I don't need it as a dependency once I have created a parser with it?
To be fair the point of the syntax highlighter was more to experiment with the headache that is live colouring on a WYSIWYG editor.
It is actually a really complex thing to deal with if you don't cheat as I did with the double stacked divs perfectly aligned and hiding the content in the
contenteditablediv that you actually write in.I am experimenting as one idea for one part can then be applied to another part while I am still prototyping.
For example, one thing I didn't mention in the article is trying to guess if someone has added a "non English" phrase to a sentence like "c'est la vie" so that we can prompt them to add a
<span lang="fr">around the phrase so that screen readers can announce things properly.The RegEx parsing method used in the syntax highlighter would work nicely on that scenario as I could just do a load of pipe separated words that are common in English and some basic occurrence counting to highlight potential other languages (or at least that is my first thought of how to do it...that could also change!).
Also just having an array of RegExs and corresponding
<span>outputs seems like a really simple way to cover basic word lookup for swear words, racist language etc. that isn't sensitive to the context of the document.One thing I learned in all this is apparently a prebuilt piped RegEx is really efficient using
.matchon a string when trying to match multiple needles to a haystack.All very much a work in progress and suggestions like the above are always welcome!
I'm interested to see how you proceed with this for sure :) PegJS produces a parser that is a standalone JS file - the rules of Peg are very similar to regexes (though no backtracking etc) so that's what brought it to mind.
I'd wonder also about training a model to recognise sub sections of the document etc, though you are right, categorical searches for racist or swear words would also make sense.
Yeah the training a model bit is way beyond my current abilities (hence why I have shelved Grammar suggestions for now as trying to do that with simple algorithms seems very difficult!).
This project does provide some really interesting challenges and I don't think I can ever make a perfect solution. But who knows, maybe I can produce something useful enough that it can be turned into a paid service and I can pay someone smarter than me to handle the scary stuff! 😋🤣
Thanks once again for the suggestion, I will have a play with PegJS at some point in the future as it is interesting from a learning perspective, especially that parser example you linked to, still scratching my head on some of that!
Nice... I would have built this
document.execCommandwas supported more, but it isn't.Yeah that is a real issue, it isn't marked for removal in any browser yet so at least 2 years use of it.
But I agree, against good practices to use it in anything new!
I should perhaps making a point of that in the next article so people don't use it without knowing the risks, thanks for the great suggestion!
But if you don't use it, you don't get undoing capabilities anymore
Undo is not too bad as we can just store the exact state each time there is an update.
Or better yet we can use doc diffing and just store the differences. I have to admit I have no idea which is better!
I think the answer I have at this point is to use it, but build it in a way I can swap it out easily. 🤷♂️
Diffing is better if you care about space, which, to be honest, is not a big concern right now, unless you plan to persist them.
About 2 years later we are still waiting on Part 2.... Hy GrahamTheDev, is there more on the project?
There are plenty "WYSIWIG" editors like TinyMCE, but having some free code as a basis could be really be helpful in some cases.