Drop the support of show property from the modal plugin.
When creating the new modal instance in v5, the `show` property does not work anymore, so instead of fixing the behavior just removing it permanently to keep the consistency between all the plugins. (All other plugins require the `show()` method to be called on the instances to be shown)
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
Update to the tooltip.js to add an aria-label attribute that contains the original title of the element, but only if the element doesn't have an existing aria-label attribute.
This is to address cases where screen readers are not capturing the aria-describedby attribute that is added when the tooltip is triggered. This should also avoid a race condition between the screen reader and the appearance of the tooltip.
Remove the default invisible gradient causing the performance issue in #32266. By removing the custom property, the linear gradient will become invalid, thus not appear by default.
There can still be a performance issue with striped tables though.
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
When using single-quotes in config.yml, the previous
regular expression in build/generate-cli.js wasn't working correctly,
it was replacing ALL string values with hashes.
Now both double- and single-quotes can be used in config.yml,
and the RegExp will work as expected.
Also, allow trailing whitespaces and empty ("") values to be matched.
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* Don't hide modal when config.keyboard is false
* Update unit test
- Modal should not be closed when pressing esc key if keyboard = false
and backdrop is 'static'
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
* Revert "Adapt to the recent main changes"
This reverts commit 50d8921670.
* Revert "Add Hugo Pipes logic for local and vendored scripts."
This reverts commit 3fcfd606f2.
* Revert "Use Hugo mounts for our docs vendor JS files."
This reverts commit 6b071116f3.
apart from the visual styling, there's probably no good reason why these shouldn't be `<button>` elements, semantically
the buttons still look a shade too button-like, despite using `.btn-light`. the last remnant of button styling can probably be suppressed further, *or* this makes the case for expanding the core button styles to have one that looks completely non-button and non-link like (for cases where an additional style/hint was given already, or it's clear from context that something's an actionable button or link)
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
