[RFC] WYSIWYG editor

[bobtheman]

This thread will be for the collaboration and creation of the wysiwyg RFC. After its completed we will copy it over to the wiki. All constructive criticism is welcome especially when its working towards a finished product.

Objectives
1. Usability. More friendly, appealing, ease of use, ability to extend
2. Performance. Comparable page loads than older bb editors
3, Security. Ability to pass security audit, no sacrifice of security

Purposed WYSIWYG editors for inclusion
The editor must be in compliance with phpbb license requirements
1. TinyMCE http://tinymce.moxiecode.com
2. New WYSIWYG editor created by phpbb team

Default Included functions
Bold, Italics, url, Save, Text Color, Remove Formating, Spell Checker, Preview, align, anchor, font size, font family, insert image, quote,

Emotions - This could replace the current smilie insert system.

[naderman]

This thread will be for the collaboration and creation of the wysiwyg RFC. After its completed we will copy it over to the wiki.

Would you mind creating the rfc page on the wiki already and putting a link to this topic in it. You can list it under "draft".

[bobtheman]

I would love to, but i have never been successful with logging into the wiki. I have created accounts on the area51, support forums, and created a new account from the wiki itself and still no luck. It wont let me log in.

[Kellanved]

I would push this very far back. The inclusion of an actual editor is javascript development not inherently linked to the core.
There is one aspect that needs attention:
How can custom bbcodes be designed so that an eventual editor can support them.

All other questions, especially which editor to use, can be postponed until the core features are done. Surveying the current situation, it seems to me that tinyMCE is too hardwired for HTML, any bbcode support takes the shape of a hack. CKeditor looks more promising, but implementing an extensible bbcode parser and writer would take serious effort.

[bobtheman]

I would push this very far back. The inclusion of an actual editor is javascript development not inherently linked to the core.
There is one aspect that needs attention:
How can custom bbcodes be designed so that an eventual editor can support them.

All other questions, especially which editor to use, can be postponed until the core features are done. Surveying the current situation, it seems to me that tinyMCE is too hardwired for HTML, any bbcode support takes the shape of a hack. CKeditor looks more promising, but implementing an extensible bbcode parser and writer would take serious effort.

Can we discuss the necessity of a bbcode parser, the possibility of moving away from the bbcode parser and using an alternative like a properly written html filtering system which is just as safe as the bbcode parser and could be safer security wise.

[Kellanved]

Frankly, I have yet to see such a thing as a "secure HTML parser". It simply doesn't exist, which is the very nature of HTML. Even worse, it would still be bbcode, but masquerading as HTML. Consider that style classes etc have to be added to the entered HTML, url re-writing has to be done, permissions have to be checked. BBcode can use '<' instead of '[', but that doesn't change the nature of the beast. Moreover, remember that people have to be able to post without the editor, using plain text.

Nonetheless, supporting bbcode does not mean that bbcode has to be the only means of entering formatting.

[bobtheman]

Frankly, I have yet to see such a thing as a "secure HTML parser". It simply doesn't exist, which is the very nature of HTML. Even worse, it would still be bbcode, but masquerading as HTML. Consider that style classes etc have to be added to the entered HTML, url re-writing has to be done, permissions have to be checked. BBcode can use '<' instead of '[', but that doesn't change the nature of the beast. Moreover, remember that people have to be able to post without the editor, using plain text.

Nonetheless, supporting bbcode does not mean that bbcode has to be the only means of entering formatting.

thanks for clearing that up.

[Highway of Life]

Frankly, I have yet to see such a thing as a "secure HTML parser". It simply doesn't exist, which is the very nature of HTML.

This piqued my curiosity.

If you had an HTML parser that:

1. Doesn’t allow the no-no HTML tags such as: script and style. (iframe isn't usable under rule #2)
2. Doesn’t allow any attributes.

What would be an example following those rules where you could exploit that HTML parser?

[Rotsblok]

Frankly, I have yet to see such a thing as a "secure HTML parser". It simply doesn't exist, which is the very nature of HTML.

This piqued my curiosity.

If you had an HTML parser that:

1. Doesn’t allow the no-no HTML tags such as: script and style. (iframe isn't usable under rule #2)
2. Doesn’t allow any attributes.

What would be an example following those rules where you could exploit that HTML parser?

Hummm I guess you don't mean these things http://www.w3schools.com/HTML/html_attributes.asp otherwise it may be a bit hard to do stuff.. Or do you only want to allow tags like: b, i, ul, ol, li, strong, span (but i think that will be of little use), code, sub, sup. In essence ony these tags http://www.w3schools.com/HTML/html_formatting.asp ? I think you will have some hard times then to have a bit more format in your text.. For example alignment, text colouring, would be a bit difficult since most ppl want have valid html code..

I think parsing for things on a black list (hardcoded) to remove tags like <script><style><iframe> and attributes like onclick, onmouseover, onmouseout, etc would be better if you go to allow html tags.. Although I do not know what that takes...

[Highway of Life]

No, I’m not trying to make an HTML parser or discussing the usefulness of such a parser with those rules, I’m specifically addressing the question of if a “Secure” HTML parser - Kellanved said that such a parser doesn’t exist, so I’m curious based on the rules I stated above how you would exploit such an HTML parser.