> 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


Reply via email to