[xwiki-devs] [VOTE] Replace embed HTML elements with static image placeholder in WYSIWYG edit mode
Embed HTML elements pose some problems: * they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ). * they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice). * they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it. So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode. Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo . I'm +1. Thanks, Marius
Hi Marius, On Wed, Nov 4, 2009 at 2:20 PM, Marius Dumitru Florea < [email protected]> wrote:
Embed HTML elements pose some problems:
* they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ).
* they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice).
* they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it.
So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode.
Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo .
I'm +1.
Sounds good. It will also make the page easier to edit since it will be less heavy. Only question: where do we display text for that image? The information text we put with the image has to be easy to internationalize. Otherwise +1 too. Guillaume
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Guillaume, Guillaume Lerouge wrote:
Hi Marius,
On Wed, Nov 4, 2009 at 2:20 PM, Marius Dumitru Florea < [email protected]> wrote:
Embed HTML elements pose some problems:
* they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ).
* they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice).
* they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it.
So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode.
Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo .
I'm +1.
Sounds good. It will also make the page easier to edit since it will be less heavy.
Only question: where do we display text for that image? The information text we put with the image has to be easy to internationalize.
Indeed that's something to think about. One option is to use a generic icon that stands for "Embedded Object" in the center of the placeholder (which also has a border) and use a translatable text as the tool tip of the placeholder. WDYT? CKeditor uses an image that contains some text (e.g. "FLASH") but that's not i18n friendly. Marius
Otherwise +1 too.
Guillaume
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Wed, Nov 4, 2009 at 3:22 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Marius,
On Wed, Nov 4, 2009 at 2:20 PM, Marius Dumitru Florea < [email protected]> wrote:
Embed HTML elements pose some problems:
* they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ).
* they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice).
* they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it.
So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode.
Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo .
I'm +1.
Sounds good. It will also make the page easier to edit since it will be less heavy.
Only question: where do we display text for that image? The information text we put with the image has to be easy to internationalize.
Indeed that's something to think about. One option is to use a generic icon that stands for "Embedded Object" in the center of the placeholder (which also has a border) and use a translatable text as the tool tip of the placeholder. WDYT?
Maybe we could use a DIV + text in the DIV + the background-image CSS property so that the text can be internationalized easily yet is diaplayed above the image. WDYT? Guillaume CKeditor uses an image that contains some text (e.g. "FLASH") but that's
not i18n friendly.
Marius
Otherwise +1 too.
Guillaume
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Guillaume Lerouge wrote:
Hi,
On Wed, Nov 4, 2009 at 3:22 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Marius,
On Wed, Nov 4, 2009 at 2:20 PM, Marius Dumitru Florea < [email protected]> wrote:
Embed HTML elements pose some problems:
* they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ).
* they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice).
* they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it.
So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode.
Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo .
I'm +1.
Sounds good. It will also make the page easier to edit since it will be less heavy.
Only question: where do we display text for that image? The information text we put with the image has to be easy to internationalize. Indeed that's something to think about. One option is to use a generic icon that stands for "Embedded Object" in the center of the placeholder (which also has a border) and use a translatable text as the tool tip of the placeholder. WDYT?
Maybe we could use a DIV + text in the DIV + the background-image CSS property so that the text can be internationalized easily yet is diaplayed above the image.
But that text will be editable. Maybe not when the embedded object is generated by a macro, but the editor is not bound to the xwiki/2.0 syntax. It should work the same with HTML syntax or a syntax that allows you to write "video:URL". Making the DIV container read-only is unfortunately not straightforward at the moment because the contentEditable=false attribute is not well supported by the current browsers. Using an image placeholder is the simplest and quickest solution right now. Marius
WDYT?
Guillaume
CKeditor uses an image that contains some text (e.g. "FLASH") but that's
not i18n friendly.
Marius
Otherwise +1 too.
Guillaume
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Wed, Nov 4, 2009 at 4:14 PM, Marius Dumitru Florea < [email protected]> wrote:
Guillaume Lerouge wrote:
Hi,
On Wed, Nov 4, 2009 at 3:22 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
Guillaume Lerouge wrote:
Hi Marius,
On Wed, Nov 4, 2009 at 2:20 PM, Marius Dumitru Florea < [email protected]> wrote:
Embed HTML elements pose some problems:
* they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ).
* they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice).
* they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it.
So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode.
Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo .
I'm +1.
Sounds good. It will also make the page easier to edit since it will be less heavy.
Only question: where do we display text for that image? The information text we put with the image has to be easy to internationalize. Indeed that's something to think about. One option is to use a generic icon that stands for "Embedded Object" in the center of the placeholder (which also has a border) and use a translatable text as the tool tip of the placeholder. WDYT?
Maybe we could use a DIV + text in the DIV + the background-image CSS property so that the text can be internationalized easily yet is diaplayed above the image.
But that text will be editable. Maybe not when the embedded object is generated by a macro, but the editor is not bound to the xwiki/2.0 syntax. It should work the same with HTML syntax or a syntax that allows you to write "video:URL". Making the DIV container read-only is unfortunately not straightforward at the moment because the contentEditable=false attribute is not well supported by the current browsers. Using an image placeholder is the simplest and quickest solution right now.
Let's go with image + alt text until we find a better solution then. Guillaume
Marius
WDYT?
Guillaume
CKeditor uses an image that contains some text (e.g. "FLASH") but that's
not i18n friendly.
Marius
Otherwise +1 too.
Guillaume
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Wed, Nov 4, 2009 at 14:20, Marius Dumitru Florea <[email protected]> wrote:
Embed HTML elements pose some problems:
* they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ).
* they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice).
* they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it.
So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode.
Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo .
I'm +1.
+1, seems the strongest solution. Even if it worked well with embedded HTML it would be too heavy as Guillaume said.
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 On 11/4/09 2:20 PM, Marius Dumitru Florea wrote:
Embed HTML elements pose some problems:
* they are loaded asynchronously and any attempt to access even the simplest DOM property like nodeType through JavaScript raises an exception if the object is not fully loaded (closed to https://bugzilla.mozilla.org/show_bug.cgi?id=331672 ).
* they can't be fully controlled from JavaScript. The specific plugin that handles each of them decides the display and behavior (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=250855 a flash movie might auto start in edit mode and, unless you want to see a movie while editing, that's not nice).
* they aren't reloaded after they are detached and reattached to the DOM tree using JavaScript which means that any DOM manipulation involving one of the ancestors of a embed node can lead to the disappearance of the embedded object. Sadly, appendChild, insertBefore and replaceChild detach the target node before attaching it to the new location. As a consequence there's no way to move an embed node inside the DOM tree without detaching it.
So I propose we replace the embed HTML elements with static image placeholders just after the edited document finishes loading. The placeholder will have the same size as the embedded object in view mode.
Note, ckeditor already does this. You can check by copying the HTML from http://jira.xwiki.org/jira/browse/XWIKI-3975 to the source of http://ckeditor.com/demo .
I'm +1.
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Guillaume Lerouge -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne