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

Clicking a submit button on it's top edge does not submit #545

Closed
rlewan opened this issue Aug 10, 2017 · 12 comments
Closed

Clicking a submit button on it's top edge does not submit #545

rlewan opened this issue Aug 10, 2017 · 12 comments

Comments

@rlewan
Copy link

rlewan commented Aug 10, 2017

Clicking an input type="submit" button stylised with the button CSS class on it's top edge displays a click animation, but does not submit the form.

How would you expect it to work?

The form should be submitted as normal.

How does it work currently?

The animation is displayed and element catches focus, but the click does not actually happen. Form is not submitted.

Explain the steps to reproduce the bug

  1. Go to any form with input type="submit" class="button",
  2. Click the button in it's top edge -- slide the mouse pointer down from above the button, click just as the pointer graphic changes from arrow to the pointing finger.

Tell us about your environment

  • Version used: 3.0.2
  • Browser Name and version: Google Chrome 60.0.3112.90
  • Operating System and version (desktop or mobile): macOS Sierra 10.12.6
@andymantell
Copy link
Contributor

After initial investigation on the x-gov slack channel it looks like it's caused by the top: 2px that gets applied to the button when it is :active. So what is happening is that as soon as you mousedown, the button moves out the way and you are no longer on top of the button. I can't find the page I was reading, but it seems that the browser defines a click as a mousedown and a mouseup on the element. Because the button slinks out the way, you only get the mousedown half, and therefore no click.

Couple of options as I see it:

  1. Find another way of achieving this movement without moving the hit area of the button
  2. Change the design so that the button doesn't move like this

@fofr
Copy link
Contributor

fofr commented Aug 10, 2017

button-problem

@quis
Copy link
Member

quis commented Aug 10, 2017

Using transform: translate(0, 2px) instead of top: 2px seems to have the same problem.

Edit: and margin: 2px 0 -2px 0 also has the same problem.

@fofr
Copy link
Contributor

fofr commented Aug 10, 2017

Doesn't seem to be a problem here (same animation, not using Elements):
Button as link: https://www.gov.uk/apply-renew-passport
Button element: https://www.gov.uk/check-uk-visa/y

(Making the button element an input type submit, the issue occurs on GOV.UK too)

@adamliptrot-oc
Copy link

Looks like the example in @fofr comment uses a pseudo element to maintain the click area

@kr8n3r
Copy link

kr8n3r commented Aug 11, 2017

there seems to be a communal x-gov effort. When someone has a feasible solution, can they submit a PR please?

@quis
Copy link
Member

quis commented Feb 1, 2018

Here’s the relevant CSS being used in the GOV.UK links @fofr posted:

.button {
   position: relative;
}

.button:before {
    content: "";
    height: 110%;
    width: 100%;
    display: block;
    background: transparent;
    position: absolute;
    top: 0;
    left: 0;
}

.button:active:before {
    top: -10%;
    height: 120%;
}

…which comes from here in the Frontend Toolkit: https://github.com/alphagov/govuk_frontend_toolkit/blob/9abfaf9d2236a628aadc05244a7dd6ae8024505a/stylesheets/design-patterns/_buttons.scss#L108

…which was introduced in this commit by @timpaul: alphagov/govuk_frontend_toolkit@24e1906

@quis
Copy link
Member

quis commented Feb 1, 2018

OK, I’ve narrowed it down.

Not buggy

<button type='submit'>Save</button>

Buggy

<input type='submit' value='Save'>


The problem is that, for some reason, <input type='submit'> doesn’t support pseudo elements.

The reason to use <input> over <button> is because of IE6 not submitting the <value> of a button to the server. This doesn’t feel like a good enough reason to prefer <input> in 2018.

@36degrees
Copy link
Contributor

Yep, input elements are empty elements which means they do not support pseudo elements.

Worth noting that there's a bug in IE7 too which could cause confusing behaviour:

IE7 has a bug where when submitting a form with Click me, the POST data sent will result in myButton=Click me instead of myButton=foo.

- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Notes

This is something I've been thinking about for GOV.UK Frontend - at the minute our behaviour is to prefer inputs unless the user specifies HTML content, in which case we then opt for <button>. Do we think this behaviour is enough to change that and prefer buttons unless the user specifically asks for an input?

@36degrees
Copy link
Contributor

36degrees commented Feb 1, 2018

For reference, the corresponding fix in Frontend is here and the logic we use to build our examples is here.

quis added a commit to alphagov/notifications-admin that referenced this issue Feb 1, 2018
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.

We have historically[1] used `<input>` because it’s better-supported by
IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
  value (as in other browsers)

Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
  TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
  hack[2] used to ensure the top edge of the button is clickable doesn’t
  work. We’re seeing this bug[3] affect real users in research.

1. We inhereted our buttons from Digital Marketplace, here is me making
   that change in their code:  Crown-Commercial-Service/digitalmarketplace-frontend-toolkit@8df7e2e#diff-b1420f7b7a25657d849edf90a70ef541
2. alphagov/govuk_frontend_toolkit@24e1906#diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79

3. alphagov/govuk_elements#545
quis added a commit to alphagov/notifications-admin that referenced this issue Feb 1, 2018
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.

We have historically[1] used `<input>` because it’s better-supported by
IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
  value (as in other browsers)

Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
  TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
  hack[2] used to ensure the top edge of the button is clickable doesn’t
  work. We’re seeing this bug[3] affect real users in research.

1. We inhereted our buttons from Digital Marketplace, here is me making
   that change in their code:  Crown-Commercial-Service/digitalmarketplace-frontend-toolkit@8df7e2e#diff-b1420f7b7a25657d849edf90a70ef541
2. alphagov/govuk_frontend_toolkit@24e1906#diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79

3. alphagov/govuk_elements#545
quis added a commit to quis/govuk_elements that referenced this issue Feb 1, 2018
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.

Historically `<input>` has been preferred because it’s better-supported
by IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
  value (as in other browsers)

Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
  TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
  hack[1] used to ensure the top edge of the button is clickable doesn’t
  work.

Fixes alphagov#545

1. alphagov/govuk_frontend_toolkit@24e1906#diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79
@quis
Copy link
Member

quis commented Feb 1, 2018

@36degrees having just watched a user stumble into this bug in research, I think <button> by default is preferable.

@36degrees
Copy link
Contributor

@quis That's really valuable feedback, thanks.

quis added a commit that referenced this issue May 8, 2018
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.

Historically `<input>` has been preferred because it’s better-supported
by IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
  value (as in other browsers)

Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
  TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
  hack[1] used to ensure the top edge of the button is clickable doesn’t
  work.

Fixes #545

1. alphagov/govuk_frontend_toolkit@24e1906#diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79
@quis quis closed this as completed in #593 May 8, 2018
peteryates added a commit to x-govuk/govuk-form-builder that referenced this issue Jun 21, 2021
This should address the bug where `<input type="submit">` doesn't
register clicks when the very top of the element is clicked[0] and is
more in-line with the Design System guidance[1].

[0] alphagov/govuk_elements#545
[1] https://design-system.service.gov.uk/components/button/#default-buttons

Fixes #295
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants