id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
11186	A way to block upcasting given element to a widget	Piotrek Koszuliński		"TC: there's a plugin which prints out an image e.g. as a preview of something. If image2 is loaded, it will upcast that image, so DOM structure will be changed, what perhaps will create a conflict between image2 and theoretical plugin.

Theoretically, plugin can be rewritten to make use of widgets (because if it prints out something different than it is, it is a case for widgets). But in real life developers will need to make that plugin compatible with 4.3+ without so much effort, so an easy way to prevent upcasting on certain elements will be useful.

1. First option is an attribute, but it's not yet present in data (and in fact shouldn't be at all), so it would have to be added while loading data. That means during processing them, but upcasting is done before htmlDataProcessor#dataFilter is applied, so one would have to do an additional iteration over entire structure. Not good.

2. Then, we have the possibility to overwrite image2's upcast method. This solves the problem in quite clean way, but it's not perfect. Theoretical plugin has to know about image2 and still may be broken by other widgets about which it doesn't know.

3. Better than overwriting specific widget would be to block upcasting globally. So we may add mechanism like:

       {{{
       editor.widgets.addUpcastMethod( function( el ) { ... } );
       }}}

    Returning `false` would block upcasting on that element. Returning other values could modify upcasting in a different way, but I don't have a clear concept yet.

    Other possible method names: onUpcast, addUpcastCallback."	Bug	new	Normal		UI : Widgets	4.3