Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

>>>>  Can we go with options when creating Shadow dom?

>> My understanding is that we have this option and are only talking about
what would be the default.

Bronislav correctly pointed out to me that this is a fact not in evidence.
We have discussed 'isolate' option, but it's not in any spec that we can
find (yet).


On Mon, Feb 25, 2013 at 10:52 AM, Scott Miles <sjmiles@google.com> wrote:

> Don't we have a situation where people can simply take your source and
> change it regardless (barring legal imperatives, which are orthogonal in my
> view)?
>
> Given Boris' arguments, Big Marketshare can simply always mess up his
> project and blame me and it's my fault. I don't accept it.
>
> Btw, If Big Marketshare is so powerful, why haven't we already fixed
> whatever thing he is monkey patching?
>
> Also, Optimizely, et al, doesn't simply appear at random. Again, seems
> like your argument is that some developer or user may take wanton stet X to
> break my stuff, and I must prevent it or it's my fault.
>
> re: "forced depend on where they got their tomatoes from" and "You cannot
> accidentally stumble into ShadowDOM"
>
> The reason the latter keeps being mentioned is because of statements like
> the former. Nobody is forcing anybody to break encapsulation. Seems to me
> the demarcation is very clear.
>
>
> >> And all I have to do is to check the points whee my app touches the
> controls
>
> Yes, transparent upgrades are great. No argument here. But If you had
> monkey-patched your libraries, you wouldn't have this ability. You didn't,
> so life is good.
>
> >>  Can we go with options when creating Shadow dom?
>
> My understanding is that we have this option and are only talking about
> what would be the default.
>
> Lastly, my point about upgrade statistics is only that the intersection of
> the two sets is generally going to be smaller than the union of them. I
> should not have qualified that difference. To be clear, the intersection I
> posed included "monkey-patchers that require the update", not simply
> "monkey-patchers".
>
>
>
> On Mon, Feb 25, 2013 at 10:37 AM, Bronislav Klučka <
> Bronislav.Klucka@bauglir.com> wrote:
>
>>
>> On 25.2.2013 19:15, Scott Miles wrote:
>>
>>> I agree with Tab 100% on this.
>>>
>>> You cannot accidentally stumble into ShadowDOM. You have to actively
>>> take that step.
>>>
>> Sure, someone can actively take step to access my shadow DOM, thou I
>> explicitly made it shadow and in next version of the control things will
>> break.
>>
>>
>>
>>> 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.
>>>
>> Sure, but as a desktop programmer I cannot tell how many times over the
>> last decade I have upgraded my applications including 3rd party controls...
>> And all I have to do is to check the points whee my app touches the
>> controls... Not caring about the rest, because the rest cannot be broken
>> (well, can, under extreme circumstances)
>>
>>
>>
>>> 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.
>>>
>> Assuming of course you can legally do that... privacy of 3rd party
>> control has nothing to do with monkey-patchif you have the code... sure you
>> cannot do that from outside of the control, but that makes no difference
>> (the problem with private clause is inheritance, protected is better choice)
>>
>>
>>> 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.
>>>
>> Again, do we have to go with one choice here? Either or? Can we go with
>> options when creating Shadow dom?
>>
>>
>>
>>> 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.
>>>
>> Well.. yours upgrades maybe...
>>
>>>
>>> Scott
>>>
>>>
>> B.
>>
>>
>