Non-WYSIWYG editing

finest feck fips · October 27, 2021

I know this request is essentially a generalization of the (I assume very old) request to ‘bring back BBCode editing’. I also understand that this request may not be practical at the present moment, because of LMG's current platform commitments (Invision) and the large, existing, opinionated userbase of these forums.

So these are notes for posterity about two ways it might become reasonably easy to get good, non-WYSIWYG editing on these forums in the future.

The latest version of CKEditor, the rich text editing library leveraged by Invision for its post editor, supports Markdown output. As a simple, universal markup ‘standard’, Markdown is an excellent, modern alternative to BBCode. Since CKEditor 5 also supports source editing for Markdown, a future release of Invision which has upgraded to CKEditor 5 could likely be made to support flexible, easy, source-based Markdown editing like many LTT Forum users already enjoy on platforms like Slack, Discord, Matrix, and others. An upgrade to CKEditor 5 is thus worth watching out for in future Invision releases!
Should LMG ever find alternative discussion platforms under consideration for other reasons, it should be noted that Discourse has excellent support for source-based Markdown editing with a side-by-side live preview, integrated with the platform's generally modern and pleasant user experience. While migrating to a new forum platform can be laborious, should LMG choose to seek a commercial contract with Discourse as they've done with Invision, such a migration would be included in the contract.
- Presumably, the availability of a WYSIWYG editor is a requirement for LMG, because there are many users here who do not want to have to ‘write code just to format their posts’. There is currently such an editor under active development as a Discourse plugin, and feedback for it is being tracked on Discourse's own forum. This effort seems worthy of consideration, should migration to other platforms such as Discourse ever be up for evaluation.

Thanks, mods, for your consideration! I won't take offense if you lock this post right away as currently impracticable. I just wanted to put in a detailed enough note somewhere that it might be useful for you guys in the future, when you might search or browse through the suggestions sub-forum in order to make a decision about an upgrade or migration.

colonel_mortis · October 27, 2021

IPS doesn't support any other markup/markdown formats, and trying to retrofit it is effectively impossible because there's no sane way to losslessly convert from the HTML of a post to markdown or BBCode, and there is a lot of metadata (particularly in quotes and spoilers) that would need to be preserved. The work required to override all of the logic that interacts with the editor is also pretty significant.

I would use markdown if I could, but realistically we are in the minority and a WYSIWYG editor is the better choice for most people.

finest feck fips · October 28, 2021

For my part, I'd be totally fine using a raw Markdown + preview editor even if it meant I could only use a subset of the normal formatting features.

To me, WYSIWYG editors in the browser feel very dated. Nearly all websites applications I regularly visit/use (Hacker News, GitHub, Slack, Discord, various Matrix instances, various Discourse instances, StackOverflow, Telegram, Wire... even stuff like WhatsApp, Facebook Messenger, Google Chat, and YouTube) all support formatting in some dialect of Markdown.

The Invision post editor reminds me of the overcomplicated, clunky, button-laden, unreliable editor interfaces of the phpBB forums I used when I was a kid, with the additional defect that it can't be turned off. It's like a trip back in time to when people who sold CMS software thought that ‘advanced’ or ‘modern’ somehow meant ‘reminds me of Microsoft Word’. (So do design decisions like notifications that produce sound (???) by default. Who does that in 2021?)

It's strange, since other elements of the UI seem more or less modern.

colonel_mortis · October 28, 2021

I think it's mostly a matter of perspective - if you ask an average person on the street which one they think is more modern, I would imagine that most would choose wysiwyg - markdown is good because its easy to implement (which is why stuff like WhatsApp use it), and because its powerful (which is why github uses it), but for most users they would prefer to just click an italics button than add * or _ or whatever that flavour of markdown decides to use.

For example, slack recentlyish switched from markdown to wysiwyg (though you can input formatting using markdown, it just gets formatted inline).

Ultimately, we are limited by what ips is prepared to support, and they've made it pretty clear that they consider wysiwyg the only option.

finest feck fips · October 29, 2021

I assume you don't mind me using this thread for a bit of discussion. Lmk if I'm wrong about that

19 hours ago, colonel_mortis said:

markdown is good because its easy to implement

This is very true, and it's deeper than it seems! One of the nice things about Markdown being easy to implement is not just that it's easy to add Markdown parsing to an application, but it's easy to add it in a way that works predictably and reliably. WYSIWYG editors' exceeding complexity doesn't just mean that it can take more time to implement the feature, but also that implementations are much more likely to be plagued by bugs as long as they live.

This is part of why WYSIWYG tends to occupy a middle space in terms of the sophistication typesetting and page layout needs. When you need predictable, uniform behavior and you have moderately complex layout or typographical needs, WYSIWYG tends to be much less predictable than WYSIWYM, or a more exacting TeX-style system. Similarly, if you have strong accessibility requirements, WYSIWYG is a problematic approach because two chunks of code can have the same presentation but different semantic properties in a way that impacts accessibility, and a WYSIWYG editor can easily generate correct-looking text, forms, or UX elements that mean the wrong thing and so are not correctly handled by accessibility tools.

But this space is awkward: WYSIWYG is good for when you ‘need’ fancy formatting, but you don't really care whether the editor behaves predictably, or whether its output can be processed efficiently, or the output is accessible, or you're using WYSIWYG to generate scaffolding that you then sculpt by hand by examining some kind of code anyway. In this way, it also invites distraction: it encourages people whose first concern is not layout to waste time meddling with layout as they write content.

It also generates the kind of design problem that makes the IPS developers now throw their hands up and say ‘can't change this’. Using raw HTML to store comments in the database means that comments are now stored with very little semantic abstraction in the database. So restyling them has to involve editing the HTML that's in the DB instead of generating new HTML however one likes from a simpler specification.

This piece from last year comes from a brand management company that deals with CMS and their unfortunate WYSIWYG editors all the time, and in its call for ‘structured content’ advocates for exactly the kind of abstraction that BBCode already was:

Quote

Probably the easiest way to think of the difference between structured and unstructured content is to imagine you're entering a product into your online store. You don't just expect to be given a blank page, and it's up to you where to put the SKU, name, retail price (in three different currencies), images, description and so on. You expect to see fields prompting you to enter this data in a specific format. Not just text boxes either - you expect to see strong validation, instructions, image selectors/uploaders. And in some cases, you expect to see rich text, or the ability to add limited formatting such as headings, paragraphs, emphasis, lists and so on, to the text.

In this example, of course it makes sense to use structured content. You'd be crazy not to! Well here I am saying that you can apply that same mindset to all of your content management.

(Aside: the editor on this board mangled the newline between those two paragraphs upon paste. My text editor, with the same clipboard contents, did not.)

But then the much-vaunted ‘semantic’ code generation features of CKEditor are used in IPS to generate... HTML that's tightly coupled to IPS styling internals?

20 hours ago, colonel_mortis said:

For example, slack recentlyish switched from markdown to wysiwyg (though you can input formatting using markdown, it just gets formatted inline).

I remember when this feature rolled out, because it was a buggy disaster in the way typical of WYSIWYG editors (unpredictable behavior with respect to whether a given styling attribute was applied, depending on cursor position and what was last typed and where). It was so bad that a rant post about it made the front page of HN and accrued over 1000 comments, and they added the ability to disable it completely in very short order. (And if they impose a WYSIWYG editor again, I'll migrate the company I work at away from Slack.)

(Aside: when I place the cursor on the empty line between the quote block and paragraph above and press the backspace key, it does not delete the newline. Instead, it does something baffling: it highlights the quote block. However, if I press the delete key with the cursor in the same position, it does delete the empty line. By contrast, if I place my cursor on the empty line between this parenthetical block of text and the paragraph above, the backspace key and the delete key both do the same, expected thing, and remove a newline.)