Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

I agree with Tab 100% on this.

You cannot accidentally stumble into ShadowDOM. You have to actively take
that step.

For one thing, I suggest that most of the time, the component code is
shipping w/your application, you are not depending on some resource that
will simply be upgraded out from under you.

For another thing, if I decide it's necessary to monkey-patch some
third-party code that's I'm using in my application, I'm generally pretty
upset if that code is privatized. It makes that unpleasant work much
harder. I need to ship ASAP, and maintenance concerns are secondary.

Either way the last thing I'm going to do is wily-nily update that code and
then blame the developer that my monkey-patch broke. Yes, someone could
complain in that scenario, but they have no leg to stand on.

Boris says the above has been a big problem at Mozilla. This confuses me.
Do developer's not know that monkey-patching clearly private code is bad
for their maintenance? I don't see how this can be the library vendor's
problem (unless maybe it's an auto-update situation).

I suppose there is a moral hazard argument: if we make it possible, people
will overdo it. This is probably true, but IMO it's akin to saying chefs
should only use butter knives because they could cut themselves on the
sharp kind.

Lastly, only a subset of possible upgrades actually are transparent, not
affecting public API or behavior. Intersect that set of updates with
monkey-patchers who can't live without the update, and you are talking
about a relatively small affected class.

Scott


On Mon, Feb 25, 2013 at 9:54 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/25/13 12:38 PM, Tab Atkins Jr. wrote:
>
>> Still, though, the "private by default" impulse is nearly always
>> wrong
>>
>
> That's an interesting claim.  Do you think that C++ classes should be
> public by default?  (Binary patching that can mess even with private
> members notwithstanding for now)
>
>
>  and contrary to a lot of patterns on the web
>>
>
> This is at least partly a historical artifact of two things:
>
> 1)  The web was not originally designed for serious application
> development.
>
> 2)  There is no way to do private by default right now, really.  There are
> some things you can try to do with closures and whatnot, but the shared
> global makes even those not exactly private.
>
>
>  the current status quo, where shadow DOM is hidden from everything
>> unless you're explicitly looking for it, is necessary for *lots* of
>> useful and completely benign things.
>>
>
> I think we may have different definitions of "benign"...
>
>
>  If you want high integrity (not security - this is a much broader
>> concept), it's expensive.  This is always true, because low-integrity
>> things are *useful*, and people often try to reach for high-integrity
>> without thinking through its downsides.
>>
>
> I can assure you that I have thought through the downsides of
> high-integrity and low-integrity components, both.  Furthermore, we at
> Mozilla have a .... lot of implementation experience with the low-integrity
> version.  It's been a constant battle against people monkeypatching things
> in ways that totally fail if you change the implementation at all, and I'm
> not sure why we should impose such a battle on component developers by
> default.
>
> -Boris
>
>