Use CSS parts for customization?

[anderssonjohan]

Allowing people to modify the MDC properties directly would remove a bit of the purpose with the component encapsulation, but sometimes you want to have more open interfaces that allows the user to customize some internal parts of a component.

One example of such component is the limel-icon-button that consists of an MDC button with a lime-icon component inside. To expose all the properties of the limel-icon component, the limel-icon-button component need to export all these properties and also keep these updated if a new property is added to the limel-icon component.

If one want to add a custom CSS transform to the limel-icon component, it's possible to do so, but one can't do that with the limel-icon existing inside the limel-icon-button component. One approach to solve this would be to add CSS parts like <limel-icon part="icon" .../> to the icon inside the button. This could then be styled using a selector such as limel-icon-button::part(icon). The code using a component is by this attribute given access to an internal part of the component so it can be styled without the need of exporting/forwarding all the available properties of the internal component.

Note: The ::part() selector is now available in all major browsers, but could be too new as of today to use?

A recent article about this selector for more reading: https://css-tricks.com/styling-in-the-shadow-dom-with-css-shadow-parts/

If this is something we should allow it should also be a part of Kompendium so the docs lists all available parts of a component that can be styled from "outside of the shadow DOM".

Environment

• lime-elements version:
• Framework used:
• Logs:

[adrianschmidt]

This sounds very interesting! Perhaps we could team up with @Kiarokh for a day during cooldown to experiment a little with this?

Regarding browser support: For Lime CRM Web Client, we really only support the latest browsers, with primary focus on the latest version of Chrome for desktop OS:es, Safari on iOS, and Chrome on Android. We can do that since we're not making a public facing website, and can basically set "latest Chrome" as a requirement for the software.

But lime-elements should have wider support than that. For example, eSign uses lime-elements in their public facing portal, and obviously, they can't just dictate that someone should use a specific browser to sign a document they received from one of our eSign customers. Exactly how wide support we need to have, and to what extent graceful (or less graceful) degradation is ok, we still need to figure out.

The alternative is of course to more strictly limit the browser support of lime-elements, and say that applications with a need for wide browser support should either not use lime-elements or only use it for progressive enhancement and take care of any wider support themselves.

But it seems to me like ::part() should simply be something that isn't applied if not supported by the browser, right? So if we build in support for that in limel-icon-button, it would only mean you don't get the new functionality in an older browser, not that limel-icon-button no longer works in an older browser. If that's the case, then consumers of lime-elements with a need for wide browser support will just have to either not use that selector for styling, or use it in a way that degrades gracefully.

[Kiarokh]

This is awesome! Just a couple of days ago I heard about ::part; but that vanished in the heat of my conversation, so I never followed it up. Great that you mention it now! This is super interesting and would be great to utilize in Lime Elements.

I agree with Adrian's analysis. We can't limit vital functionalities of Lime Elements, unfortunately. But it works for things which have less risk –like this use case– which we have probably no other or easy way to address.

I'm up for the experiments ;)