Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky <bzbarsky@mit.edu> 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.