I would like to point out that the theming API isn't going to serve our needs very well. For instance, people do not draw scrollbars the same way, on mobile devices for instance it is common to draw scroll indicators and not really scrollbars, who fade in and fade out.
It would be best for the browser to draw these parts if possible, using some kind of negotiation. It would be possible for the plugin to request a widget and a size. Then the browser could tell the plugin what it can draw. For instance the plugin might want a very small button, but the browser cannot paint such one because the native button cannot, thus it gives back to the plugin what if you do together with a pixmap. This is more of less how WebKit deals with HTML forms theming today, and I guess Mozilla does something similar.
Doing it this way, the browser could take the CSS into account as well, which would be the right thing to do.
Only handling specific "modes"
It would be good if the current plugin initialisation code could check what modes the plugin wants to handle. Currently, it's impossible for a plugin not to handle NP_FULL mode when NP_EMBED is supported. See Mozilla bug and WebKit bug. (BastienNocera 16:38, 8 April 2010 (UTC))