Re: [w3c/webcomponents] Alternative proposal for closed shadow DOM (#499)

Hello

first of all, as a starting point, we should consider 3rd party 
components basically the same way as user-agent provided components, as 
a black box. There is no need for different approach, that would be even 
counterproductive. What you are describing can be applied to standard 
elements as well. So what, we live with that for 1/4 of a century.


security
---------------
never been an issue, because that is not what ShadowDOM (SD) is for
  - rewriting attachShadow is not problem with SD, it's ECMAScript (ES) 
feature, in such case we should not be able to write any ES, because 
every method can be hijacked.
  - yes, host page have to implicitly trust component with data, but as 
a desktop developer, every time regular desktop developer uses 3rd party 
component, the security risks are high (e.g. direct access to harddrive 
on regular app). But one should be aware of what one is using. We do not 
take down internet because someone might download virus, it is everyone 
responsibility. Such is this. We should not limit valid usage because 
author might misuse it and programmer, who should be even more security 
savvy than regular user, does not care


Integrity
------------
- component element might have very reasonable need to interfere with 
outside of itself through public API of outside, the same way outside 
can interfere with the element through its public API or even other way 
(e.g. putting stylesheet link element, script element will interfere 
with outside, we have those exactly for this purpose)

automation, accessibility & testing
------------------------------------------------
I see no problem. You can test 3rd party the same way as you test 
regular elements. It might be poorly written (insufficient public API, 
not enough events, ...] , yes, but that is not problem of closed SD, but 
that particular component. The same applies for the rest of this point

  desktop component development / usage / behavior
---------------------------------------------------------------
Desktop development (and not just desktop, but I'm thinking controls 
mostly) is used to this concept for a very long time. ES is bit 
different, but other languages know concepts of private or protected 
parts of objects (I'm missing those in ES). Which actually turns 
everything into black boxes. Every problem with this is of 2 kinds
  - author creates poor public API, developer cannot use the part of 
object that should be usable from outside
  - developer is simply using wrong object (the object simply does not 
fulfill all needs)
neither is the problem with the concept of privates/protecteds (= closed 
mode for web dev), but, as usual, with people.
This is not about "but this is web page, not desktop", first of all, 
every one of us have been doing it for as long as we are 'web 
developing' with user-agent provided elements and second of all, concept 
of 'everything touches everything, whenever and however it wants' may be 
great for web presentations, but is detrimental for web apps, because 
prevents reusability, composition and update of components. All those 
concepts rely on blackboxing of components: author will provide you with 
enough API to use the component and makes sure it will not change (or 
the behavior) with upgrades, and you will not rely on internals so it 
can actually be updated/improved. Save composition relying on either 
being design to interfere by author (which developer should know)  or on 
explicit command from developer. I believe we have enough issues through 
the years with 2 frameworks on one web page interfering.
The hardest possible black-boxing of components is simply necessary for 
creating truly reusable components, may be not natural for web 
developers used to total control over everything, but me, developing in 
different environments as well, I was actually missing this = easy 
reusability of components across several apps. (can anyone add privates 
and protecteds into ES? At least we have WeakMaps and symbols, but 
protected properties/methods would make my day... I know, TC39 issue)
* just a notice, controls in desktop environment (unless some composed 
frame) are all actually canvases with the states of the control painted 
onto it (simply thing of checkbox), there are no internals one might go 
nuts with.



Brona


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/499#issuecomment-218794256

Received on Thursday, 12 May 2016 15:32:09 UTC