Arbitrary Customizer control input type support can cause unexpected output in custom controls

[celloexpressions]

I just realized that we might run into potentially significant issues with the fact that the base render_content() function in WP_Customize_Control now outputs stuff for any given type if a custom control subclass doesn't override the render_content() function.

This is likely to be the case for some custom controls that do all of their rendering in JS. But there may not be a great solution. My best idea is to create a whitelist of valid html5 input types to allow.

If we want to fix this it would be a 4.0.1 thing, otherwise we can wontfix I think.

The workaround is just to add:
public function render_content() {}
to the custom control class.

[nacin]

Not overriding a parent method to avoid rendering (if that's what you want) does seem like doing it wrong. I wouldn't mind seeing a patch here but if there's no real world breakage, I'm inclined to let this slide.

[celloexpressions]

29613.diff​ implements a whitelist of allowed types for the <input> element, to avoid rendering stuff in unexpected situations. It's way less elegant, but since there was a change in behavior here, something we should consider. I'm surprised WordPress.com didn't run into this, given some of the custom controls they have. The whitelist is based on the type attribute values listed here: ​http://www.w3.org/TR/html51/forms.html#the-input-element.

I don't know that I would want to change this after 4.0.1, as devs will start expecting/relying on the current way it works, especially in the context of potential future improvements like #29572.

[celloexpressions]

Still no reports of issues with this, so we should be fine without making any changes here. You need to override render_content() in subclasses, even if the function is empty and you're rendering in JS.