On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky <[email protected]> wrote:
> On 3/6/13 1:31 PM, Scott González wrote: > >> but we feel the pros of exposing internals outweigh the cons. >> > > When you say "exposing internals" here, which one of the following do you > mean: > > 1) Exposing internals always. > 2) Exposing internals by default, with a way to opt into not exposing. > 3) Not exposing internals by default, with a way to opt into exposing. > I was replying in the context of jQuery, in which we expose most internals always. There is no option to have jQuery hide it's internals. > And what do you feel the pros are of whichever one you're talking about > compared to the items after it on the list, just so we're on the same page? In terms of web components, I'm not sure I (or anyone else on the jQuery team) have too strong of an opinion on the default. However, I can say that I find it extremely annoying that I can't reach into the Shadow DOM for new input types and just kill everything. I want <input type="date"> to render as <input type="text"> because native HTML will likely never be as flexible as custom JS components. Obviously I'd prefer a standard, and web components are supposed to solve this. But in the meantime, we're provided with useful semantics and validation that go unused if you want the flexibility of a JS date picker. As someone building JS components, I see the benefit of having the internals exposed to me so I can do as I please. I also recognize the pain of maintaining code that reaches into internals. As someone who cares about the future of the web, I see the very real danger of this becoming widespread and ending up in the situation Boris wants us to avoid.
