- From: markofca via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Sep 2019 00:45:56 +0000
- To: public-svg-issues@w3.org
@dirkschulze My 2c (which I believe may be sacrilege and apologies in advance)... As a developer for 30+ years, I personally don't see the Shadow DOM ever being something that a large number of web developers will ever "get". I barely get it myself. There feels like a tight coupling between understanding how a browser is implemented and understanding the Shadow DOM. Not many people understand the former, so I don't have a lot of hope that it will be easy, for example, for people whose day job is styling web pages with CSS to grasp the finer workings of the Shadow DOM. This could just be my own difficulty with it. Partly, I think there is an issue that the terminology for just about everything related to the Shadow DOM (why is it called a shadow DOM even?). It breaks from traditional computer science terminology, and when we're talking about CSS, we have to recognize that even traditional computer science terminology is probably not widely understood. Developers have common notions of 'class/prototype/template' and 'object/instance', but discussions of shadow DOM introduce a very parallel set of terms for these notions, maybe for good reason, but I'm not so sure. In my description above, I see myself casting the discussion back into a more familiar paradigm. Maybe it would help (or maybe it's too late?) to think about the naming and concepts so that people learning about the Shadow DOM have some meaningful landmarks. The idea that I instantiate classes into objects and can only style those objects through an interface controlled by the class are readily accessible notions for a first year computer science student. By contrast, the idea that multiple shadow trees are created with host contexts and distribution lists and shadow-projected content is perplexing. Quickly reading through the link you provided (which I understand is a spec and not a tutorial) makes me nervous. I would really need to sit down and parse it line by line to try to get the gist of it. In short, I think the value of CSS is, in part, that it's incredibly accessible to a wide range of people. I don't see the Shadow DOM as it's currently presented as ever achieving that. It largely is an implementation detail for browser developers. In some ways, the encapsulation it's providing seems of limited value compared to the complexity it's introducing. The very notion of CSS is somewhat anti-encapsulation (anyone can modify anything anywhere in the DOM) and the shadow DOM, to the extent that it is used widely and not just as something to aid browser development, breaks that paradigm. I haven't thought about it as much as I'm sure you guys have, but my gut instinct would be preventing/limiting access across the boundary of the shadow DOM is a mistake. The history of styling shows that early encapsulation (hiding the ability to style scroll bar elements for example) gets undone over time, not the other way around. I suspect people should be able to style 'instances' freely without limitation. Yes, that bears the potential for abuse, but on the flip side, everyone will understand it because it reflects how CSS works in the 'normal' case. Instantiation is useful (replicating structure without replicating code...<use>). Encapsulation, not so much. -- GitHub Notification of comment by markofca Please view or discuss this issue at https://github.com/w3c/svgwg/issues/367#issuecomment-533359823 using your GitHub account
Received on Friday, 20 September 2019 00:45:57 UTC