Continuing the discussion from Who would prefer a standard wysiwyg to markdown?:
I checked with the founders and they are ok with us restarting this thread with a view to discussing the development of a plugin to deliver some form of WYSIWYG post editing in Discourse.
Bearing in mind @sam’s & @codinghorror’s previous comments that the core team would not consider undertaking such development for the foreseeable future, what remains is the opportunity for the rest of us to get together and produce the plugin ourselves.
That’s assuming that there is enough genuine interest in which to make this project viable.
Assuming there is, how we go about this would be our next consideration. Do we have the required skill sets and sufficient time to make it happen? - or if not, are we prepared to form a small cooperative in which to raise the necessary funds to make it possible?
Sam has already pointed out that this is not an easy task - so let’s not fool ourselves that this a 2 or 3 week project - with obvious ramifications on our time and potentially our pockets.
But if we keep our objectives modest, at least to begin with, then I think we stand a chance of delivering something which would, in my view at least, greatly benefit the wider Discourse community. And of course, given it’s an optional plugin, we’d hopefully avoid discussions relating to bloatware, bandwidth and server requirements that seem to thwart many initiatives of this type.
Before passing this over to the community to discuss, here’s a few of my thoughts that have been developing over the past few weeks.
1 - How much can we achieve by enhancing the existing setup? By that I mean building on top of the existing UI, perhaps with a slightly better editing experience - but importantly, keeping Markdown as the formatting language. I’m deterred from this approach because if any low hanging fruit existed in this area, the founders would probably have added it one quiet weekend. But we should explore this in case we can apply the 80/20 rule and get a reasonably big hit for not a huge amount of effort.
2 - If the above (1) is not viable and, or desirable, the worry is once we step outside of Markdown (which Sam alluded to below), the impact on other areas of the code base would be significant. But that shouldn’t deter us, because if we believe WYSIWIG editing is worth the effort, then we need to find the path of least resistance whilst still achieving our objectives. And besides, there may be an alternative way of thinking (see 3).
3 - I probably should have started with this, but what we mean by WYSIWYG is key. I see it as an enhanced editing experience allowing complex HTML structures to be created. I don’t see it as simply allowing the user to select bold more easily. If it were, we’d take the route described in scenario 1 above.
The Barcelona & Tenerife post below is an example of what I mean.
This is taken from a prototype that I developed a few days back and it’s saved away on the server and renders exactly as you see it above - although I cheated by HTML encoding the HTML and enclosing it in an
<a ...></a> wrapper, which was then decoded during the post view render event below - note the following supports multiple encoded wrappers,.
$(this.element).find('.cooked a[href="#decode"]').each(function (index, element) {
var encoded= element.innerHTML;
var decoded = $("<div/>").html(encoded).text();
$(element).replaceWith(decoded);
});
It works very well, but it’s a hack and not very Discourse like - although something similar could? be considered.
In case you were wondering, there was no editor involved above - I see that as the simpler bit. For this example I simply copied source HTML from a WYSIWIG editor, HTML encoded it, wrapped with an a tag and pasted it into the post, before saving. Note, that I did manage to leave the existing post contents (shown in red) untouched because only the escaped (a tag wrapped) components were pre and post processed - the rest was left as was. It also quotes very nicely because the HTML in the quoted text is removed during the strip and bake process.
4 - I think the above is overkill for comments, but I would like to see something like the above post made available when creating topics, either limited to specific categories and or against specific trust levels. This also implies that comment creation and editing would not typically be provided with this full fat solution.
Some other issues to consider, but perhaps to be picked up and added to by the community:
5 - What editor?
6 - How is the HTML saved away. Raw? encoded as above …? or?
7 - How are these posts rendered in search, emails and other activity summaries?
8 - What other considerations are there for the rest of the system?
10 - How do we handle images?
And so on.
Over to you. Is there interest and if so, how do we go about it?
Ps. Please bear with me on this, I am fairly new to the platform which I believe to be the best available. Bar none. So please do tread lightly with me if I’ve misunderstood one or more aspects of the system and how they work.
A limited range of rich formatting is perfectly acceptable - in fact, the ones shown in the toolbar above as I type this is perfectly acceptable. I’ve just tried the numbered list icon by the way - very unfriendly IMO. Do you have to number the list yourself?