Move user_input_methods guide

[estelle]

Move guide per openwebdocs/project#185
Update guide to remove prefixing, "not supported", and "modern web" lingo
Update text to encourage supporting all input types all the time for good UX.
updated links to page.

[github-actions]

Preview URLs

• /en-US/docs/Learn/Forms/User_input_methods
• /en-US/docs/Learn/Forms
• /en-US/docs/Web/Guide

Flaws (1)

Note! 2 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Learn/Forms/User_input_methods
Title: User input methods and controls
Flaw count: 1

• broken_links:
  • Can't resolve /en-US/docs/Web/Accessibility/ARIA/Roles/

(comment last updated: 2023-12-06 16:32:43)

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[teoli2003]

Drive-by change proposal (I need to check if it fits the "module" structure of that Learn section; not an expert in LA so if @wbamberg or @chrisdavidmills can have a look too, it would be nice)

[teoli2003]

Also, the broken link to orientationchange may be to: https://developer.mozilla.org/en-US/docs/Web/API/Screen/orientationchange_event.

But it is marked as deprecated and is marked only supported by Firefox for Android.

I think the modern standard way is to listen to the change event on ScreenOrientation: https://developer.mozilla.org/en-US/docs/Web/API/ScreenOrientation/change_event

[chrisdavidmills]

I don't think this fits under forms and the learning area at all. Looking at the content, it doesn't mention forms; it is much more about events.

In which case, wouldn't https://developer.mozilla.org/en-US/docs/Web/Events be a better place to move it?

[estelle]

i rewrote it to make it form related as we really, really need this information in the HTML section, and it fits best under forms.

[chrisdavidmills]

@estelle thanks for the work in making this fit better into the form module. I have some suggestions on how the page can be further improved, but I think this is getting close.

[chrisdavidmills]

This largely feels not relevant to form content and therefore comes off a bit weird. Suggestions include:

• Maybe presenting it as a note, so it feels like more of an aside.
• Removing the example of content editable, as that really isn't relevant to form elements
• Removing pointer lock as an example, as that doesn't feel relevant to forms either
• Talking about screen orientation and and fullscreen in the context of kiosk-style apps?

With at least some of those items done, I think it would work better. Let me know what you think.

[estelle]

Reworded it, and removed the links: made it more of an intro to the next section rather than a summary. keeping content editable because it is a necessary feature in creating custom form controls. dropped pointer lock.

[chrisdavidmills]

Cool, this reads much better

[estelle]

@teoli2003 @chrisdavidmills Thanks. Ready and needing a re-review from both of you.

The article has been rewritten and Chris is doing the review.

[chrisdavidmills]

@estelle more suggestions for you. This is looking much better now, thanks so much for your hard work on this. I have approved so that you can get it merged after dealing with my latest round.