-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat(disclosure): add <rh-disclosure>
#2043
base: staging/cubone
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 1a7f3f0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for red-hat-design-system ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Size Change: +2.24 kB (+1.08%) Total Size: 210 kB
ℹ️ View Unchanged
|
I'm curious why you opted to make Late-2000s haute cuisine trends aside, it would be a touch annoying to order a burger and have the patty, buns, veg, and sauce, all come in separate containers with assembly instructions stapled to the bag. As custom-element authors, we should have the confidence to define our own behaviours. Tn other words, if if downstream teams "need" lightdom details (which is in my view an antipattern) what about making it opt-in? Elaborating on my position: we should make the maximum effort to avoid requiring lightdom which performs the same function. This is to gain maximum benefit from custom elements and shadow dom, namely encapsulation and interoperability. There have been and will likely continue to be instances where the state of the art gives us no choice, for example I suspect that pfe's radio and checkbox elements will have to manage their own lightdom, although I'm concerned that this might break under the control of "VDOMs" like react. In the future, when reference targets, aria IDL attributes, more ElementInternals apis, and improvements to In the case of disclosure though, I haven't yet seen the show-stopping must-have requirement that the So all that in mind, I challenge you to imagine a disclosure element in which |
consider <sl-details summary="Toggle Me">
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
</sl-details> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So that it works with JavaScript disabled, avoids FOUC, and drives adoption. (see this draft PR demo of Universal Nav with shadowdom'ed We thought that rh-disclosure might be used for Your opt-in example is indeed interesting and something I'd be willing to pursue if we decide that path is our way forward. If that's not amenable, then I would probably do something similar to what |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
Light theme focus ring color should use
--rh-color-interactive-primary-default-on-light
for active and focus states.
-
When the disclosure is expanded, it's showing a 24px space between the summary slot and the body content. According to our Figma file, it should be 32px (
--rh-space-2xl
). The Figma file's been updated more recently than the disclosure docs page, so apologies for the inconsistency there!
@marionnegp I used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Focus ring changes look good!
I wanted to check the focus ring in the nested disclosures, so I wrapped that demo with <rh-surface>
. I noticed that not everything ended up being themed correctly. (Links aren't light blue and the third nested disclosure's caret icon is black.) Is this expected based on how <rh-surface>
works (maybe I used it wrong), or is it a bug?
Links aren't light blueThis is expected behavior. It's the responsibility of the page author to style elements in the lightdom. eg: The third nested disclosure's caret icon is blackI could not reproduce this. See the screenshot below. The caret color stays the same across all disclosures and doesn't change if one is nested. Double check if it's still happening for you. If it is, kindly share some steps to reproduce and I will be happy to look into it. Thanks for all your feedback! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry one more thing! Disclosure should use the same interaction state styles as accordion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
What I did
<rh-disclosure>
elementTesting Instructions
<rh-disclosure>
demo on the DP.To do's
main
👉staging/cubone
+ diffNotes to Reviewers
This element is lightdom based. We're planning to use it standalone as<rh-disclosure>
and also using it in<rh-navigation-XYZ>
for dropdowns.Shout out to @zeroedin for the initial concept.
Closes #1293.