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. ~TJReceived on Friday, 21 February 2014 20:14:50 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:40 UTC