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

Form-associated? #15

Open
annevk opened this issue Jun 10, 2019 · 8 comments

Comments

Projects
None yet
5 participants
@annevk
Copy link

commented Jun 10, 2019

In native UI playing with a switch does not require confirmation. Settings are changed live. Is there precedent for that not happening?

I'm a bit worried we might end up encouraging some kind of UX pattern on the web that's not found in native by making this submittable.

@domenic

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

I've been thinking about this since you posted it and I believe I've managed to wrestle my intuitions into something coherent.

HTML form-associated elements tie up a lot of different functionalities into one. Things such as:

  • Being disableable
  • Being grouped into fieldsets (which can be disabled en masse)
  • Being associated with <label>s
  • Being resettable to their original states
  • Being able to be submitted to the server
  • Being subject to a submission/validation framework

(and probably more that are not as obvious from glancing at the spec, but that in practice authors depend on and use.)

The conflict here is that almost all of these are useful for switch, except for a couple. In particular, validation doesn't make too much sense. (But maybe custom validation still does?) And submission to the server encourages a pattern that doesn't align well with how switches are supposed to be used (according to the UX guidance linked in the explainer).

So I think the switch element should be form-associated, but I'm unsure whether it should have any submission value. I'd lean toward saying that it should have one: omitting it seems more likely to cause web developer confusion, and you can imagine it being useful to send the server the state of the switches alongside the state of other parts of the form (even if you also update the UI immediately, or send a quick out-of-band signal to the server, on switch change). But I'd like to hear more opinions.

If it does have a submission value, we should still have strong authoring guidance on making changes take place immediately. I'm just not sure whether omitting the submission value would encourage people to follow this guidance more.

@Dan503

This comment has been minimized.

Copy link

commented Jun 12, 2019

In this comment it was suggested that the toggle switch immediately submits after being toggled.
https://discourse.wicg.io/t/proposal-a-toggle-switch-control-element/3620/3

That would actually be an accessibility violation against 3.2.2 On Input.

You need to submit a form using AJAX to avoid breaking that criterion when submitting forms on user input. That requires JS.

@JonathanRowley

This comment has been minimized.

Copy link

commented Jun 12, 2019

To facilitate submission without JS you could inherit from <input type=“submit”> to make use of the form action attribute for a <switch> element?

Example:

<form>
    <input type="switch" formaction=“https://someurl.com/path” />
</form>

Alternative syntax (much like button):

<form>
    <switch formaction=“https://someurl.com/path”></switch>
</form>

Shadow DOM:

    <input type=“submit”  formaction=“https://someurl.com/path” />

Alternative Shadow DOM:

    <button type=“submit”  formaction=“https://someurl.com/path”></button>

Alternatively, you could inherit from a form element, omitting the need for the author to wrap the switch in a form element.

Example:

<switch method=“” action=“”></switch>

Shadow DOM:

<form method=“” action=“”>
    <input type=“submit” />
</form>
@domenic

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

None of those approaches get around the fundamental problem, though, that submitting a form is a full-page navigation that will throw away the current contents of the page. That isn't the behavior you want for a switch.

@annevk

This comment has been minimized.

Copy link
Author

commented Jun 12, 2019

The server could reply with a 206, but yeah. For progressive enhancement it should probably be submittable, even if weird from a "native" perspective. I think if there's some text to contract this with checkboxes and such this is all good from my perspective.

@Dan503

This comment has been minimized.

Copy link

commented Jun 12, 2019

HTML is supposed to be accessible by default so anything that suggests that it auto-submits when it changes isn't an option.

Not unless some fancy new native browser AJAX like functionality is also introduced. That would be opening a massive can of worms though that I don't think anyone wants to touch.

@JonathanRowley

This comment has been minimized.

Copy link

commented Jun 13, 2019

Anchor links auto submit a HTTP GET request when a user clicks on them. These are accessible elements. I would expect a toggle switch to perform a similar operation but allow POST, PATCH, PUT, DELETE etc as configurable HTTP request types.

So the question remains, would you expect to find a toggle switch as part of a form? why not use a checkbox instead? What semantics does a new toggle switch element inside a form give us?

I’m personally all for a toggle switch element but maybe not as a form element.

@scottaohara

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2019

I think this does come down to good author guidance being written for the swtich.

Native mobile usage and JavaScript powered custom ARIA role=switch controls have largely created a precedent for instant submission (though from an a11y semantics standpoint role=switch still has some quirky support, which my hope is this element gaining traction would help resolve).

However, there definitely is an argument to be made that a switch could still serve a purpose even within a more conventional form submission, and have author guidance to semantically differentiate it from a checkbox.

For instance, "I agree to the terms of service / privacy policy." That's a checkbox. That is a yes/no that upon form submission is a one time answer. A switch could be used within a form as an indicator of an option that users could change their mind on at a later point. e.g. "do you want to receive marketing emails?" No I don't. But, it will be available to me as a configurable option in the app's settings. I won't change that setting... but i could.

There could then also be author guidance to indicate that a switch could be used with JavaScript to provide instantaneous changes to a screen/document or as a global setting, outside of a standard form submission, ala a toggle button, which the ARIA specification also relates a role=switch to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.