Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 25.2.2013 18:38, Tab Atkins Jr. wrote:
> On Mon, Feb 25, 2013 at 6:21 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> On 2/25/13 12:11 AM, Tab Atkins Jr. wrote:
>>> We've gone back and forth.  It seems that allowing monkeypatching by
>>> default is the better choice, as most uses aren't security conscious
>> Tab, could you please read and respond to what Blake actually wrote?  He
>> didn't mention the word "security" at all.
> True, but that's often something that comes up.  Sorry for implying
> that was the only concern Blake had.
>
> Still, though, the "private by default" impulse is nearly always
> wrong, and contrary to a lot of patterns on the web.  As I alluded to,
> and Elliot explicitly said in the 2012 email that Bronislav quotes,
> 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.  Because of this, hiding the
> shadow is *not* something that's obviously good, and I argue that it
> should rarely be necessary in the first place.
>
> 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.
>
> ~TJ
>

My opinion of course... but you wrong on so many levels... I'm 
originally desktop applications programmer (still doing some), and 
private by default is the best policy (actually it's protected, but 
there's no such concept in HTML and no such thing in JS yet), it is 
contrary to lot of patters on web (given JS and DOM sharing space over 
all document regardless of origin), but this is serious flaw of the 
design, not a pro, it's con.

Sure I can say "please not change the internals of that DOM it may 
change in the future, do not count on existence of some node in that 
DOM, it may change in the future" but again, what is the point of Shadow 
than?

Yes, high integrity is expensive, so what? That is not an argument at 
all. It's a choice... do I need it? I'll use Shadow DOM, is it pointless 
for the result? I will not use it... We are not making anything 
mandatory. Shadow DOM is the way hi to create actual blackbox 
control/component/widget as it's normal and beneficiary in other languages.

"This is always true, because low-integrity things are *useful*, and 
people often try to reach for high-integrity without thinking through 
its downsides." Generalization excusing poor decisions of programmers? 
How about those, who can make good one?


But to argue your original point: keeping the smallest amount of point 
application can connect to control/component/widget blackbox is the best 
way how to ensure continuous, long time, functionality without breaking 
everything else. Because you are keeping the boundaries sharp.  When you 
have e.g. Delhi control, you know the contract between the original 
author and you. Having HTML+JS+CSS mess you know nothing at all.

I do recognize the history of the web, and I'm fine with making access 
policy to Shadow DOM more granular as long as I'm able to actually say 
"I do not want you to see anything other that I choose to expose in any 
way".



B.

Received on Monday, 25 February 2013 18:25:08 UTC