Conversation
|
|
@garethbowen Whenever you get a moment, could you please review this? Thank you so much! |
garethbowen
left a comment
There was a problem hiding this comment.
So nice to clean this up, thanks!
One suggestion about the right cursor for disabled elements, but approved to unblock.
| .p-datepicker-input:disabled + .p-datepicker-input-icon-container, | ||
| .p-inputtext:disabled, | ||
| .p-inputtext:read-only, | ||
| .p-button:disabled { |
There was a problem hiding this comment.
Is cursor: not-allowed the right style here? I think that it's more for things where you don't have permission, and we should use cursor: default instead. What do you think?
| } | ||
|
|
||
| .p-button:disabled { | ||
| cursor: not-allowed; |
Closes #588
I have verified this PR works in these browsers (latest versions):
What else has been done to verify that this works as intended?
Expand to see before (right) and after (left) the change.
Why is this the best possible solution? Were any other approaches considered?
Creating a custom OdkDialog wrapper adds unnecessary boilerplate (manually passing slots, props, and emitted events) with minimal structural benefit, as each dialog still requires unique internal layouts for the header, body, and footer.
We leveraged odkThemePreset to globally apply the dialog "skin".
For those other common styles that cannot be defined in the preset, they are extracted into the global primevue.scss.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Nothing
Do we need any specific form for testing your changes? If so, please attach one.
No
What's changed