Hi Marius,
Allowing the user to edit the pasted content using a rich text area
before cleaning is not a good idea because the HTML
generated by these
Office suites can easily mess up the rich text area. The best option I
think would be to have a panel (div) that can catch paste events and set
the pasted content as its inner HTML.
Yes, this sounds like a good idea. But is it the div+onpaste event that we
should use or something like an iframe with designMode enabled ? (I think
latter is used in many hand crafted html editors) In any case, GWT doesn't
seem to have generic support for either of these, so we might have to worry
about cross-browser issues. Also, to let the user paste content into some
element (either div or an iframe), we somehow have to enable the designMode
(or something similar). So, this means the user will anyway be able to edit
the content after pasting it.
Btw, by moving the Import dialog box you loose the pasted content
because the in-line frame used by the rich text area
is detached during
dragging and a new document is created each time the in-line frame is
(re)attached. This is a dialog box bug anyway.
I'm wondering if this bug is enough reason for us to give up on the standard
GWT rich-text-area (no cross-browser issues). It's a terrible bug ofcourse,
but how many users will actually face it in day to day use ?
4. Ask the user. He may know better which Office suite he's using. Of
course, you need to provide also an option like
"Don't know" or "Others"
in which case you can apply one of the previous 3 solutions. Ideally, if
possible, you would use solution 2 to detect the Office suite but still
allowing the user to change it.
Cool. This apporach is more extensible I think. First we can start with a
generic exhuastive html cleaner and progressively introduce specific
cleaners when we feel the need (since we have the office suite information
provided by the user).
Or use a placeholder for local images with a tooltip explaining that
those images couldn't be uploaded.
+1.
Thanks.
- Asiri