Wedge

We have talked about it.

Thing is, there's already an editor that sort of does that built right into SMF (and thus Wedge)

Tell you what, though, there is one huge problem with using such an editor: security. Half of the security patches I've seen in WP in the last year are related to the editor. This is not a situation I really want to get into.

Yeah... To me, right now, the SMF editor is okay. It's not very good at importing data but really, most people wouldn't bother with that anyway. (I didn't even know if could be done.)

Totally off-topic but I can't bother to find the IE topic.
So, you know what I spent my day on...? IE6 compatibility :lol:
It's always a bitch... First you launch IE6 and notice something's broken and it's easy to fix. So you fix it. Then you're happy, but then you go to another page and something else's broken... Might as well fix it too. Only, it doesn't cooperate this time. And you end up wasting time rewriting the menu code to add an output buffer (!!) for IE6 and delete all whitespace, and then you notice that it'll only work on list tags that have no ul child... And there's no way to fix these... And then you say, why the hell did I waste my time on this shit to begin with?!

So I'm tempted (once again) to go back to the original version that sucked big time (adding vertical gaps between list items in the admin menu), and not bother. I don't know. Problem is, months ago it used to work (only 1-pixel vertical gap), now it's like 10 pixels... :-/

I believe it was Sartre that once said "Hell is other browsers"

To be honest, I can't believe you're still spending time on it. :o

Yeah, I know, it's stupid... Considering less than 3% of the Western world uses it and I have no interest in catering for Chinese and Korean users... (Not that I don't *like* them... But I don't see any reason to bother until someone provides us with Chinese or Korean language files, to begin with.)

I'm not going to bother MUCH longer, but for instance I *had* to deal with IE7 because it still has minimal market share. (> Opera, I have to admit...)

(Although it has to be said we only have country information for IE6... Given that IE7's share is less than IE6's, maybe IE7 is actually used more in Asia just like IE6.... Heck, I guess I should be checking out visitor stats for wedge.org. Excluding Baidu of course.)

OK, back over this topic.

WYSIWYG has a place. Me personally, I'd never use it, I find the entire idea so imprecise it's unreal (and please don't tell me time's an issue, I make quite literally hundreds of forum posts some days.)

And SMF does have a WYSIWYG editor. Now, if SMF's editor were replaced with another editor, that'd be a different story entirely, because it would have the security issues as mentioned but also the improved functionality of a WYSIWYG editor that wasn't retarded.

Here's an interesting point: we actually discussed a bit back about ditching bbcode and using purely WYSIWYG instead. That's almost more practical than you'd imagine in a lot of ways, it would save a great deal of trouble in terms of processing for a lot of posts, the only real objection I raised wasn't even the implementation of security, or the increased bandwidth use - no, the only objection I raised was in fact concerning usability.

One of the perks of bbcode is that you can introduce quick codes for all kinds of things. Representing a spoiler, or a footnote, in HTML is frustrating if done in a WYSIWYG fashion. However, most users that use WYSIWYG will not use these features.

So, perhaps, there's room for an alternative. For posts made with the WYSIWYG editor, save them with a flag to indicate they came from WYSIWYG. For all other posts, flag them as using bbcode, and render appropriately from the database.[1]

You'd have to be careful about switching between the two, since you would want to do that from time to time, but no more so than is currently being used.

1.	Security's not a concern in any practical fashion. If access is granted to be able to manually override this parameter, it's also going to be able to manipulate the raw data anyway so that raw HTML could be injected, negating the pre-parser sanitisation rules that are currently in place.

Have no clue what you're looking into doing... :-/

It was more speculative. Remember the discussion we had not that long ago about ditching bbcode entirely? The principle argument against doing it was because bbcode offers a highly convenient way to add new complex markup that wouldn't necessarily have an equivalent in HTML. Footnotes and spoilers are the main examples, as is quoting.

Now, the easy route to implementing a good editor is to apply the same process that SMF does: have the editor toggleable, but when toggling, do a conversion from HTML to bbcode for most of the HTML, and when going the other way, do only simple bbcode that has a direct HTML equivalent. quote bbc, for example, does not get converted when switching.

What I'm suggesting here is a more complex route that allows keeping bbc whilst getting most of the benefits of actually using a HTML editor.

For posts constructed entirely in a WYSIWYG editor, sanitise them on incoming and then proceed to save it in raw HTML, with a flag in the messages table to indicate that this is a raw HTML item. For these posts, we can safely avoid calling parse_bbc, thus giving us a speed increase.

For posts constructed using bbcode, or created in an environment where we've switched back and forth, we treat that as bbcode and do some decent conversion (better than is there currently).

My question: is that feasible? It sounds like it in my head, and it sounds like a more thorough approach than I'd originally planned to use (which was to drop the original editor, replace it with CKEditor and rewrite the html-to-bbc conversion routine to suit)

I'm not thrilled with not being able to switch back and forth. And how would we do amulets anyway?

Amulets are smileys. Amusing iPhone spellcheck.

I'm not suggesting we disable switching.

I'm saying we do switching but if the post was purely done in WYSIWYG, save it in WYSIWYG and bypass BBC parsing.

Oh, and make switching more reliable in the first place...

But why only save as HTML the wysiwyg posts?

Because they're already HTML.

Posts with bbcode likely cannot translate back and forth cleanly. E.g. Footnotes cannot be converted to/from HTML in any meaningful fashion.

Simple BBC like footnotes can be converted through a simpler function than parsebbc. Also if we can switch back and forth then wysiwyg posts are bound to have quote tags etc.

Footnotes are not simple BBC, not when you convert back from HTML. Quotes are a similar case. And quotes are not converted to/from WYSIWYG in any of the systems that have BBC and WYSIWYG.

I also don't think most people use quoting, so the bulk of posts in most forums will be fine. But a post in pure HTML, if we know it's pure HTML, we don't have to pass it through a parser... We don't have to do anything other than output it.