Change WYSIWYM to WYMIWYG

[wymmy]

To me, saying WYSIWYM is ultimately no different than WYSIWYG other than a single letter change. The development of WYMEditor seems to be generally headed in the direction of WYSIWYG - making this no better than TinyMCE. I'd rather see the editor take the direction it originally started in where "What You Mean" to do reigns supreme.

IMO, block-level elements are generally broken in every browser's idea of 'designmode'. The 'p' tag within WYMEditor, however, seems VERY stable across browsers. So, in theory, it should be possible to use the 'p' tag for every block-level element and then just apply visual styles based on classes. It should be possible to use jQuery to parse the data while it is being pulled for block-level transformations (e.g. a 'p' tag with a 'h1' class becomes a 'h1' tag in the output) and to transform tags as they are going into the editor (e.g. a 'h1' tag becomes a 'p' tag with a 'h1' class). This approach would allow you to eliminate all block-level elements except the stable 'p' tag and the result would be a very stable editor that is focused on What You Mean instead of What You See.

[mr_lundis]

I'd say WYSIWYM and WYMeditor is still fairly different than TinyMCE and most other WYSIWYG. Both CKeditor and TinyMCE have improved a lot since this project started out in regards to standards and the quality of the generated code. It's possible to use these editors - if you configure them correctly - to generate fairly good markup. But these editors are rather heavy, and do not encourage the user to write more semantic content.

To improve cross-browser consistency and stability is always something we strive for, but I'm not sure I understand how changing all block elements to paragraphs would improve the WYSIWYM part? I think the area that needs most work right now in regards to the "meaning part" would be better support for inline elements, RDFa, microformats, and so on.

The main reason people want to use other block level elements (like divs) is to embed different types of content. In 0.6 we'll address this by creating a placeholder system which will make it really easy to embed new content (like hCards, forms or videos) without risking messing up the rest of the editor content.

Another reason people want to use divs are to enable columns - this will also be easier in 0.6 since the editor and the UI will be (as good as) completely decoupled, making things like one toolbar for several editor instances possible. This decoupling would in other words make it easier to have one instance per column without cluttering the page with unnecessary UI components (also very useful for inline editing.)

In my book these are all very welcome improvements - but I don't really see how they decrease the editor's focus on semantics. I'd like to think the other way around - that these improvements will make it easier to focus more on the content instead of the presentation.

And for closing: better block level element support is still needed for allowing content other than text inside list elements for example. But that's not to say that better block level element support will take WYMeditor down in the dark hole of divitis.

I hope I managed to clear things up for you - but I might have gotten you totally wrong.
If you think so, could you please try to explain to me why you think WYMeditor is no better than TinyMCE?

Anyways, cheers!