Comments (12)
No, I don't recall having this conversation.
@Templarian If we are able to implement the ::slotted
selector properly I don't see any blocker handling complex compound selectors. I don't see any issue make those selector work once we agree on how the trees should be flattened.
from lwc.
We need a volunteer to work on this. My mental model is easy, we can have a custom attribute for when the slot is supposed to display slotted content, and in that case, we do:
::slotted(input){
color: red;
}
compiled into:
::slotted(input),
[c-foo_foo]>input {
color: red;
}
That seems good enough, and should work fine in both cases, synthetic and native. @pmdartus what do you think?
from lwc.
This issue was discussed in the CSSWG and the interop difference found here is due to a bug in Safari and in all other areas they are interoperable with other vendors. Since default content can be styled using normal styling it was resolved to clarify the spec using examples (since people on the call that implemented it were confusing what HTML flattening would do to slots) and change the spec to read as the current interop behavior.
Discussion is here: w3c/csswg-drafts#5482
So this issue should be unblocked for support.
from lwc.
I think the hardest part here is the replicate the fact that the ::slotted()
pseudo-element should be applied after the flattening.
Here is a complex example: https://jsfiddle.net/wLmbq354/1/
<x-parent>
#shadow
| <style> ::slotted(div) { color: red; } </style>
| <x-child>
| #shadow
| | <style> ::slotted(*) { color: blue; } </style>
| | <slot name="slot3">
| <slot name="slot2" slot="slot3">
| <slot name="slot1">
<div slot="slot1">
<span slot="slot1">
As far as I understand the specification, the pseudo-selector should be applied to the elements that are returned by slot.assignedElements({ flatten: true })
. So if you invoke it on slot2
and slot3
it should return the div
and the span
.
Before discussing how this will be implemented in LWC, I just want to make sure we got this right. It appears that Webkit is the only engine implementing the spec properly:
- Webkit: div is red and span is blue
- Blink and Gecko: div is red and span is black (the tree is not properly flattened)
@caridy Can you confirm we have the same understanding of the spec here so I can open bugs on respective engines?
That being said, I don't think the [c-foo_foo] > input
will make the cut if we want to support flattening properly. I think we will need to add another attribute for slotted content, but I think it will be tricky to get that right.
from lwc.
I don't fully understand the issue, let's chat about it.
from lwc.
@pmdartus Looked around to see if Chrome had any open bugs and I don't see anything resembling this in the tracker. I think I understand the bug.
@caridy Not sure how far this conversation went, but assuming no complex nesting would it be possible to implement a restricted ::slotted
support.
::slotted(div) { }
::slotted(div:hover) { }
::slotted(div:hover)::before { }
Seeing as it translates to specific styles for legacy the performance issue seems minimal.
from lwc.
I don't remember the offline conversation about this... maybe @pmdartus remembers it. we can always chat again :)
from lwc.
@pmdartus any update on the interop issue that caused the blocking of implementing this as I just discussed utilization of this psuedo and wasn't aware that we didn't allow it. Do you have a repro testcase to test the interop and if it does exist we can get this fixed in engines that are blocking our implementation.
from lwc.
The repro can be found in the original post. The issue is still reproducible today.
@gregwhitworth Before opening a bug against a specific engine, I would like to understand which engine is wrong. TBH, this issue is reaching the limits of my understanding of the CSS spec. Do you know someone that might help?
from lwc.
This actually doesn't have to do with CSS itself, but the implementation or interpretation of this specific aspect of the HTML specification. Specifically stating:
The ::slotted() pseudo-element represents the elements assigned, after flattening, to a slot.
So basically, when you follow the algo (which honestly there's so much indirection) is if the above is true. Given the rest of the implementation and that the content appears in the slots (I updated the fiddle to add slot eventing to ensure that Safari/FF/Chromium behave the same and they do).
So effectively it comes down to the above definition of the elements, once flattened. Upon my naiive reading of the algo I think Safari does the correct thing here. And then when you consider that there is a test within WPT specifically testing nested slots that technically passes but does not actually pass in Chromium/FF but does in Safari here I think I'm correct that Safari has the correct behavior. I'll file a bug on Chromium.
from lwc.
Bug filed here: https://bugs.chromium.org/p/chromium/issues/detail?id=1119248
from lwc.
We do not intend to add support for ::slotted
to synthetic shadow. This will come with native shadow mode. See: https://rfcs.lwc.dev/rfcs/lwc/0115-mixed-shadow-mode
from lwc.
Related Issues (20)
- Create lwc:client-only prop HOT 1
- [tests] Firefox 119 fails ARIA tests in Karma HOT 3
- [tests] saucelabs integration tests failing on Linux/macOS HOT 4
- Label issues with package names HOT 4
- In dev mode, public APIs extending from superclasses may throw when called HOT 2
- Components that do not extend LightningElement should get dev warnings for missing `@api` HOT 3
- Components should not "inherit" `@api` from their superclasses HOT 1
- Add instrumentation/logging for native vs synthetic lifecycle callback differences HOT 1
- [ci] Firefox tests failing in SauceLabs
- DOMException: Failed to execute 'setAttributeNS' on 'Element' on `<svg xmlns:xlink>` HOT 3
- Unable to create hello world with LWC Open Source HOT 4
- Follow-up work for ElementInternals HOT 1
- `errorCallback` swallows SSR error HOT 2
- OpenTelemetry sdk for lwc HOT 4
- [3.7.0 regression] Re-rendering causes `this.refs.foo` to become `undefined` HOT 1
- [tests] `Unexpected attempt to set "disabled=true" property from the renderer`
- [Perf] Avoid calling `traverseAndSetElements` on every re-render
- [Template compiler] Event listeners on deep objects not being serialized properly HOT 2
- [Metadata] Inconsistency in AST for deep vs shallow expressions HOT 3
- Hydration does not support FACE or native lifecycle
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lwc.