Hey @pemberdom - this has actually come up before and we decided to not proceed with a PR to adjust how it works: https://github.com/Esri/calcite-components/pull/320 / https://github.com/Esri/calcite-components/issues/319
Leaving open for discussion, maybe we should revisit that?
My bad, I didn't see those discussions.
The workaround is a one line code, but my vote would go for handling it, or at least mentioning the current behavior in the doc given it's not consistent with the native button's behavior?
@pemberdom no problem, they were closed after all!
@driskull @AdelheidF this came up again - maybe revisit?
The only valid use case I could think of for running an onClick on a disabled button would be for analytics but, even that seems "edge-casey".
Went through the discussion since this is not obvious unless documented. Also suggest that we follow the native behavior, don't allow calcite elements to trigger events when they are disabled.
So when using calcite-button, calicite-input , calcite-select, calcite-combo-box user can work with them as they would with the native counterparts, otherwise there is some learning here.
Maybe we should try to see if it will work without being too difficult. We would just need to suppress any onclick props and listeners assigned to the custom node without removing them entirely incase disabled is removed.
I've been in the same ⛵ in a few web apps I've been building recently and have been using this global CSS rule to get the desired effect (at least as of around version 1.0.0-beta.20 before calcite-tooltips changed).
I'm only pasting it here for the sake of research breadcrumbs if anyone else from the consumer-dev perspective is looking into this later on down the line.
/*
block click events for disabled calcite-buttons
also use the ":active" pseudo-class to block clicks but NOT block hover functionality for any associated calcite-tooltip
*/
calcite-button[disabled]:active {
pointer-events: none;
}
@jwasilgeo that will work for clicks but (I think) you'd still be able to tab to the button to focus and space / enter would still run an onclick function if present.
Based on how many folks have been affected by this, I think we can just look at that PR #320 again, and solve for @driskull PR comment of checking for onclick added after mount (or, another solution). But seems worth changing.
Would the following work if someone uses component.addEventListener("onclick")?
this.el.getAttribute("onclick");
Would need some testing.
Disabled button should probably just get tabindex="-1" and pointer-events: none, right? Then it would behave like a standard button regardless of what onClick is.
Most helpful comment
Disabled button should probably just get
tabindex="-1"andpointer-events: none, right? Then it would behave like a standard button regardless of whatonClickis.