-
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: 5c8d706 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: +1.02 kB (+0.48%) Total Size: 212 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 |
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.