-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-shadow-parts-1] feedback from devs #3467
Comments
::part feedback + thoughtsBelow are thoughts, questions, and general feedback from the SLDS Framework team regarding the currently implemented in Chrome. We're experimenting a little further with slots and some more complex examples, so I expect we'll add a couple other questions with examples. FeedbackAccess controlIt would be very useful if it was possible to limit access to CSS rules for a defined part. The purpose is to limit the styling API of a component by only allowing certain things to be overridden or to lock down certain things that should never be overridden. In the example below “part='title'” is defined but only “color” and “background-color” can be overridden, all other rules would be ignored. We envision allow all by default with the possibility to allow or deny specific lists of CSS rules.
In the example below “part='title'” is defined but “color” and “background-color” are locked, all other rules would apply and override the component's default styles.
Limited ::theme selectorThe current description of the ::theme selector is perhaps a bit too broad for real world usage. However the ability to access any ::part within the context of a component, without elaborate In the example below, a theme context is defined for
Web Component default exportparts=When building a custom web component via composition not having to explicitly specify The example below presents a possible solution where, at component creation,
QuestionsDynamic exportparts=Would it be possible to dynamically set the value of
::before and ::after pseudo elementsIt appears the
|
This spec is not my main area of expertise, so I'll refrain from commenting on the substance until I've studied it further, but a comment on the form: usually things are much easier to process when there's one "issue" per github issue. If you want to have a master issue that links to all of them, that's fine, and we can cross link as needed, but splitting each topic into its own issue lets the CSSWG get to the bottom of each one by one, track their status independently, assign them, schedule them for discussion in teleconfs, etc. I've reposted each point from @stefsullrew's comment (#3467 (comment)) into separate issues:
|
Thanks so much, Florian. |
Thanks @frivoal I understand your point about having separate issues and thanks for analyzing the content and creating them. The reason I created this general issue is that I was trying to get as much feedback as possible, including feedback that was purely supportive of the existing spec (for purposes of launching). I think it's easier for people to leave feedback (especially positive feedback) in a more narrative and less precise form. A github issue isn't the ideal way to do this but I'm not sure what would be a better open forum. |
I've been struggling with shadow parts for a little while now in a project with many nested web components that we want to provide external styling for. The current definition requires a lot of bloated extra code for us to achieve external styling possibilities. exportpartsFor nested components, this is very messy way of making sure everything is exported all the way to the root. A general simpler (default) way would increase the developer experience a lot. As a workaround to avoid maintenance hell, we are using a mixin that finds parts and exportparts in the subtree and forwards them on the component if needed. parts are not selectable within the shadow domWhen defining a part name, why not make it selectable from stylesheets within the shadow dom? To select a part you have to use something like part names vs class namesFor us, the part names and our class names have the same semantical meaning and we don't want to repeat the names in two attributes like Use ShadowRoot mode settingsIt would be great if the exportparts were aligned with the mode provided for the shadow root, so that part names were accessible the same way as the shadow dom nodes are accessible in javascript via closed or open. |
spec
I've created this issue as a place to log feedback from developers who have tried using shadow parts. Even if there are features missing, knowing that the basic shape of the API is right and e.g. already works well for some set of components is useful.
The text was updated successfully, but these errors were encountered: