Skip to content
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

Change month nav buttons to be divs with role="button" #1305

Merged
merged 1 commit into from
Aug 14, 2018

Conversation

majapw
Copy link
Collaborator

@majapw majapw commented Aug 13, 2018

Custom month nav buttons are not currently clickable in Firefox. Changing them to divs addresses the problem. This is due to the difference in treatment of button elements by Firefox (absolutely positioned children of elements that are rendered outside of the visually are not interactive).

Separately, this work highlighted the fact that custom month navigation does not currently have a focus ring. That is something not addressed by this commit but which will be investigated in the near future. I have opened an issue here: #1304.

Fixes #1303

to: @ha1ogen @noratarano @ljharb @backwardok @garrettberg

@majapw majapw added the semver-patch: fixes/refactors/etc Anything that's not major or minor. label Aug 13, 2018
@coveralls
Copy link

coveralls commented Aug 13, 2018

Coverage Status

Coverage decreased (-0.2%) to 84.632% when pulling d35a736 on maja-address-unclickable-custom-nav-in-FF into dcb346e on master.

@@ -283,11 +293,13 @@ export default withStyles(({ reactDates: { color, zIndex } }) => ({
height: 19,
width: 19,
fill: color.core.grayLight,
display: 'block',

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be inline-block to match the default for button?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto what garrett said

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is on the svg itself, not on the button and ... this is the display value that is needed for the height to remain the same in the before/after 🤷‍♀️ Otherwise there is some weird padding below the arrows.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(in Firefox)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed, inline-block does not address the issue. I think it has to do with the svg itself?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah ok didn't realized this was applied to the svg - this seems fine

aria-label={phrases.jumpToPrevMonth}
onClick={onPrevMonthClick}
onKeyDown={(e) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably better to use onKeyUp here instead

@@ -283,11 +293,13 @@ export default withStyles(({ reactDates: { color, zIndex } }) => ({
height: 19,
width: 19,
fill: color.core.grayLight,
display: 'block',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto what garrett said

@@ -115,7 +115,9 @@ function DayPickerNavigation({
)}
>
{!isVerticalScrollable && (
<button
<div
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how much CSS you want to remove (also not sure if you ever think you'll turn this back to a button in the future), but now that this is a div, there's a lot of CSS that's no longer necessary

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm very confused why a "div that you're marking as being a button" is better than "a semantically correct button element" :-/

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljharb Did you read my description? The whole point is that with the way the custom button code is currently set up (the navPrev/navNext props), custom month navigation DOES NOT WORK (literally you cannot navigate months) in Firefox. This is specifically because of the way Firefox handles button elements. I don't know that we'll want to keep this forever but this div with a button role addresses the issue and still satisfies accessibility criteria. This is worth revisiting (and as I mentioned there still exists an issue with there being no visible outline) but we need to fix this right now.

Copy link
Collaborator Author

@majapw majapw Aug 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@backwardok I think I actually do want to keep the css

    cursor: 'pointer',
    userSelect: 'none',
    border: 0,
    padding: 0,
    margin: 0,

is all there is and I think we still want those things.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

border, padding, and margin don't need to be set on divs because they don't have those things set by default

Custom month nav buttons are not currently clickable in Firefox. Changing them to divs addresses the problem. This is due to the difference in treatment of button elements by Firefox (absolutely positioned children of <button> elements that are rendered outside of the <button> visually are not interactive).

Separately, this work highlighted the fact that custom month navigation does not currently have a focus ring. That is something not addressed by this commit but which will be investigated in the near future.
@majapw majapw force-pushed the maja-address-unclickable-custom-nav-in-FF branch from 23d0d58 to d35a736 Compare August 14, 2018 17:29
@majapw
Copy link
Collaborator Author

majapw commented Aug 14, 2018

@backwardok @ljharb @garrettberg I've changed the onKeyDown to be onKeyUp. Can you please take another look? :)

Copy link
Contributor

@backwardok backwardok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable

@majapw majapw merged commit 70eae98 into master Aug 14, 2018
@majapw majapw deleted the maja-address-unclickable-custom-nav-in-FF branch August 14, 2018 19:43
@afercia
Copy link

afercia commented Sep 29, 2018

Hello. In the WordPress Gutenberg editor project we're trying to use DayPickerSingleDateController (see WordPress/gutenberg#7621) and at the moment it's still using 17.1.1. In fact, in the Gutenberg implementation these buttons are still <button> elements. I'm not able to reproduce the original bug, for me the buttons are perfectly actionable with both mouse and keyboard, at least in Firefox 62 on mac. Out of curiosity, was the bug triggered under some special condition or configuration or anything else I may be missing? Thanks! /Cc @majapw

@majapw
Copy link
Collaborator Author

majapw commented Sep 30, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver-patch: fixes/refactors/etc Anything that's not major or minor.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants