Open lpradopostigo opened 3 months ago
Not exposing the element internals is one of the main reasons for web components, and is not a bug. When working with this library, you should not worry about what is inside the component, and instead focus on styling the icon via its props, or by using CSS on the custom element itself.
If you want it to be display: block
, simply apply that style to the custom element:
<html>
<head>
<style>
a { display: inline-flex; align-items: center; gap: 1em; }
ph-link { display: block; }
</style>
</head>
<body>
<a href="https://phosphoricons.com">
<span>Phosphor</span>
<ph-link></ph-link>
</a>
</body>
</html>
Though that usually isn't what you want when using icons in a flexbox. By default, they render as display: contents
, and this should appear to the surrounding light DOM as just an SVG element.
You can see and play around with it in this sandbox: https://stackblitz.com/edit/vitejs-vite-ebfkhs?file=index.html,src%2Fstyle.css
I'm open to having my mind changed though. The layout use-case you mentioned does not require (and in my opinion should not be done with) the part::
API, but it's possible there are valid cases.
Sorry for the late reply, I agree that my use case can be achieved using another CSS selector. It just seems weird to me that there is no part exposed, for example the https://shoelace.style has at least a base part exposed for simple components.
Now, since you are only rendering a svg and most people only will use as it is, I think is safe to assume that most of the problems they will face will be related to layout, which can be solved via CSS selector without targeting the Shadow DOM.
After some thought, I believe that the reason to exposing a base part will be only to solve some weird use case, also people with weird use cases probably should use the raw svg version. So, in the end I think it is just about how much of the inner pieces of the component you want to expose, thanks for your time.
Yeah. For complex component libraries it makes sense to me, but only as an escape hatch. We're rendering a single SVG, and the only real use-case I can think of for using part
s here is animating individual paths or creating differential coloring. I'll keep this issue open, and if others express a desire for it, maybe we'll add it.
Since there is not part exposed, there is no way to inject styles into the shadow dom without resorting to javascript or use some kind of wrapper. My use case was to set
display:block
on the svg element that was also wrapped with an anchor element, since it was messing the vertical alignment in a flex box container. Maybe I can just add anotherdisplay:flex
on the anchor wrapper and call it a day, but I think is pretty expected to expose a part api on a web component.