CKEditor should expose the names/ids of dialog windows, tabs and fields

[Anna Tomanek]

These values are crucial for all sorts of customizations and it is vital that we make them accessible to developers. By accessible I don't mean having to search for them somewhere inside the millions of lines of CKEditor source code.

This information must be available in the API docs and auto-updated on all changes of the dialog window source codes.

Please note this is also one of the most asked for problem areas on our forum.

[Wiktor Walc]

When CKEditor is running source mode we could add an extra attribute to each UI element in the dialog, which would hold the real path to the element: "tabId:elementId".

This way, when using the inspector in Firebug on the URL field of the Image dialog, instead of the following:

<input type="text" aria-required="true" aria-labelledby="cke_346_label" id="cke_345_textInput" class="cke_dialog_ui_input_text">

one would see also:

"info:txtUrl"

In release version this extra information could be hidden, to avoid performance issues.

[Frederico Caldeira Knabben]

What about a plugin that shows tooltips when rolling-over the dialog elements?

[Sa'ar Zac Elias]

Considering that this information is to be viewed by developers, I don't think that adding attribute or a tooltip plugin is the right way to go.
I tend to agree with Anna more here, we can develop a tool that creates a list of dialog, tab and field names into a special document that is to be distributed or put online.
If we go "old fashion", we can even do that manually as changes in dialog names/tab names/field names is rather rare.

[Frederico Caldeira Knabben]

I meant a developer plugin in fact, which must be enable by hand, just like the uicolor plugin. It could also include other information, like the element type. It'll be definitely usable... it's enough to open the dialog and have everything there, including custom fields, which would not be documented by us.

[Wiktor Walc]

A tooltip plugin sounds like a way to go.

The problem with having it described in the documentation is that:

1. Some dialogs contain lot of elements, so the list of elements for the Link dialog would be long, how could you design it so that it was easy to find the element you're looking for?
2. Dialogs added by thirdparty plugins will still not be documented
3. Such a tooltip plugin could show even much more information in the future, like the current definition of this element etc.

[Sa'ar Zac Elias]

Ok, I see your points, I'm ok with that.

[Anna Tomanek]

Sounds great to me, too, and I am sure this tool will really help the developers get up to speed with customizing CKEditor. As stated above, it can also be extended to cover other functionalities dedicated to CKEditor developers so I am all for that.

[Anna Tomanek]

Great job, Saar, I really like it.

One problem I see is that the tooltips seem to interfere with the input fields that they cover:

• If you click the text field inside the tooltip and try to write something, the characters are not entered.
  
• If you click the text field outside the tooltip, the characters are entered, but the tooltip covers them so it's not immediately clear whether filling the field works or not.

Perhaps the click event on the field should cause the tooltip to hide and uncover the field?

Would it make any sense to also show the ids of the dialog window buttons? I can see the "Clear" button from the color picker has a tooltip, for example, while in the Selection Field dialog window the "Down" button has one (albeit with "undefined" id) and the rest of them don't. Is removing the buttons a valid use case for CKEditor developers?

[Sa'ar Zac Elias]

New patch covers everything me and Anna have discussed about, including:

• Some buttons didn't have tooltips.
• Tooltips for tab names as well.
• Positioning of the tooltip now doesn't interupt editing.
• Added padding for text.

[Wiktor Walc]

• Is it possible to display the tooltip straight below the element? When viewing the Link dialog, the tooltip for the URL field looks a bit bad on the right side.
• How about using something like:

  <div tabindex="-1" id="cke_tooltip" style="z-index: 10020; top: 513.5px; left: 681px; display: block; padding: 5px; opacity: 1; border: 2px solid #333;">
  <h2 style="font-size: 1.1em; border-bottom: 1px solid; margin: 0; padding: 0 5px 5px 0;">Element information</h2>
  <ul style="padding: 0pt; list-style-type: none;">
  <li><strong>Dialog name:</strong> link<br></li>
  <li><strong>Tab id:</strong> info</li>
  <li><strong>Element id:</strong> url</li>
  <li><strong>Element type:</strong> <a style="color:white" href="http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.dialog.definition.textInput.html" target="_blank">text</a></li>
  </ul>
  </div>
  

to display the tooltip? I'd format a bit the tooltip box and add an extra information: the type of the element with a direct link to the documentation about it.

• When element ID is undefined, I'd display something like "not set".
• In the second patch lang/en.js is missing.
• Do we really need to add CSS rules to _source/skins/xyz/dialog.css? I'd say that plugins should be totally separated from the editor.
• The scaytcheck dialog is broken when this plugin is enabled:

  el is null
  el.on( 'mouseover', function(), line 100
  

[Sa'ar Zac Elias]

Putting <not set> instead of a missing ID is not relevant, as the whole dialog system relies on the element IDs, and the plugin will silently fail without them (the cause of the last bug described by Anna in comment:11). We should make suere we got IDs all across our core dialog. The patch handles the ones Wiktor and I found.
Besides that, everything we've discussed about and an additional minor bug fix are included in the 3rd patch.

[Anna Tomanek]

I really love the current version, from the user's perspective, that is. This is even better than I initially thought we can come up with -- great job, Saar. I am sure this will become an invaluable tool for the CKEditor developers. R+ from me.

[Frederico Caldeira Knabben]

Nothing to add. Nice job!

Please just remove the "dialog" require. This tool should not change the editor. So it should not load the dialog plugin if no other plugin is loading it.

[Alfonso Martínez de Lizarrondo]

There's something very obvious missing in the patch, and it's a sample page with the plugin so people can use it easily, as well as allowing us to use it at any time in the rev. site.

I would suggest to apply the approved patch and then add a simple test page (another extra plugin with missing sample is the tableresize)

[Anna Tomanek]

Good catch, Alfonso. Attached is my proposal (devtools.html sample) and a modified index.html file from the _samples folder.

[Anna Tomanek]

devtools sample

[Anna Tomanek]

index.html file for the _samples folder

[Sa'ar Zac Elias]

HOW DID WE NOT THINK OF THAT?! ;)
Thanks Alfonso, Anna.
Fixed with [6679].

[Sa'ar Zac Elias]

Oops, committed on trunk.
Reverted with [6680] and fixed again on the branch with [6681].