[whatwg] Styling form controls (Was: Re: Forms-related feedback)

[TJ VanToll]

> And Shadow-DOM doesn't let you style an existing control, just fully
> replace the rendering. So styling a textfield means doing a full
> editor with all the crappiness that contentEditable pulls in. Yes, a
> lot of the contentEditable stuff can and should be improved, so
> possibly this could be as simple as sticking a <span contenteditable
> plaintextonly=true> in there one day.

Chrome stable now supports replacing the shadow root of <input> elements, so you can see that this issue in action: http://jsfiddle.net/tj_vantoll/6qadQ/. You can indeed swap Chrome’s native picker with a custom one, but you lose most of the <input>’s functionality when you do so.

> Additionally, replacing the rendering rather than styling it is
> hostile towards new platforms. If everyone had used Shadow-DOM to
> build their own rendering for <select>s that would have made the
> transition to mobile much more painful since you'd get a tiny custom
> <select> UIs rather than a more platform-appropriate picker.

The datepicker is a perfect example of this. While developers frequently request the ability to use custom calendars, those same developers want to leave the native mechanism in place for mobile devices.

The datepicker also shows the problem that using pseudo-elements as styling hooks presents. The calendars presented on mobile browsers and desktop browsers are radically different. Even if you wanted to standardize certain hooks, there is literally nothing in common across the implementations.

Because of this, I don’t think there’s a good way to avoid making developers build their own controls. It’s unfortunate; I just don’t see a way around it. Therefore the main use case I believe needs to be addressed is allowing developers to build a datepicker/colorpicker/etc without reimplementing <input>.

One option that was brought up in #whatwg awhile ago was the ability to create custom form elements. Ideally you could build a <datepicker> that inherited the behavior of <input type=“date”>, but gave you the ability to override the way that the data is collected from the user. Perhaps it’s also possible to allow shadow roots of form elements to be replaced without losing the core functionality.

TJ