Re: [csswg-drafts] [css-shadow-parts] consider putting more power on user instead of author

Setting aside oddities like `#define private public;`, the notion of encapsulation boundaries and information-hiding is an idea with literally decades of research and practice behind it; it's present in every language. It was the entire basis of the Shadow DOM feature in the first place, and even having shadows be accessible at all was a pretty vigorous debate (leading to the current compromise of no default, so you have to specify whether your shadow is "open" or "closed" whenever you construct it).

When those classes are badly designed, they can be annoying to work with, sure. But the answer isn't to work around the language's info-hiding and poke into the class (and it's actually *impossible* to do so in many languages, including JS), it's to get the class fixed to fit your needs.

> Could you consider putting this discussion as opened as only 3 person participate ?

I closed this issue because this debate isn't new; it's retreading ground that we went over years ago, tried out, and realized our mistakes about. The question is more-or-less settled at this point, with far more than three people having discussed it, including all the browser vendors, spec authors, and many real-world authors trialing the features in professional contexts over an extended period of time.

When we *first* designed the interaction of shadow DOM and selectors, we had a very locked-down feature similar to ::part. Early users complained about this and wanted more freedom, so we switched over to just using /deep/. The *exact same users* then complained that they were shooting themselves in the foot too much with /deep/, and were developing more constrained API shapes to protect themselves from it, ending up similar to ::part again.

At the same time, it turned out that /deep/ was expensive to *implement* as well, and we weren't coming up with any good ideas on how to make it cheaper without abandoning the entire "isolated styling world" idea altogether. (You end up having to copy all the /deep/-using rules into every descendant component's style, duplicating those rules many times over.) So abandoning it and returning to something more limited and well-defined was welcome on the performance side as well.

So this discussion will remain closed; without some surprising new piece of information (like browser vendors suddenly deciding that they actually really want to implement this), relitigating the issue won't change the result.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 1 August 2018 23:22:44 UTC