Word of advice: Everybody (I know) who developed a contentEditable editor moved at the end away from it or came to the conclusion that a event based editor is the technical better choice. ContentEditable looks only good at the beginning and has many nasty little and bigger flaws.
All problems start with caret placing and multi browser support and ends with undo or collaborative editing (when you go deep into the rabbit whole).
When I think about it: Never develop an editor on your own ;)
That was exactly my experience few months ago when I was building a wysiwyg resume builder. The first problem I faced was that if I was entering some text and switched from the browser to another app and then back to browser, I would lose focus. So I had to built custom logic for that using a whole bunch of workarounds. But this was an even bigger pain because if the user's cursor was in the middle of a sentence and not at the very end, then placing the cursor at a specific position was quite complex in content editable. Similar problems if the user had selected/highlighted some text.
Undo/redo logic was another nightmare. And copy paste required a ton of clean up before.
Next issue I faced was that if the container element had certain css formatting applied (can't remember which one) then if I hit enter, then backspace won't work. If I remember right, this had something to do with a well reported bug related to pre-wrap, white-space, break-line etc. This was also when I discovered that the content editable would work differently across browsers. This was basically when I dumped content editable and went with a simple textarea and a "fake dummy" hidden textarea used for calculating the size, formatting etc.
Believe it or not, it used to be a lot worse. One of my first dev projects was a contenteditable based editor, and this was back in 2008 so I needed to support IE6-8, which had it's own separate API for manipulating selections/ranges and of course a whole bunch of bugs. Firefox's impmentation wasn't much better!
Yep, I remember running into the IE type edge cases too with contenteditable though I just ended up excluding IE all together as not many people use it now a days anyway. I also remember running into bugs which were logged for Firefox over a decade ago for contenteditable and no one had fixed them.
As someone who's worked on this, I'm oh so conflicted. Yes, it's mostly a terrible idea, if CodeMirror and the likes work. On the other hand, there's so much default behaviour that's just excellent that'd need to be reimplemented if you started from scratch. It can't be denied that contentEditables have the advantage of just requiring much less code overall.
To this extent, I've written a hook for React/Preact that attempts to be a decent code editor basis on contentEditables: https://github.com/kitten/use-editable
Funnily enough, if you just search the code for "// Quirk" it's easy to see that this experience wasn't pleasant in the slightest. But it did allow me to write a code editor in just about a day which can be found here: https://trygql.formidable.dev/
I'd say, there's plenty of edge cases to take care of. But on the other hand, things like composition, selection behaviour, and other niceties are things that you just have to take care of much less
This was my experience, too. Contenteditable wasn’t as bad as I was led to expect going into the project. (It is terrible, but not the showstopper everyone says it is.)
The biggest problem I have with it is that layering on collaborative editing is nontrivial.
Tiptap does a pretty good job of it, but really that's just using a contenteditable as an interface to update a well-defined JSON representation of the content.
If you are planning to write a custom editor Tiptap is a good starting point, but it's weirdly over-complicated in places.
There are still nights I wake up screaming, remembering the time I tried to build an editor with contentEditable. Is there a special place in hell for those who forced this spawn of Cthulhu upon us? Or should we pity these souls, who were the first to lay eyes on these unimaginable horrors?
If you ever meet someone who thinks that the lovecraftian amalgamation of HTML/JS/CSS is a sane platform for developing applications, just tell them to build an editor using only contentEditable and the standard browser APIs. Then wait a few days. They will hate you, but at least they'll be forever cured of their delusion.
Yes, it's that bad. No matter how long you have been programming, no matter what you have built before, contentEditable will defeat you. Decades of experience, written your own programming language, database, editor? Oh you poor soul, contentEditable will laugh in your face, because there is no logic to it. It is the very embodiment of edge cases built upon edge cases, with a smidge of browser incompatibilities sprinkled on top, then all dumped onto the garbage dump that is caret handling.
I'm a contentEditable survivor. The dark episode is now behind me, yet no matter how much time passes, I will forever be scarred by the experience.
You literally build the editor from the ground up (events like keystrokes modify a data object which then changes the page), rather than trying to patch the browser's editor (including all possible versions of every supported browser) into doing what you want.
So when stuff is pasted in from Word or whatever other weird Rich Text Enterprise application - what's actually doing the heavy lifting of translating all that \\rtf\\section\\block\\blockend\\secondend garbage into HTML? Is it the `sanitize-html` library here? Is it the browser? My first intuition would be "pasting a bunch of formatted stuff from Wordpad into an HTML document surely doesn't result in anything reasonable, right?" But then seeing the direct jump from "alright, stuff was pasted in, now we only want to allow these HTML tags" makes me think somewhere in here some magic happened to convert it.
I think that's probably the most interesting part here. What happens for images? Do they get converted into an <img src="data:base-64;..." type thing?
A native app will copy a selection into the clipboard in several ways, basically accounting for a selection of common MIME-types.
So when you copy an image from Finder in MacOS, if you paste it into a terminal you get the file path and if you paste it into a comment on github you get the contents of the file as a binary blob.
When pasting, an application is essentially querying the clipboard for a representation of the data it can use, and if there is none, it either defaults to something or fails.
In a well designed program, all of the translating and parsing is done before sending to the clipboard. If you copy text from MS Word and paste it into a content editable field in a website, you might expect some consistency.
I believe at least on windows this bit isn't always true
> In a well designed program, all of the translating and parsing is done before sending to the clipboard.
To avoid unnecessary work a program can opt to delay rendering until it's pasted or the program is closed. This is why excel will sometimes ask you if you want to keep your clipboard on save.
Based on behaviour I've observed on Linux before, I think X11 might only use delayed rendering (at least for non-text stuff), and so pasting from a closed application just hangs the recipient.
Is there any way to force which gets chosen? I love being able to copy and image and just paste it to WhatsApp/Messenger/Whichever other client, but if I do copy an image from the internet it’s very hit or miss if it shows up as an image when I paste, or a link. If I download the image, and then copy the downloaded one, it always shows up as an image
I ended up working around this by copying into GIMP and copying from there, but of course that's a suboptimal workaround. There's surely some small utility application for this.
When pasting from Word, the contentEditable will gladly accept any formatting that came with the paste (e.g whatever strongs, bolds, italics, links, headings, tables, what-not you may have in your clipboard), and so the sanitize-html NPM library essentially strips out the elements I do not want for UX consistency. Since I'm building this contentEditable just for a singular paragraph as part of a larger block-based editor, I only want it to contain what a regular paragraph would (e.g bold, italic, link), but nothing else.
So, all-in-all, the clipboard contains still everything, the sanitize-html library would strip things from it that you wouldn't want, so that you're left with only the formatting you do want. As for images, since I'm stripping them out as well, there will not be any images. By default I'm not sure if they end up as base-64 (I'm leaning to believe that rather they would get local URL's like file://...).
Rich Text Format is the default representation for formatted text on the Windows clipboard. Any application that can paste rich text should accept it. When you paste directly into a content-editable the browser should convert the rtf into html.
Most modern apps will also copy an html fragment to the clipboard so the browser could use that directly.
According to stackoverflow, when you read from the clipboard in javascript the browser gives you access to its synthesised html version of the rtf content via ClipboardItem.getType. That's what you would expect, but I haven't tried it.
Odd choice to use ClojureScript in a tutorial. The point of a tutorial is to convey information effectively. This is like a physics professor deciding to lecture in French because they think it sounds better.
That’s right, no one in France actually knows any physics, because it’s completely impossible to convey information effectively in French, and they just use it because they think it sounds good. Just like ClojureScript in tutorials.
If you /know/ you're in front of an english speaking audience and deliberately don't speak that language sure, but there's no specific programming language for HN. Hell, hackernews itself is written in a lisp.
That doesn't really matter, most web development is in Javascript and if you want to communicate to web developers widely you should use (something that looks like) Javascript.
I found it interesting, then remembered that in every single case (except maybe TypeScript) the new language is simpler only as long as you follow the tutorials closely. (Usually a mess of missing IDE support, missing documentation, big undocumented boilerplates etc).
That said, a number of those languages are interesting and great even of they aren't as simple as the tutorials make them look.
No, the parent comment's point was that some people use clojurescript, just like soms people speak French. Sure, most people who use clojurescript can read javascript, but most people (in Europe/NA) who speak French will also understand English. And yet we don't criticise profs of physics in France for lecturing in French.
I wouldn't call what I write a tutorial per se, more of a "I went through this problem and this is how I solved it". And consequently, I went through this problem in ClojureScript. I even linked to the project I'm building, which is entirely ClojureScript. Perhaps ClojureScript isn't for you, and that's fine, but seems odd for me to criticize on the merit of language choice when you're on what is effectively a programmers forum.
If this article was trying to get me to try ClojureScript, it had the exact opposite effect. Beautiful syntax to define a class had me at first, but then fell on its face when I saw that first "if" and compltely lost me with the gymnastics required to.. wait for it.. make one thing happen after another?
Physics lessons are taught in French in France+... It's not because a programming language is not very popular that it shouldn't be used for a tutorial; on the contrary it can help building the network effort most of them rely on.
+ not only there but also in Québec, Switzerland, Belgium, a lot of African countries. Millions of people understand French as a first or second language. Moreover there is a lot of scientific literature in French, in particular in linguistics (the field was created in French, actually). I find your statement rather insensitive.
I'm French and I don't find the statement insensitive at all. English is the de-facto language of the web, trying to deviate from that is making it harder for people that read your content. This is not a value judgement, there are lots of language with a beautiful history and culture, English included. But what's used the most and thus the most useful is a simplified version of English.
I'm not, JS is the most used language for frontend, and saying that using something else reduces the clarity of the article is perfectly valid criticism.
Agreed, I largely gave up trying to understand what the code is doing. The message really gets lost unless you already understand clojurescript's flavor of React.
Nice. I recently wrote a custom contenteditable component/parser used for chat and elsewhere in https://sqwok.im and ran into a bunch of the same issues.
I ended up switching everything to use regex with rigorous testing as there were far too many edge cases, particularly between the different browsers.
I agree contenteditable leaves a lot to be desired, and indeed I had to file a few bug reports to the vendors while working on it (e.g. in firefox hitting backspace against a <contenteditable=false> within a <contenteditable=true> wouldn't work)
Have you run into some of these cross-browser issues? How have you approached it?
Honestly, I haven't even gotten into the cross-browser testing parts of this endeavour yet and what you write about frightens me hehe. But, since the project I am working on that has this is entirely open source, I figure if someone really wants rigid support for X browser, perhaps they can contribute. I usually build my OSS projects for myself, and share it only because why-not and perhaps someone can learn something from my projects.
As for ClojureScript, well, I just find it a lot more concise and easier to read than a non-lisp. I realise this is not the case for someone who has never seen Lisp before, but from my experience, people who do learn how to read a Lisp tend to also see that point of view of it being highly effective at conveying meaning. I just feel like there's less cognitive overload with it.
I still make money writing plain old JavaScript, Java, PHP and other C-derivatives, but for personal use Clojure is my go-to.
I would highly recommend using DOMPurify over sanitize-html. It is a lot smaller in bundle size, it is also well maintained: https://github.com/cure53/DOMPurify
The author mentions to build their own sanitizer, which I would recommend against. Maybe for this use case (extracting a few b tags), it’d be fine, but as soon as links are involved: please stand on the shoulder of giants in order to prevent XSS.
Thank you for the suggestion! I'll make sure to look into it. And yes, you're right that I should stand on the shoulders of giants. My only problem is that I want my project to eventually be used by a variety of build tools for ClojureScript, and afaik there's only one that supports NPM packages (Shadow-CLJS), so I try to get by without and also lessen my dependency on NPM packages.
I'll take the downvotes, and no disrespect to the project itself - but only to the falling-over-self comments about ClojureScript.
If you care about semantics at all, or even want your code readable by someone who is in their early days of trying to understand and learn code - it's just ugly and hard to read.
I've been coding since I was 14, and I don't feel bad in saying that I can't tell you what this line does without looking it up. (reset! caret-location nil)))) I can't imagine how you could argue this is good and adheres to any philosophy of openness or readability.
Your comment implies that you’re only familiar with C-style curly brace languages.
ClojureScript is a Lisp language. If you’ve never learned one, I highly recommend it. It will make you think about programming differently.
As esr puts it in his (in)famous “How To Become A Hacker”:
“LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.”
For myself, I learned Scheme (another Lisp-like language) in graduate school through the How to Design Programs curriculum (http://htdp.org/), which despite already being a professional programmer, I found enlightening. And then again in the online programming languages course from Brown: https://cs.brown.edu/courses/cs173/.
LISP is super easy for humans and machines to parse which makes it readable and I'd be hard-pressed to call it ugly for that reason--I think it's pretty darn easy to read having fairly small exposure to LISPs. I personally prefer ML-family syntax and never liked the ergonomics of working with parentheses, especially in Vim, but I agree the parent comment reeks of exposure bias making claims about what others know and should feel comfortable with.
If it's so easy, why are none of the early code learning platforms employing Lisp or Clojure? An honest answer is that it's too hard to read for children who are learning. It's not easy, saying it is doesn't make it so. Ask a kid if it's easy.
Scheme was literally one of the OG languages to teach to beginners. As an English speaker, I've nested parentheses is normal writing, so it shouldn't be a foreign concept.
HtDP uses Racket and scales from graduate school to middle school children. Part of the reason they use Racket Scheme is that it is extremely easy to teach the syntax.
As for why it's not used more widely, same reasons Lisp like languages aren't used more often in industry: inertia, fear, worse-is-better syndrome.
Programming languages in which line breaks and indentation are not significant are hard to parse for humans, period.
Take any Javascript or C program, and remove the line breaks so that it's just a linear string of tokens. It's no harder for the parse for the machine. Much harder for you.
Humans parse non-trivial examples of Lisp using indentation clues that the machine ignores, just like in the case of a large number of language families.
Not all structure in programs is indicated with indentation; sufficiently small chunks of programs are written on one line. The structure of those chunks is easy for humans to understand accurately if they are written in Lisp because there is no ambiguity.
Lisp syntax also has a way to break any expression, no matter how small, into multiple lines with indentation. Any two Lisp programmers will do it the same way:
(+ (* x
x)
(/ y
z))
there are no questions like "do I put the slash at the end of the previous line"?
If you can't understand some one-line chunk of code, you can get it into a canonical indented form, and this can be automated.
An exclamation point being part of a function's name is certainly surprising to me. It would be like learning that `foo[5]` was a function named `foo[` being called 5x or something..
(Apparently it's a ClojureScript convention to put an exclamation point on impure functions.)
Exclamation marks are also used in Ruby to differentiate between mutating methods vs those that return a transformed copy. So, `array.sort` vs `array.sort!`. Question marks are also used, but more aesthetically vs functionally: there are `array.empty?` and `array.include?` but no `array.empty` or `array.include`.
Swift allows unicode in symbols, so you can name functions with emoji. Thankfully that hasn’t caught on.
J has a similar idea–built into the language syntax vs using characters in function names–where a period can be used to inflect a primitive.
It's not about having an open mind. I teach children to code, and you'll notice that there are ZERO early coding learning platforms that take a Lisp/Clojure approach. Do you think that is a coincidence or because it's an ugly language that people can't easily read at an early age?
That's a poor comparison, given that reading Chinese requires you to memorize thousands of symbols that have little internal consistency or rules to deduce their meaning. It's _actually_ really hard and time intensive to learn to read. That doesn't make it ugly of course. Just not well suited for the analogy you're trying to make. I guess Arabic would be a better fit here, since it has an alphabet, if I'm not mistaken.
It's not about having an open mind. I teach children to code, and you'll notice that there are ZERO early coding learning platforms that take a Lisp/Clojure approach. Do you think that is a coincidence or because it's an ugly language that people can't easily read at an early age?
"I've been coding since I was 14, and I don't feel bad in saying ... I can't imagine how you could argue this is good and adheres to any philosophy of openness or readability." is like saying "I have experience, therefore that invalidates any experience you might have."
If you don't have any interest in perspectives outside of your own then I can't imagine learning anything can be easy at all.
Since I come from a school where scheme was taught as a first language, I find clojurescript a hell of a lot easier to read than javascript. Half the time I feel like javascript just does things out in the aether with side-effects and I find the code really hard to follow when it does. Clojurescript has a much easier to follow flow for me.
That doesn't mean javascript is ugly and hard to read for someone else.
It's more like "I want the world to understand code, and I don't think we get here with bougie languages that divide learning instead of emboldening it." Language should be easy, it shouldn't be a ring-kissing circle jerk. Clojure is not on any early learning platforms. There's a reason for that. Children don't understand brackets, cause you know, children. If you look at the data on children learning languages, Lisp and languages like it actually divert wouldbe programmers away. Not something I consider positive.
Clojure is hardly bougie or a circle jerk considering it's focus on pragmatism. The first programming language taught in both my highschool and college was PLT-Scheme (now Racket), which is arguably more bougie than clojure considering its' academic focus as a PL research language.
Zero people dropped out in HS. In college I'm pretty sure you're going to have people dropping out of the intro course for programming no matter what language you choose when it's taught in 60-100 student lectures with professors and TAs that have been steeped in CS so long they no longer remember what being a beginner is like.
You seem to be pushing the children narrative very strongly, as if it were some deciding factor on what languages adults should learn for their own pleasure and what not. At no point was this article directed at children. If you do not like Lispy languages and find them hard to understand, that's totally fine, but that is every bit your problem, not mine.
Let's completely forget for a second that the article wasn't basically prescribing ClojureScript as a omnisolution that we're all dumb for not converting to - it was my opposition that the point is ignorant of 99.5% of the rest of the world. His argument was that is was readable - it isn't. Again, ask someone who's learning whether it's readable. And I better not find you in a thread, arguing that semantic HTML is far superior while you flog for a non-semantic language.
I think you are delusional. Me writing in a blog post that I like Clojure and I recommend you trying it is very far removed from "prescribing ClojureScript as a omnisolution" especially as I specifically mention that all I write also applies in regular JS and React.js. If a friend recommends you try out a beer he/she likes, are they also prescribing that beer as an omnisolution? Because that's what you're saying. Ridiculous. Go yell at someone else for writing a blog post in a programming language you don't understand. There's a lot of blog posts to yell at out there. And I'm sure they didn't consult children before writing them as well! The tragedy!
Why would you expect to know what a line of code does in a language you've never used without looking it up? If you've ever used hooks in react it is roughly equivalent to setCaretLocation(null).
Beauty is in the eye of the beholder, as they say. But, like I mentioned in another comment here, it seems odd to me to criticise on the merit of choice of language on a programmers forum.
I teach children to code, and you'll notice that there are ZERO early coding learning platforms that take a Lisp/Clojure approach. Do you think that is a coincidence or because it's an ugly language that people can't easily read at an early age?
I think it's market effects and nothing else. Schools teach first and foremost the skills that are easily employable. Hence why most schools teach either Java or JavaScript these days. Whether or not something is nice to read (btw, what does this even mean? Your lack of experience is not an indication of how "easy to read" something is) has pretty much nothing to do with it. I hope this is not the attitude you teach children with, because if you think something you do not understand is by default ugly, you have bigger problems than my small blog post.
I also do not write my blog for children to read. In fact, I don't even have a target audience - it's all "I had a problem and this is how I solved it", and perhap some Clojurian finds my posts on Google and finds it interesting. I certainly know there are Lisp-likers here on HN, as well.
Code should be for everyone - not just a few ring-kissers who feel they have past a certain integrity threshold - or maybe better said, you think Lisp is some sort of Master Sword that you pulled out of the rock - so therefore, it must be better.
What does "nice to read" mean? It means that I don't spend another 2 hours falling over myself trying to convince 7 year olds why being decisively pedantic is better than more expressive, semantic code.
You're still caught up in the idea that coding and programming is for an elite group of people, and that perspective is boring and old.
That's a pretty weird approach to take imo. So you see the world through the lens of a 7 year-old? So we should not teach anyone advanced math either because a 7 year-old wouldn't understand it? Perhaps people shouldn't drive a car, because a 7 year-old wouldn't know how! Listen, I can learn and write about whatever programming languages I like, without having to once think about you or the children you teach.
You can label me elitist, you can label me however you like, but as a teacher you have a funny way to suppress people's ability to share knowledge on the basis that you or your children don't understand it. Shouldn't you as a teacher be happy that people are sharing knowledge on a wide variety of things? And yet you choose to call languages ugly, hard to read, and shame people for sharing knowledge because it isn't in your beloved programming language. And you call me elitist?
It's not shaming to say a language is ugly. Languages - like art - are open to subjectivity. You're arguing for objectivity towards Lisp/ClojureScript - so yes, you are acting in an elitist way. Should I encourage children to learn eye for an eye, simply because that's a way of thinking? Or would I be better to give them tools that make their world easier to comprehend and think for themselves?
It's funny you brought up math - because children learn math at very early ages, and they progressively grow to understand more complicated math as they are able. The entire time the child is learning math, though. Math is the most basic instruction set that is used to count sides of a shape - all the way up to complicated thought experiments involving quantum mechanics. It is a semantic language that not only doesn't require a manual, it doesn't even require a theological conversation to apprehend it. So much so that when we attempt to communicate with life outside of our solar system, we use math to communicate with them. Why do scientists chose math over latin, or Russian? Because chosing a nationalist language would be dumb. Why would I chose to teach a language that obfuscates readability? Seems dumb.
So because you believe that one group of people can't learn a particular language, nobody should be allowed to post using that language on the internet? I both have been taught racket and taught racket myself in schools, and at no point was coding presented as 'only for elites.'
I'm not sure why you hate lisp-like languages so much and can't accept that it's actually more comfortable for some people. I'm sorry if you were hit with one too many "lisp is for a more civilized age" people.
My comment got prohibited while the parent was flagged, but the example code seemed pretty understandable to me and I've never written a line of lisp code in my life (the closest I've come is cutting and pasting lines into an emacs config file). While Lisp has claimed ownership of all the parentheses that Python has eschewed, it's a more than reasonably readable language and predictable in its syntax.
All problems start with caret placing and multi browser support and ends with undo or collaborative editing (when you go deep into the rabbit whole).
When I think about it: Never develop an editor on your own ;)