Adopt ECMAScript modules

[a11ydoer]

In terms of the code review, i worked with @alflennik to derive the following:

• validated that that the addition of listitem.scrollIntoView({ block: 'nearest', inline: 'nearest' is working
• validated that the addition of the eslint-disable-line comments did in fact eliminate the lint error (although, there are notes on this below)

It is important to note that even though disabling the error did disable the error, it did not address the error in and of itself, and therefore cannot be a resolution to the issue at hand.

Thankfully @jugglinmike has created a PR that addresses the eslint errors. It can be found here: #2642

A more in-depth explanation is provided in the PR itself, but to provide a summary here:

Because of existing code sharing logic in the project, any iterations away from the existing logic will conflict with the current setup.

It makes sense to apply these changes in a PR separate from this one to address this holistically in the project and not just on this pattern in particular. Therefore keeping the logic the same for this patch.

If you are in alignment with the above, we can go ahead and merge it in for you :)

Originally posted by @aleenaloves in #2622 (comment)

[a11ydoer]

@alflennik @jugglinmike @jongund By any chance, do we know what is the current status of eslint errors in the updated listbox example? I appreciate any update on eslint errors.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Listbox example - ESlint error.

The full IRC log of that discussion

<jugglinmike> Subtopic: Listbox example - ESlint error
<jugglinmike> github: https://github.com//issues/2671
<jugglinmike> Alex_Flenniken: This was originally reported by Aleena, but we couldn't reproduce it. Since Aleena has moved on from Bocoup, I think we should close this
<Jem> https://github.com/w3c/aria-practices/wiki/Code-Guide
<jugglinmike> Matt_King: Let's make this issue about moving toward ECMAScript modules.
<jugglinmike> jugglinmike: I'll reframe the issue
<jugglinmike> Matt_King: Let's make it about using import declarations in the JavaScript where appropriate
<jugglinmike> end topic
<jugglinmike> RRSAgent, end topic
<RRSAgent> I'm logging. I don't understand 'end topic', jugglinmike. Try /msg RRSAgent help

[jugglinmike]

As discussed during today's meeting (notes posted above), we're going to use this issue to track the project's adoption of ECMAScript modules.

@mcking65 My GitHub account doesn't have the necessarily privileges to modify issues in this repository. Can you rename this one to, "Adopt ECMAScript modules"?

[mcking65]

@jugglinmike

Could you please outline the steps we need to take to resolve this issue?

[jugglinmike]

We discussed this plan a few months ago and agreed that it is no longer a priority. The trouble is that adopting ECMAScript modules would involve adding complexity to the contribution experience (in the form of a build step or a local development server), and the CG does no wish to do that at this time.

Further context: the current contribution experience entails loading source files directly into the browser from the hard drive. In terms of transport, this means using the file: protocol. However, web browsers do not necessarily load ECMAScript modules over the file: protocol. In order to maintain code that uses import declarations, we would either need to provide a build process which performed the "linking" step statically, or we would need to provide a web server so the files could be loaded over the http: protocol, instead.