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

pointer-events styles breaks title prop and cursor styles on disabled buttons #276

Closed
vdh opened this Issue Jul 28, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@vdh

vdh commented Jul 28, 2016

Checklist

  • I'm using Bulma version [0.1.0]
  • My browser is: Chrome 52.0.2743.82 (64-bit)

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 the cursor: not-allowed style from being applied to the button.

I think it's a dangerous precedent to rely on pointer-events to control browser behaviour for disabling form controls. The disabled 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 the is-disabled class and cascade it down to child elements, but that behaviour could be replicated with a disabled fieldset.

As noted on the MDN article about pointer-events:

Note that preventing an element from being the target of mouse events by using pointer-events does not necessarily mean that mouse event listeners on that element cannot or will not be triggered.
[…]

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

<button class="button is-disabled" title="Cannot remove the last item" disabled type="button">
  Remove
</button>

<!-- Or wrapped in a control -->
<div class="control is-disabled" title="Cannot remove the last set">
  <button class="button" disabled type="button">
    Remove
  </button>
</div>

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.

@jgthms jgthms self-assigned this Mar 27, 2017

@jgthms

This comment has been minimized.

Show comment
Hide comment
@jgthms

jgthms Apr 1, 2017

Owner

Fixed by #615

Owner

jgthms commented Apr 1, 2017

Fixed by #615

@jgthms jgthms closed this Apr 1, 2017

textbook added a commit to textbook/bulrush that referenced this issue May 15, 2017

textbook added a commit to textbook/bulrush that referenced this issue May 15, 2017

@homeworkprod

This comment has been minimized.

Show comment
Hide comment
@homeworkprod

homeworkprod Aug 27, 2017

@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.

homeworkprod commented Aug 27, 2017

@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.

@vdh

This comment has been minimized.

Show comment
Hide comment
@vdh

vdh Aug 30, 2017

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();.

vdh commented Aug 30, 2017

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();.

@markedro

This comment has been minimized.

Show comment
Hide comment
@markedro

markedro Sep 8, 2017

Is this getting reverted back specifically on the tags? disabled doesn't appear to be considered as a valid attribute for anchors. It does appear that if disabled gets hard coded to an anchor directly when defining that, yes the element seems to show in a "disabled" state but subsequently it isn't able to be programmatically enabled / disabled beyond its original definition which means you are stuck with having to specifically define 2 separate anchors (specifically one enabled and one disabled) and then perform some type of show/hide toggle between them which is very sub-optimal. Or is there something I'm missing?

markedro commented Sep 8, 2017

Is this getting reverted back specifically on the tags? disabled doesn't appear to be considered as a valid attribute for anchors. It does appear that if disabled gets hard coded to an anchor directly when defining that, yes the element seems to show in a "disabled" state but subsequently it isn't able to be programmatically enabled / disabled beyond its original definition which means you are stuck with having to specifically define 2 separate anchors (specifically one enabled and one disabled) and then perform some type of show/hide toggle between them which is very sub-optimal. Or is there something I'm missing?

@janat08

This comment has been minimized.

Show comment
Hide comment
@janat08

janat08 Feb 27, 2018

Yes this is still an issue in regard to anchors.

janat08 commented Feb 27, 2018

Yes this is still an issue in regard to anchors.

@hovancik

This comment has been minimized.

Show comment
Hide comment
@hovancik

hovancik Jul 26, 2018

Still issue (with anchors) in 2018. If anyone comes here, check the status at #885

hovancik commented Jul 26, 2018

Still issue (with anchors) in 2018. If anyone comes here, check the status at #885

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment