One more thing I just realized: when it try to use fullscreen mode, only the height is expanded and the width of the composer stays the same. Also, the border elements seem to be missing.
Hey folks — quick update to share that we’ve made the new composer available as an opt-in, experimental setting. You can turn this on in your community today, but please keep in mind that there are functional limitations at this time, which are noted in the OP of this topic. We’ll keep this topic up to date as we continue to release fixes and improvements.
May I ask the team if you’re actively working on completing the wysiwyg editor, or switched your focus to something else for now? Aking for a friend
We are actively working on it.
It’s a priority for us to first get it into a state where it is on by default for newly created sites.
We don’t think we are too far away from that, but there are a handful of things we have in progress that we want to complete first, like a better UI for editing links, and handling cursor position when you add a quote, for example.
Once we meet that goal, I expect we’ll be continuing to refine it as it’ll be in front of even more people and generating additional their feedback.
Anything on your mind about it in particular other than that?
If you ask me, the only thing that’s missing for me and makes me switch back to the markdown editor quite often is resizing images. I often post screenshots, and most of the time I size them down. Unless I’m using a considerably outdated version of Discourse (which I don’t think is the case), image resize is still impossible in wysiwyg, right? Once done, the current version would work for like 95% of the cases for our project management purposes.
That’s helpful feedback. Image resizing isn’t supported yet, but it’s high on the list.
Do you usually resize to a particular value? (e.g. 50% or 75%)?
FWIW I’m most looking forward to the toolbar reflecting what the current writing style we are in.
E.g. if writing bold it would be really nice for the toolbar to reflect that with a highlight of the bold tool, same for italics. Obviously once you reach the end of that style, it would be great for the highlight to disappear
Most of the time resizing to 75% to make a screenshot look like …. well, a screenshot. When it is slightly reduced in size, then it kind of visually looks like an image embedded into a post because all elements in the image are smaller - it looks like something separate. Whereas if I leave it 100% size, it “blends” with the existing Discourse interface beacuse the UI elements in the image are roughly the same size as the UI elements of Discourse - and it looks ugly.
Finally, when it is a small piece of UI that I took a screenshot on a Retina screen and then embed it into a post, it looks gigantic, so I have to downsize is 50% or more.
At the end of the day, I try to make all screenshots that I insert look roughtly a bit sized down compared to the Discourse UI - then it looks very nice and is easy to read and comprehend as part of a longer text.
My two cents: I’ve been exploring Basecamp recently, and I find their composer to be one of the best WYSIWYG editors in terms of the balance between the richness of the editorial functions and easiness of use. For MOST cases, the only things that are missing are, hotkeys for all the things that one can do in the editor, and image resizing. My teammates who tried it actually love it.
For your reference:
It is difficult to explain what exactly is different. It just feels… more friendly and cozy to edit in, if I can say so. Also maybe less confusing. It is definitely less feature-rich compared to the Discourse one. But even though, taking into account the pre-wysiwyg era in Discourse, I’d prefer the Basecamp editor all day long. In case this is helpful, insightful and will let you think about it more.
Both of these are in progress. I don’t have ETAs on when they will be complete, but we’re working on it!
This feature is extremely important for our use cases (using Discourse as an alternative to Atlassian Confluence as an enterprise intranet). The WYSIWYG editor significantly lowers the barrier to participation, but a large portion of our content consists of structured documents—naturally with different heading levels. If all other necessary formatting options are easily accessible, but the central headings are not, this creates a problematic UX inconsistency.
I would therefore recommend a simple implementation as a dropdown button with H1 to H6. Ideally, it would also be possible to display the current “state”—for example, if the cursor is on an element with a heading, the button would show “H3” or similar. Consistently, this should also apply to other formatting options (bold, etc.). However, while this state display would be nice to have, the button itself is extremely important.
We’re starting work on this feature next week, @Ralf_Stockmann!
Thank you for your work.
“Captions” are mentioned as a known missing feature. Is it possible the new composer will support <figure> <figcaption>
in html output?
Is there a way to make this as the default composer for now?
AFAIK it’s still experimental, so I don’t think so.
However, it would remain at the mode that the user has used previously.