ionic 4 UI components are not customizable enough, compiled list

Feature Request

Ionic version:

[x] 4.x

Current Behavior Ion-toggle only has 4 customizable Css properties, meaning that the background colors of the knob and the toggle (selected and unselected) are the only supported properties for editing.

Describe Preferred Solution In past versions, with the components not in the shadow DOM, they were highly customizable to provide great and easily editable UI. For example, placing custom border-radius on both the knob and the toggle are no longer possible. The same can also be said for components such as ion-radio. Because so much has been lost with this change, it would be nice if most (or at least more than 4 in the case of ion-toggle) CSS properties were exposed and could be set via variables.

Example of preferred solution given below:

Related Code ion-toggle { --handle-border-radius: 1px; --toggle-border-radius: 1px; }

Additional Context Would be great if the editable CSS properties for all UI elements could (at least) reach the level of ion-range.

[barocsi]

I think the github workflow for web components is a general flaw for such projects. The components are buggy and need a lot of customization, not only for a given context but due to the high number of use cases. There will be so many requests by the community that exposing everything through CSS properties will be impossible. Hence developers will fork, compile and use a web component for themselves in an isolated manner, so they will not push it back to the community due to the uniqueness of the case. Double loss.

I think the workflow of web components will need to change, githubs workflow is just not suitable for it.

Just imagine how many (almost ALL of The) times did you need to override the CSS of a component? The amount of variations will make the exposes css variables to converge to the number of CSS properties, because I am pretty sure on the long run someone will request it to be exposed.

[brandyscarney]

Thanks for the feedback! We’re working with what we have available now in terms of CSS features and support. We agree that the current state of CSS could use some improvement, and improvements are already underway. Chrome 73 actually just shipped with the :part feature which would solve a lot of these problems. See the spec on CSS parts here: https://www.w3.org/TR/css-shadow-parts-1/ and here’s a blog that explains it a bit better: https://meowni.ca/posts/part-theme-explainer/

Basically, the :part feature will allow users to target the internal parts of shadow components without having to expose CSS variables for everything. However, until we find a way to polyfill the missing CSS features for unsupported browsers, we are using CSS variables and what we have available to allow customization. We’re always open to suggestions and ideas and we are always actively looking to improve. We recently started working to use constructable stylesheets and have found that the API solves some big problems for us, such as:

• Performance and memory improvements
• The loading of relative resources within the CSS
• Hot Replacement of CSS within shadow-dom
• Sharing global CSS across shadow-dom boundaries

We’re doing our best to review issues and pull requests and merge what we can, but we have a small team and a lot of the time the pull request requires us to make or request changes which can cause a back and forth interaction before it can be merged. We love and appreciate the community’s help reporting issues and creating pull requests though as it brings missing things to our attention and gives us a push to get them added in faster.