Inserting new content after tables don't work

[mr_lundis]

After inserting a table into the editing area it is impossible to create a new paragraph below it, without editing the html directly.

See this forum thread for more details.

[weswinham]

After some browser testing, it looks like Firefox has problems when the table is at the very beginning (can't create anything before it) and at the very end (can't created anything after). Internet Explorer has problems only when the table is the first element.

Fixed this in my branch with: http://github.com/winhamwr/wymeditor/commit/f3ada130b2611d2597a8f6415ac5e33231bafc33

[weswinham]

Updates to my fix for webkit browsers:

• http://github.com/winhamwr/wymeditor/commit/5007683b5b8e3552d5be8adedd859ba928454253
• http://github.com/winhamwr/wymeditor/commit/cea4d55453172429706bf77143ef5dba824dd395

[mr_lundis]

Regarding your fix, it looks nice - but it would be interesting if it could be modified to work with other kinds of block level elements as well. There are already some quirky solutions for blockquotes, as well as for some other elements. It would be nice if we could refactor all this code in to one unified fix. This would also make it easier to support div's, for those who need that...

[weswinham]

Two things:

Regarding expanding this to other kinds of block level elements, which other block elements exhibit the behavior that tables are showing? So far, I've only noticed tables having the problem with breaking editing before/after and between them. I guess maybe images might be the same though?

Regarding my fix, after more testing and thought, it's actually not very robust. It works well when you're creating the document, as it keeps the br's where they need to be. It totally falls down on subsequent edits though, because those extra br's are stripped out by the parser on the initial WYMeditor.editor.xhtml() call and we're back to square one.

What do you think about a post-processing hook on WYMeditor.editor.xhtml() that accounts for editor-specific work-arounds? So editor.xhtml() would still return the valid, cross-browser xhtml that we're interested in preserving, but it would under-handedly modify the actual HTML in the iframe body to correct any problems specific browser designMode (or later ContentEditable) implementations exhibit. This seems like a more general solution that would actually be useful in at least one more area I'm working on (fixing list indent/outdent behavior).

We'd basically be creating a 2-tiered system where we always return and allow editing on valid xhtml, but we give the browser what it needs to provide a good editing experience. For example, we could pepper _moz_dirty="" all over the place in the mozilla implementation, because added that attribute magically fixes all sorts of current warts when it comes to editing lists.

I'm going to take a shot at implementing this and see how it looks, and I'll see how well it can be extended to other block-level elements (just images to start since that's all I know) that need browser-specific html tweaks to allow editing.

[mr_lundis]

As I said in the comment above - there are already workarounds for inserting content after blockquotes and preformated text, but they don't apply very well on tables... Other problematic areas would be block content inside list elements and nested lists - really any kind of nested content.

Images aren't a problem though, as far as I know, at least when they remain inline (which they should) - placing images as block elements makes the editor wrap them in paragraphs at the moment.

In my opinion what this issue comes down to is to find a consistent way of handling enter key strokes. Like when you hit enter twice to leave a list and insert a new paragraph below (or whatever is appropriate) - this behavior should be consistent to the largest extent possible. And when that might not work (tables for example) an alternate solution is needed, like inserting a line break afterwards.

You could even extend the line break approach to always have one <br /> at the end of the content, making it possible to always insert new content, even below any blocking elements (not just tables.) I think this could also make a cleaner implementation...

However what you're suggesting would really need some kind of onChange/isDirty event to be really solid (planned for 2.0) but I'm looking forward so see what you'll come up with!

The idea to insert <br />s after/between "blocking elements" is really nice workaround by the way - I've never thought about that, and I've been thinking about this quite a lot. ;)

[mr_lundis]

Related to: #212 and #210.

[weswinham]

I've done some more work on my branch: http://github.com/winhamwr/wymeditor/commits/master

On thing to note is that I think #73 is basically the same issue here. blockquote, pre and table elements are a special kind of "blocking" element that you can't just hit enter to get past. I've got a general-ish solution I'm working on in the branch, and comments are definitely welcome. It's working surprisingly well in firefox right now, and I'm hitting safari (chrome) up next and then I'll be swinging around for ie6/7/8 support.