Closed vdh closed 7 years ago
@jgthms:
It seems to me that the disabled
attribute is not applicable to anchors as per the HTML5 standard.
However, you have changed examples to use the attribute on anchors.
This seems to be invalid (anyone, please correct me if I'm wrong).
I am under the impression that in order to style anchors as "disabled", the re-introduction of a corresponding CSS class is necessary.
The issue I raised technically only applied to form controls (buttons and inputs), I'm not quite sure why that change was also done for anchor tags.
@homeworkprod But even if a CSS class (or something like a[disabled] { pointer-events: none; }
) were (re)added, it wouldn't completely disable anchors. Keyboard events will still be able to interact with them. Unfortunately, AFAIK the only way to completely disable anchors in the current spec is to bind a Javascript click event handler that calls event.preventDefault();
.
Yes this is still an issue in regard to anchors.
Still issue (with anchors) in 2018. If anyone comes here, check the status at https://github.com/jgthms/bulma/issues/885
This is a two edged sword. By not relying on a class, you cannot click things inside the disabled element. For example we have an input box that is disabled, but when clicking the little lock which is INSIDE the input box, we want to enable it.
Cannot do that if disabled is a property of the input box, as the browser blocks onclick events.
I think using an invalid attribute (disabled
on an a
tag) instead of a regular class is enough of a reason to bring back the is-disabled
class, but there are valid reasons to bring back that is-disabled
class even for elements where disabled
is a valid attribute.
For example, I'd like to style a button as disabled until a certain condition is met. However, when the user clicks on the disabled button, I would like to let them know exactly why it has been disabled. Right now I can't do that, because the only way to style the button as disabled it to use the disabled
attribute, which means I can't respond to click events.
I think keeping the is-disabled
class but not disabling pointer events would be the best solution. Let the programmer handle the functionality, and let Bulma handle the styling.
For elements that actually have disabled
attributes, I think it would be redundant to also require the is-disabled
class. The same disabled styles can be applied to elements with the is-disabled
class or the disabled
attribute, but the programmer can decide which to use based on the functionality they want.
I agree with the other commentors here that Bulma shouldn't be trying to intefere with the programming/logic and interaction side of things here. Keep it purely style-based. As it is, this attribute nonsense completely breaks modern frameworks like Angular and React. Just bring back is-disabled
as a CSS class and be done with it. No pointer hacks, no attributes, just plain CSS styling class.
I was unpleasantly surprised to see the ".is-disabled" being deprecated in Bulma. [disabled] introduces lots of accessibility issues when used in most scenarios.
Here's a great article about this: https://www.smashingmagazine.com/2021/08/frustrating-design-patterns-disabled-buttons/
It breaks keyboard navigation, making it a nightmare for accessibility.
There are literally just a few instances where it's okay to use [disabled]. In the majority of cases, you should not use it.
Checklist
Description
The
pointer-events: none
styles being used on.is-disabled
or.button[disabled]
selectors breaks any title/alt properties applied to button tags, and also prevents thecursor: not-allowed
style from being applied to the button..is-disabled
on=control
: sass/utilities/controls.sass:30.is-disabled
on%control-with-element
: sass/elements/form.sass:53, sass/elements/form.sass:55.is-disabled
: sass/base/helpers.sass:98.is-loading
usespointer-events: none
as a hack to disable buttons: sass/elements/button.sass:106I think it's a dangerous precedent to rely on
pointer-events
to control browser behaviour for disabling form controls. Thedisabled
property is the more accurate and reliable way to disable a control. I can see how using this CSS style could make it easier to disable multiple elements at once by applying theis-disabled
class and cascade it down to child elements, but that behaviour could be replicated with a disabledfieldset
.As noted on the MDN article about
pointer-events
:So without a dedicated
disabled
property, buttons and controls could still potentially be interacted with by non-mouse events such as keyboard input, or browser plugins (e.g. autofill or spellcheck plugins)Steps to Reproduce
Expected behavior: When hovered over, the browser toggles the
not-allowed
cursor and shows the title text in a tooltip.Actual behavior: Both the tooltip and cursor style are not activated.