Webcomponents: > ""::slotted() should full support complex selector"" has came up multiple time and always get closed without any solution.

[ghost]

""::slotted() should full support complex selector"" has came up multiple time and always get closed without any solution.

That should be tracked in a new issue, not in this old issue about ::slotted pseudo element. Also, supporting complex selector inside ::slotted would be about matching selector in the tree in which slotted node appears, not about selecting arbitrary descendant of slotted content. Regardless, you should file a new issue. We can't tack every new idea into an existing issue.

_Originally posted by @rniwa in https://github.com/w3c/webcomponents/issues/331#issuecomment-632913345_

[ghost]

There you go.. But it still doesn't solve anything. The question stay, how are we suppose to style the children?

[rniwa]

Please state your concrete use cases. What are you creating? and what issues are you encountering with the existing features?

[ghost]

There is no existing feature that's the point. I should not have to make things more complicated with examples when simple sentence is perfectly clear. Again.. The issue is how do we style slotted child nodes? Unless you are saying that slotted elements simply cannot have children. Stop closing the issue and you won't have to make us repeat.. #745 for example.

[rniwa]

There is no existing feature that's the point. I should not have to make things more complicated with examples when simple sentence is perfectly clear.

You do. The lack of a feature is not a basis to add a new feature. We need use cases to evaluate what solution makes sense.

Again.. The issue is how do we style slotted child nodes? Unless you are saying that slotted elements simply cannot have children. Stop closing the issue and you won't have to make us repeat.. #745 for example.

Again, what's important is concrete use cases that motivated such a solution. Given this particular solution has been rejected in the past, it's not useful to keep repeating the same discussion. What may change implementor's opinion or might prompt new solution is new uses cases for which we can seek a solution.

[ghost]

And yet you still haven't said how to style a child node. Maybe someone less verbose then you could make sens of it. #745 already made a perfect use case.

[rniwa]

And yet you still haven't said how to style a child node. Maybe someone less verbose then you could make sens of it. #745 already made a perfect use case.

Look, I'm trying to be helpful here. You need to describe your use cases & problems, not your preferred solution. Otherwise everyone is going to simply ignore it.

If your use case is identical to that of #745, then there is nothing new to discuss.

[ghost]

Of course there is, you just had to solve one of the 30 last exact same issue. #745 is not even solve and it's 2018. Hello There.

[leobalter]

@cldtech I hope you take this with a grain of salt at some point. For the web components work, as any other standards work, we need to exercise some diplomacy and try to get a positive path to something we want to solve.

While I might understand the frustration within the lack of a feature there are some points in this thread that are just not constructive. A different approach would be much more helpful to your case, if your goal is to have the proposed feature available. Some examples:

The title is confusing and contains opinions about a meta discussion. The quoted parts could be enough. The meta discussion is in this thread is also leading to a different path, which I believe it won't match your actual goal. So far I see a complaint about closing threads, or what is necessary or to build the argument for the proposed feature.

Even if you don't see that yet, @rniwa is trying to help. From the point to start a new issue to request for examples of use cases. These are just paths to get things done faster. This is a way to prove the need of what you're requesting to other people. We all have a different context and experience. We want to understand your experience and a use case is way to try that better.

simple sentence is perfectly clear

Bias. Experience makes us see things from a different perspective. @rniwa is sincerely indicating it is not clear and I have to agree.

If it is impossible or too complex to show an example, there is no need to get defensive. Instead, try asking for help or just say it is complicated to illustrate it.

And yet you still haven't said how to style a child node

Don't require responsibility from others. You're requesting the feature, not others so far.

---

I came in to this issue interested in what it was about and unfortunately all I can answer so far is meta. I wish to learn more about the technical problem.

[ghost]

A lot of word for no answer. "While I might understand the frustration within the lack of a feature"? No it is absolutely not a lack of a feature, it's the whole purpose on slots that doesn't make any sens without child. It's just a pale imitation of back-end templating engines brackets feature and being HTML is useless.

[leobalter]

I am not well versed in web components yet. Would you help me illustrating how "::slotted() should full support complex selector" should be using a quick code example?

[mkay581]

what @cldtech is saying is valid. Being able to style slotted nested children has frequently been requested many times but it just keeps getting shot down.

[ghost]

Custom element let's say a ribbon. There HAS to be child nodes for the layout to make sens and work;
Consider this web component UIRibbonAccordion:

const shadowRoot = this.attachShadow({ mode: 'open' });
shadowRoot.innerHTML = '
    <slot name=pin><\slot>
    <fold>
          <slot name=fold-pin><\slot>
    </fold>
    <!-- style -->
    <style>
          :host { .... }
          :host > ::slotted(ui-ribbon-section) { .... }
          :host > ::slotted(ui-ribbon-section) > ::slotted(fold) { .... }
    </style>';
}

Then in HTML;

<ui-ribbon-accordion>
    <ui-ribbon-section slot="pin">
            <!-- accordion tab -->
            <ui-pin slot="tab">
                  <img slot="icon" src="....">
                  <label slot="label"> .... </span>
            </ui-pin>
            <!-- accordion panel -->
            <ui-ribbon-fold slot=fold>
                  <ui-pin>
                        <img slot="icon" src="....">
                        <label slot="label"> .... </span>
                  </ui-pin>
            </ui-ribbon-fold>
    </ui-ribbon-section>
</ui-ribbon-accordion>

Where can we say the accordion panel must be a display: flex or a transparent background?
Only one level (top level) content styling makes it totally useless to put any nested content doesn't it?

[rniwa]

Where can we say the accordion panel must be a display: flex or a transparent background?
Only one level (top level) content styling makes it totally useless to put any nested content doesn't it?

In that scenario, ui-ribbon-section can have a shadow root of its own and then it can style ui-ribbon-fold because it's in its slot. Does that not work for your use case, if so, why?

[ghost]

It doesn't because one; creating multiple custom component for what is actually one get us back to being not so reusable therefore not a component and two; We can't make a component inside another from HTML only, we have to pass by the JavaScript of each node level to make them instantiate there own component (or more so sub-component) which also mean they have to know them which prevent dynamic uses and the worst for me; no being able to make the "nested components" by HTML means we can't use those components in server-side templating engine like Django or Jinja2 (for pythonic example), only JavaScript based ones like mustache could do it and only by making even more code!! Do we really need to start making "sub-components" jargon or should we just be able to style everything on the way DOWN the trees?! If there is such a big problem for others that i can't think off, there also can be an attribute to activate/deactivate the childs access..

[mkay581]

So @rniwa is the recommendation that whenever you have to style slotted nested children, just make them seperate component with their own shadow dom? 😃

[ghost]

So @rniwa is the recommendation that whenever you have to style slotted nested children, just make them seperate component with their own shadow dom?

Thats also what i understood, and the first thing i tried but like said my very last message, there is a painfull snowball effect!

[rniwa]

It doesn't because one; creating multiple custom component for what is actually one get us back to being not so reusable therefore not a component and two;

I don't follow what you mean by this. Why would adding a shadow root to ui-ribbon-section make it not re-usable? Could you elaborate?

We can't make a component inside another from HTML only, we have to pass by the JavaScript of each node level to make them instantiate there own component (or more so sub-component) which also mean they have to know them which prevent dynamic uses and the worst for me

I don't follow this either. It's true that we can't define a custom element or shadow root purely in HTML but how does that relate to not being able to attach a shadow root on ui-ribbon-section?

no being able to make the "nested components" by HTML means we can't use those components in server-side templating engine like Django or Jinja2 (for pythonic example), only JavaScript based ones like mustache could do it and only by making even more code!!

The lack of server side rendering seems like an orthogonal issue. As things stand, shadow DOM doesn't really work with server side rendering because nothing in shadow root could be constructed in the server side. That issue is tackled in https://github.com/whatwg/dom/issues/831.

Do we really need to start making "sub-components" jargon or should we just be able to style everything on the way DOWN the trees?!

Could you clarify what you mean by "sub-components" jargon? If you meant that having to create every child element that's relevant to your custom element / component also a custom element / component, then yes, that's how things are designed right now.

If there is such a big problem for others that i can't think off, there also can be an attribute to activate/deactivate the childs access..

This isn't really an issue for other web developers per se. Allowing styling of arbitrary descendent elements of a slotted content would result in a massive hit in browser performance and other implementation challenges that I'm not going into details here.

[rniwa]

So @rniwa is the recommendation that whenever you have to style slotted nested children, just make them seperate component with their own shadow dom?

Thats also what i understood, and the first thing i tried but like said my very last message, there is a painfull snowball effect!

I'd like to better understand what your "painful snowball effect" is. Perhaps those pain points are things we can resolve.

[ghost]

So @rniwa is the recommendation that whenever you have to style slotted nested children, just make them seperate component with their own shadow dom?

Thats also what i understood, and the first thing i tried but like said my very last message, there is a painfull snowball effect!

I'd like to better understand what your "painful snowball effect" is. Perhaps those pain points are things we can resolve.

No, clearly you can't.. At this point of recalcitrant non-sens i'll just use another technology. You are suppose to be w3c, not our stubborn uncle who knows better then everyone. I do not thank you but i'll be sure to stay in touch with the others you shut down. This is exactly how new technologies are born since always.
Your fixation on what NOT to do with web components prevent you from even reading us right.
You just keep making us repeat and turn the question around til you win your opinion. Yes OPINION, because not once you provide an actual argument about anything. I do not believe you don't understand for one second. I chat bot would do better.

[mfreed7]

No, clearly you can't.. At this point of recalcitrant non-sens i'll just use another technology. You are suppose to be w3c, not our stubborn uncle who knows better then everyone. I do not thank you but i'll be sure to stay in touch with the others you shut down. This is exactly how new technologies are born since always.
Your fixation on what NOT to do with web components prevent you from even reading us right.
You just keep making us repeat and turn the question around til you win your opinion. Yes OPINION, because not once you provide an actual argument about anything. I do not believe you don't understand for one second. I chat bot would do better.

I don’t think you’re interested in working to figure out a solution to the problem you’re bringing up. @rniwa has been exceedingly patient in this conversation and has asked several times for you to help everyone understand the use case for your requests. You don’t seem to want to do anything other than repeat your request and say that it is obvious. But without a clear understanding of the problem we’re trying to solve, we’re destined to fail at solving it. Perhaps you could just elaborate on what you mean by the “painful snowball effect”?

[ghost]

But without a clear understanding of the problem?

I am not well versed in web components yet. Would you help me illustrating how "::slotted() should full support complex selector" should be using a quick code example?

Strange that you didn't see that;

Custom element let's say a ribbon. There HAS to be child nodes for the layout to make sens and work;
Consider this web component UIRibbonAccordion:

const shadowRoot = this.attachShadow({ mode: 'open' });
shadowRoot.innerHTML = '
    <slot name=pin><\slot>
    <fold>
          <slot name=fold-pin><\slot>
    </fold>
    <!-- style -->
    <style>
          :host { .... }
          :host > ::slotted(ui-ribbon-section) { .... }
          :host > ::slotted(ui-ribbon-section) > ::slotted(fold) { .... }
    </style>';
}

Then in HTML;

<ui-ribbon-accordion>
    <ui-ribbon-section slot="pin">
            <!-- accordion tab -->
            <ui-pin slot="tab">
                  <img slot="icon" src="....">
                  <label slot="label"> .... </span>
            </ui-pin>
            <!-- accordion panel -->
            <ui-ribbon-fold slot=fold>
                  <ui-pin>
                        <img slot="icon" src="....">
                        <label slot="label"> .... </span>
                  </ui-pin>
            </ui-ribbon-fold>
    </ui-ribbon-section>
</ui-ribbon-accordion>

Where can we say the accordion panel must be a display: flex or a transparent background?
Only one level (top level) content styling makes it totally useless to put any nested content doesn't it?

It's not patience, it's taking us for fools.

[mfreed7]

Right - you said that here, and then @rniwa asked this followup question. I’m still wondering what the answer is - why don’t nested components work here?

[rniwa]

So @rniwa is the recommendation that whenever you have to style slotted nested children, just make them seperate component with their own shadow dom?

Thats also what i understood, and the first thing i tried but like said my very last message, there is a painfull snowball effect!

I'd like to better understand what your "painful snowball effect" is. Perhaps those pain points are things we can resolve.

No, clearly you can't. At this point of recalcitrant non-sens i'll just use another technology.

You're more than welcome to do so. Shadow DOM and custom elements aren't meant to solve every problem in existence nor was it conceptualized to address every paradigm of writing web apps or websites. If it doesn't meet your needs, using another approach is the right thing to do.

You are suppose to be w3c, not our stubborn uncle who knows better then everyone. I do not thank you but i'll be sure to stay in touch with the others you shut down.

Please refer to WHATWG's code of conduct and W3C's code of ethics and conduct. I've been following up on this issue on my spare time while I'm on a long term medical leave. I don't appreciate you name calling me like that.

This is exactly how new technologies are born since always.

That's simply not how W3C or WHATWG operate these days. We base our solutions on use cases and problems, not an abstract need to do something.

Your fixation on what NOT to do with web components prevent you from even reading us right.

On the other hand, you seem to be fixated on the exact solution you'd like to have. What I'd like to do is to explore alternative solutions that can address your use cases. Perhaps we'd conclude that adding the capability to style arbitrary descendants of slotted content is the only way but maybe not. Would you not rather explore those possibilities at all because you want one kind of solution?

You just keep making us repeat and turn the question around til you win your opinion. Yes OPINION, because not once you provide an actual argument about anything. I do not believe you don't understand for one second. I chat bot would do better.

Well, it's not my opinion that supporting the ability to style any descendent of slotted content incurs unacceptable performance cost. That's a matter of fact statement we know as a browser engine implementor. And people who use web browsers care a lot about performance & responsiveness so we're constrained by that need.

And again, I really do not appreciate your tone of voice here. You've been warned.

[ghost]

Name calling? For what, stubborn? Grow up fellow. You almost wrote a book today about what web component can't do and still haven't said what they are suppose to be use for.
So as for being warn, i return you the compliment. You are the one who's suppose to help here, your opinion is as irrelevant as you without arguments. It's time to take this to W3C actual people. I don't appreciate you using the organisation to impose an arbitrary way of using components as what is not without never answering to what they are suppose to be for in this perception of yours.
How dare you hemper with progress. 😔

[rniwa]

You are the one who's suppose to help here

I'm not sure why you got that impression? I'm simply a participant of this discussion.

Because I'm more or less responsible for web components standards discussion & its implantation in WebKit these days, I'd be interested in hear any use cases or issues people are encountering but I'm no way responsible or obligated to help someone who wants to propose or realize new idea or feature. The person who wants to do that needs to convince everyone else that it's a good idea.

We're all here to discuss what problems we may have with existing web components standards and how we may solve them. Nobody is entitled to any help.

[ghost]

Well perhaps i got this impression from the fact that you made statement and gave orders on every single issue about ::slotted never asking questions at least since #331 with more presence then anyone else. But mostly because you are the one who closed it on May 5, 2016 and we're not the original author..
By the way;

these days

Yeah try something else.. May 2016..

So i suppose i don't get who has access to close issues.. I do apologize for that part.

[Danny-Engelman]

Carl,

I saw you post in French on Twitter, so you should at least be able to read this:

c'est le ton qui fait la musique

With your reactions in this and other GH repo, you are no example of us true creatives.

If your tone of voice is evolution, then I am taking a different path

Back to ::slotted

It does what it does for many reasons discussed over the past 4 (and maybe more) years.

We current WC users, are standing on the shoulders of giants, rniwa is one of them

• Slots are provided by the host
• Slots are _reflections_ of lightDOM (not moved to shadowDOM)
• so the host does the styling
• ::slotted takes simple selectors
• ::slotted can only touch the _"skin"_ of (lightDOM) content
• this prevents performance issues

You have a young face (or you are a troll)
So be glad you didn't have to do Web development 25 years ago with less standards.

Standards are agreed upon after (lengthy) discussions.

They won't be changed just because a young gun starts calling every participant an idiot.
Trust me... I tried it on Macromedia, when I was about your age.. 25 years ago

Welcome to the WC community,

Danny Engelman
Amsterdam

PS. (never waist a moment for attention) I think Apple should do Customized Built-In Elements,
<img is="queen-of-hearts> is more useful than <queen-of-hearts><img src=...></queen-of-hearts>

.

[ghost]

"If your tone of voice is evolution"..

Read again, or should i say it in french for you. It says creativity is evolution. Not that it has anything to do here but since you ask.

This is as manipulative as it can be. What possible benefits to bring up that i speak french?
So as for mentioning 25yo standards only to bring up my age is at best "immature". Talk about irony..

They won't be changed just because a young gun starts calling every participant an idiot.

Yes Danny, i am the first and last person who ever asked what the hell is the use of something you cannot style. #331, #574, #594, #745 must be 'trolls' too. This is coding, the one place where we can actually satisfy everybody, it's called parameters or sometimes attributes. No need to 'change' any basis.

You also put the word "idiot" in my mouth. I did not insult anyone and my tone is not relevant as it's interpretation and not information. Condescension and personal attacks are not of any help so as judgement about age. This is no place for this. It's even more sad that you seem to have the answers but for some reason you didn't talk about that.

If that tone of voice is web components, HTML is already dead.
Welcome to.. "the world"!

[Danny-Engelman]

Carl, there is no "the world";
between you and me there is your (on the few indicators I would say autistic) world and mine.

And this is the last message I post in yours.

It's even more sad that you seem to have the answers but for some reason you didn't talk about that.

Like I tried to explain,
you get the right answers when.. in your case if.. you learn to ask the right questions.

Au revoir, pas plus...

[ghost]

For those still looking for solutions in these closed unsolved older posts; i was gonna start a library to handle the mess but looking if some already made it before i found some possibilities. I think a light & specific library could do the trick and ensure a more updated approach as it's the actual project and not a tiny part of a standard.

• "X-Tag is a lightweight, power-packed Web Components library that gets you there fast, and stays in its own lane." What a slogan. xD
• LitElement. A simple base class for creating fast, lightweight web components

[Danny-Engelman]

Good, you are communicating in our world again.

Maybe next time, before you come in all guns blazing, you can do a search first.... An observation.

Here is more for you to look into:

• https://nicedoc.io/WebReflection/hyperHTML (another giant's shoulders we stand on)

• https://github.com/hybridsjs/hybrids

• https://github.com/ionic-team/stencil

• https://github.com/skatejs/skatejs

• ... and more..

Note that any library is a wrapper around standards, libraries can't do anything more a standard can do, can only make development easier.

Your question was about ::slotted. Lit (see slotted in https://lit-element.polymer-project.org/guide/styles) does nothing more than vanilla JS does.

Libraries are the can with diced tomatoes, vanilla development the tomatoes,
some cooks prefer to use a knife.

10 years ago jQuery had 20 competitors also...
I learned the hard way betting on the wrong horse (Mootools in my case) can be costly.

[ghost]

My question is about styling custom elements, so as those a mentioned.

I saw all those libraries 100 times, i am not posting those to argue them, if you don't like them just don't use it and get the hell out of our way. You are not any kind authority to deny solutions.

Note that any library is a wrapper around standards

That is once again not what i said.
Please refrain from posting with no contribution to solutions to add. No, concatenating what is not a solution nor it is contributing. More importantly. Insults are not welcome and talk more bout you then me. I did not insult anyone and yet you called me 'young gun' and 'autistic'.

A library is a solution if it does what the user is looking for in a beta standard. Before turning those words, i suggest you use a reference. The Thesaurus tool is fantastic to approach semantics.

[ghost]

So there it is people! CSS Shadow Parts are is the exact solution to the exact problem just as requested here. Soon enough in this article we can find this;

Encapsulation is great, but we also want our components to be themeable and customizable. That’s been made far easier with the ::part selector.

Here's another article from @vaadin with a useful perspective. Seems like

massive hit in browser performance and other implementation challenges

weren't much of an obstacle. No thank you to you @rniwa and @Danny-Engelman! I don't think you even look for it, your mind we're made. We are coders guys, if we loose this sens of "everything is possible" this virtual future of ours is gonna be plain as a day!

[rniwa]

I feel like you either misstated your original problem or doesn’t understand what ::part does. It allows a shadow tree to expose its decadent element to the tree of its shadow host. I.e. if there is an element E with part specified in a shadow tree of a shadow host H, then H::part allows E to be styled within the tree of H. It no way allows us to style elements ancestor of which slotted into the shadow tree.

[ghost]

Well it works very just fine for my ribbon example, exactly as wanted with ::part() instead of ::slotted(), i tried up to 10 level of nested element inside the shadow dom and again, just fine.
When you talked about performance i even said it could be completely avoided by using some kind of attribute, therefore wouldn't lead to any parsing that could lead to slow down.

So i'll just leave this here;

Well, it's not my opinion that supporting the ability to style any descendent of slotted content incurs unacceptable performance cost. That's a matter of fact statement we know as a browser engine implementor. And people who use web browsers care a lot about performance & responsiveness so we're constrained by that need. - @rniwa

[rniwa]

Sounds like you misstated your problem or we all misunderstood what you were saying then. Glad it worked out.

In the future, please use other online forums such as stackoverflow before filing a spec issue. We’re not here to help your web development, we’re here to discuss standards.

[ghost]

Save it, you we're just to proud and now it's simply pathetic.

[rniwa]

Save it, you we're just to proud and now it's simply pathetic.

Again, this post violates the code of conduct. Please refrain from making comments like this. It’s not acceptable. You’ve been warned twice now.

[ghost]

My question is about styling custom elements, so as those a mentioned.

I saw all those libraries 100 times, i am not posting those to argue them, if you don't like them just don't use it and get the hell out of our way. You are not any kind authority to deny solutions.

Note that any library is a wrapper around standards

That is once again not what i said.
Please refrain from posting with no contribution to solutions to add. No, concatenating what is not a solution nor it is contributing. More importantly. Insults are not welcome and talk more bout you then me. I did not insult anyone and yet you called me 'young gun' and 'autistic'.

A library is a solution if it does what the user is looking for in a beta standard. Before turning those words, i suggest you use a reference. The Thesaurus tool is fantastic to approach semantics.

You're a disgrace.