PHPBB3-10418 - WYSIWYG Editor/Rich Text Editor

[MattF]

Every time I use a WYSIWYG, which honestly is only in Wordpress, I always find myself having to go into the raw/html mode to fix what the WYSIWYG gets wrong. I actually find them more difficult to work with than not having them at all.

I would definitely want to be able to turn it off if it were added to phpBB, just as a user option/preference.

I find it kinda ironic too that this topic is 35 pages of WYSIWYG discussion, yet not a single post warrants the need for WYSIWYG - they're all just quotes and plain text

[brunoais]

In my plans, you have an UCP option to select the default mode you want the editor to be in. You may select the default mode to be source mode.
While in source mode, you have, mostly, the same experience as with the current phpBB's editor although with a slightly different interface.

Anyway, I agree. Not much of BBCode was used around here. Still, it may just be because we are a more technical kind of people.

Additionally, I invite the styles team to tweak SCE's CSS so that the buttons borders and toolbar look best to fit prosilver. There's still no ETA for competition as I'm finding new challenges with this every day. I can only say it seems to be nearly ready.

[lisawdegregorio]

I think it should probably be better integrated with phpBB if its to be included in the core.

[tct]

I can only say it seems to be nearly ready.

i like

[brunoais]

Someone please tell the styles team I'll need help with the design to make SCE look the best way they can think of with prosilver.

[brunoais]

User functionality help wanted!
The WYSIWYG has a big limitation. It is hard to decide how and where to end a BBCode tag that allows having itself inside.
E.g:
Tags such as b and i do not allow themselves as child of themselves, so knowing if, by pressing the button, the formatting should be added or removed is trivial.
On the other hand,
Tags such as [ quote] and [ list] allow stacking inside their own, so pressing the command button is ambiguous if the user means to stack more, for example, [ quote] tags instead of breaking it at that point.

I need suggestions on solutions to this problem.
IMO, the best way appears to be by detecting the Shift key while the button is pressed. Doing Shift+click forces the removal of 1 level of that specific tag's at cursor selection.

If I was not clear, think this example below.
Assume you have this quote:

top text
below text

Place the mouse after "top text" and press the quote button while keeping the Shift key pressed. That transforms the quote into:

top text

|

below text

If you select "below" while doing the combo, however, the result is:

top text

below

text

Is it a good idea? Do you have any alternatives that work for any block BBCode?
Regardless if it, though, there can be custom solutions for specific BBCode.

[JoshyPHP]

Tags such as b and i do not allow themselves as child of themselves

I don't know if it's relevant to WYSIWYG but in 3.2 b can be used inside of b. Same thing with i, u, etc...

IMO, the best way appears to be by detecting the Shift key while the button is pressed.

Even if we ignore mobile users for a moment, I don't think many desktop users will try pressing Shift while clicking things with the mouse.

You should look into how other editors work. I know that WoltLab's Burning Board has WYSIWYG quotes but I don't remember how their editor works.

[brunoais]

IP.B uses the double Enter (although it is buggy).
vBulletin uses an RTE and it doesn't process the [ quote]
MyBB has a dead topic on that.
SMF does not support it.
WoltLab's Burning Board doesn't seem to support this, I can't find any information onto how to work with it.

(more information maybe later)

Tags such as b and i do not allow themselves as child of themselves

I don't know if it's relevant to WYSIWYG but in 3.2 b can be used inside of b. Same thing with i, u, etc...

Yeah... I checked and they really allow themselves inside each other like that... I'll have to find someway else to define when a button is considered a toggled functionality...

IMO, the best way appears to be by detecting the Shift key while the button is pressed.

Even if we ignore mobile users for a moment, I don't think many desktop users will try pressing Shift while clicking things with the mouse.

So... Mobile users do not have modification keys? I thought there were finger movements to replicate them...

You should look into how other editors work. I know that WoltLab's Burning Board has WYSIWYG quotes but I don't remember how their editor works.

I can't find anything on it. I think that's just as good as implementing the Shift key way except it is useful for the people who know it.

[Nicofuma]

Tags such as b and i do not allow themselves as child of themselves

I don't know if it's relevant to WYSIWYG but in 3.2 b can be used inside of b. Same thing with i, u, etc...

Yeah... I checked and they really allow themselves inside each other like that... I'll have to find someway else to define when a button is considered a toggled functionality...

I don't think we care here. It's allowed because it's valid in HTML but it's not logical. In the WYSIWYG editor you should consider the logic and not the possibilities. If you wan't to do things more advanced, use the plain text editor.

[brunoais]

Tags such as b and i do not allow themselves as child of themselves

I don't know if it's relevant to WYSIWYG but in 3.2 b can be used inside of b. Same thing with i, u, etc...

Yeah... I checked and they really allow themselves inside each other like that... I'll have to find someway else to define when a button is considered a toggled functionality...

I don't think we care here. It's allowed because it's valid in HTML but it's not logical. In the WYSIWYG editor you should consider the logic and not the possibilities. If you wan't to do things more advanced, use the plain text editor.

I think I can do as a rule for inline-level BBCode. It seems to be valid for all of them.
Question, then:
Where do I get the logic of a BBCode if not hardcoded somewhere?
I really want to have something as forward-compatible as I can think .
Considering that... I think I'll just leave to the implementation of the Shift override in a subsequent version which may or may not be in the 3.2.0 release. As for the inline BBCode, I'll keep the override logic I've been developing and allow overriding default values somehow at tag creation in a toggleable menu in the ACP. In my simple tests, the unset of the bold, italic and underline are working as expected (I only made simple tests, though)
Sounds good?