Widgets feature

[Frederico Caldeira Knabben]

Widgets are represented by a group of elements that act as a single entity inside the editable content. The widget elements are many times protected from direct editing and can be configured to have different behavior, features or layout.

A good example for a widgets is a "captioned image", which contains an image element and text for the caption. Both parts will always live together and should be selected as a whole. Once deleted, both should be removed.

Some requirements:

• The widget must have a visual selection that clearly identifies it as selected as a whole.

• Widgets can be blocks or inlines.

• Support both framed and inline editing modes.

• The toolbar must properly react to the widget selection, disabling features that are not compatible with it.

• By default, the widget is not editable, so it's contents must be protected.

• I must be possible to have editable elements inside the widget, which will work with the editor toolbar.

• Inner editables may have different requirements in terms of acceptable elements and ENTER key.

• DEL and BACKSPACE to delete the widget.

• Other insertion keys should have no effect on the widget.

• It must be possible to select widgets with ARROW keys.

• It must be possible to blur from the widget with ARROW keys (left/right).

• Undo and Redo support.

• Copy and Paste support, even if only within editorS. (comment:4)

• Drag and Drop support, so the widget can be repositioned or moved among editorS. (comment:4)

• Accessibility.

• Easy API for plugins implementation. (status: 60%)

[Frederico Caldeira Knabben]

Pushed the first prototype to ​t/9764@cksource.

The current version is still very limited. It is based on our research to understand the feasibility of such feature and also to propose a few UX models to be discussed. It is mainly a feedback ready version. Implemented features have been crossed out in the ticket description.

So far, excluding the non implemented restrictions, it works well with Chrome... almost well with Firefox... maybe ok with Opera... WTF with IE9. So, test it with Chrome for now.

[Dinu]

This is huge! I'm a kid who got his first bycicle :)

I was thinking about the copy&paste, drag&drop features and the following came to my mind: There can be stateful widgets that don't like to be dragged across editors. Presumably in the end the widgets will be implemented as plugins, that will generate, be able to edit & shape non-editable content via a properties dialog etc. Since different editors may have different lists of plugins loaded by configuration, it would make no sense moving a widget to an editor that does not support it. So, to further the already ambitious checklist, I think such a mechanism should be implemented that:

• a widget can have a bit of metadata, say "widgetClass" that says the widget is an instance of a "captionedPicture"
• a hookable API callback (or some other form of appropriate event handling) that can process any cross-editor operation, such as safely serializing the widget for transport (copy), safely deserializing the widget (paste)

I don't know how to formulate this in a single sentence that can be added to the checklist :)

[Frederico Caldeira Knabben]

Replying to dinu:

Interesting aspect. Let's see what can be done in that sense once we have the copy/paste and DnD thing researched. I've added a notice in the list.