Re: [shadow-styling] Named parts, styling built-in form controls, and shadow styling (was Re: Goals for Shadow DOM review)

On Fri, Feb 21, 2014 at 11:19 AM, Edward O'Connor <eoconnor@apple.com> wrote:
> Domenic wrote:
>> However, what I was initially wondering was: can we just use existing
>> shadow DOM constructs? E.g. could you style the slider with
>>   input[type="range"] /shadow/ .slider-thumb
>> ?
>
> I think we want to end up in a world where existing engine features *can
> be explained* by platform features, but *are not necessarily implemented
> with* platform features. Using /shadow/ to expose pieces of native form
> controls feels like we're promising too much to authors, e.g. what if
> the slider thumb isn't an Element?
>
> In a world with Named Parts and a Shadow DOM capable of defining them,
> input[type=range]::part(slider-thumb) levels the playing field between
> authors and implementors without overcontsraining implementations.

I agree strongly that we don't want to use /shadow/ to explain
existing inputs/etc.  Their internal structure is magic and undefined,
and even though we want to *somewhat* define it, exposing more than a
bare minimum is unsafe and prevents us from experimenting with new
ways of presenting them.  (If that had happened before we got current
smartphones, we'd have been unable to give <select>, for example, an
actually usable UI on mobile phones.)

Explaining inputs via Shadow DOM *was* originally a goal, but we
realized pretty quickly that it was impossible without making a lot of
weird choices that don't make nearly as much sense for author-designed
components.  It might happen some day, but it'll require new features
beyond what Shadow DOM is currently planning on.

~TJ