Open nolanlawson opened 3 years ago
This issue has been linked to a new work item: W-10133774
well, certainly, the main issue is how to support that component in non-native? is that's not supported, then yes. The idea to restrict it everywhere is to have more confident that the component will work with or without native.
Good point, yes. Although it just occurred to me that we also want to support ID selectors for light DOM. Perhaps that's easier to support.
With the advent of mixed shadow mode, we would only be able to remove the restriction if the light component isn't shadowed because light components can render anywhere in the tree. Then the component itself would have to support both the shadowed and non-shadowed case, making id-usage more trouble than it's worth.
Hm, it seems to me that if a light DOM component is inside a native shadow component, then it should still be able to use IDs. Its IDs may conflict with IDs for other light DOM components inside the shadow tree, but that's the downside of light DOM.
Whereas a light DOM component inside of synthetic shadow roots do not have their IDs mangled. (I just tested to confirm.) So in this case as well, ID selectors would work.
Maybe this error should be turned into a warning? It sort of feels like, if we can't predict at compile-time whether a component is native or synthetic, we should leave it up to the developer to use a potentially problematic CSS selector.
The LWC compiler will complain if the CSS contains an ID selector:
In native shadow, it's perfectly acceptable to use ID selectors, because IDs aren't mangled as they are in synthetic shadow (e.g.
foo-0
,foo-1
,foo-2
, etc.). There should probably be some way to disable this check for native shadow components.