-
Notifications
You must be signed in to change notification settings - Fork 20
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: b1e0b00 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.06 kB (+1%) Total Size: 209 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 |
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.