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

> We tried the deep combinator; what it ended up with in practice (that is, based on experience from real developers writing real code with it) was fragile and error-prone code. You end up losing the nice "I know exactly what I'm targetting" quality that shadow DOM's encapsulation is supposed to provide, because you can write a rule deep-targetting a particular class you know about, and accidentally hit other components that happen to use that same class internally, which isn't a detail you should normally need to worry about. 

Well maybe because developers didn't understood to use with parsimony the deep operator... it was new and experimental. **The "it's dangerous" is for me a fake argument.** After all, I could write a `while(true);` or doing some `* { color: red }`. It provides big power because we need it sometimes, this doesn't mean it is necessary to be used.

The big problem:  you assume that the shadow component will be perfect (inclues @apply, and part, etc...), maintained for a long period and all the users of the lib will update all these components when a new release is here. **BUT** in practice, when you work in company, you deal most of the time with legacy code where no libs are updated for years (or not updatable because the old code doesn't support it), most of them are unmaintened anymore or the code is "closed" which mean no pull requests, so no changes are possible to fix the bugs/missing parts (here css theming). That's for this kind of really **frequent** situations (except maybe if you work at google or microsoft), that we need some power to bypass the restrictions of shadow dom. I anticipate a big problem that we'll all face in a not so long future. Here you thing as a pure developer, not as a businessman which face every time crazy clients' requests that you need to satisfy !

> And that's not even getting into the fact that you're now relying directly on internal structure of things that you aren't supposed to care too much about the internal structure of, so any updates to the component are likely to break your code.

Wrong ! I care a lot because I want to theme with precision a component (like the icon of a pause button from a video player that a client request me to change). If the author forgot to put a variable for a `background-image` (or that I want to add the property), I want to be able to bypass the shadow dom boundaries. Moreover, If I see any breaking changes in the display, I can rollback the update (or avoid major update), or adapt my code. BUT I won't be able to adapt the lib's author code... because of the current limitation.

> Switching to ::part means that component authors get to publish a reliable, stable styling API that's robust to changes they make in the future, and they aren't exposing more details than necessary about the internal state of their component.

Something that never append in reality, libs evolves so fast that major updates (including breaking changes) append faster than bugs fixes sometimes. Moreover, a client may absolutely want to incorporate a shadow component from a "closed" code company (ex: a solidwork preview component). In this case, you probably won't see any part or css variables... so you're deeply fu***.

> For component users, it means that they know exactly what's safe to target, and it's completely impossible to accidentally over-target unrelated elements in other components.

This is another fake argument: To be completely safe, just don't use **deep**...

What's you're saying is basically: _you see when you have sex, you can get HIV so we'll force you to use a condom no matter's what (here the removal of the deep operator). It's in steal and totally unbreakable. You want kids (power to theme, bypass) ? Sadly we won't allow you to remove the condom, so sorry it's impossible..._ (I didn't find a better representation sorry :) )

> or the class author wrote a bad API for their class.

This is exactly what appends in 99% of the cases. At first it's good until technologies evolves, code is unmaintened or provided from a closed source... And sadly when you work in a company, you don't always have choice to use the lib you want, and to maintain frequently your code.

Finally, don't assume that I say: "everybody should use deep, it's no cool !!!!" What i mean is: you probably don't need deep and should avoid it, BUT if you're stuck with a shadow component without css variables and no way to update the lib's code AND you absolutely need to theme it, you should have a way to to it ! This situation won't appear immediately, as shadow dom is pretty new but probably in 6 months / 1 year we'll start to encounter frequently this kind of problem. Where the simple introduction of a small word `deep` could solve easily all of this problems...

-- 
GitHub Notification of comment by lifaon74
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2963#issuecomment-409687332 using your GitHub account

Received on Wednesday, 1 August 2018 19:05:36 UTC