Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 25.2.2013 19:52, Scott Miles 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)?
Sure we do, but clear edges makes clear contract what can change in the 
future without informing anyone and what is carved is stone.
>
> 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.
Boris is not saying customers are right, Boris is saying they do it, 
simply because it's easy o blame someone else.
>
> Btw, If Big Marketshare is so powerful, why haven't we already fixed 
> whatever thing he is monkey patching?
Because someone else may be using original functionality


This part of this discussion is not about whether someone can/cannot 
monkey-patch... It's always possible. It's about clarity what is and 
what is not public. And this clarity is not only for programmers but for 
runtime as well. It's quite easy to work 50k+ lines program code with 60 
3rd party controls when the edges are clear (and you do not even need to 
use use 3rd party controls). The overhead you have to go through, either 
you alone or in team, not to mess something completely independent in 
big project just because missing isolation is quite huge.

>
> >> 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.

Well if there is/will be such option (I cannot find it in Shadow DOM 
spec), I'm fine either way, but I do understand that we will probably 
have to go with less strict option as default. But frankly it will not 
solve e.g. Google Feedback issue if someone (like me) will opt for total 
isolation. Or we need to make more granularity (total, read/write {thou 
it's like a normal dom}, read-only, whatever), but regardless of apps 
like GF, the total one is important step I think we need to do.


B.

Received on Monday, 25 February 2013 19:25:22 UTC