[p5.js 2.0 RFC Proposal]: Replace deprecated keyCode functionality and docs with KeyboardEvent.code & KeyboardEvent.key web standard replacements

[RandomGamingDev]

Increasing access

Due to the deprecation of the keyCode in web standards as shown here and p5.js's reliance on it for keyboard input and all the doc's examples (at least those I've come in contact with) using them it's time to replace them with their KeyboardEvent.code & KeyboardEvent.key web standard replacements in order to guarantee the continued functioning of p5.js without having to.

Which types of changes would be made?

• Breaking change (Add-on libraries or sketches will work differently even if their code stays the same.)
• Systemic change (Many features or contributor workflows will be affected.)
• Overdue change (Modifications will be made that have been desirable for a long time.)
• Unsure (The community can help to determine the type of change.)

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

What's the problem?

keyCode is still the primary method of detecting key presses despite it being deprecated for a while now.

What's the solution?

Replace it with the KeyboardEvent.code & KeyboardEvent.key web standard replacements in order to guarantee the continued functioning of p5.js without having to.

Pros (updated based on community comments)

• Continued Support: Continued support by browsers who might remove support in the future
• Teaching Usage of Web Standards: Since a large part of p5.js is aimed at beginners we want to avoid teaching outdated and deprecated concepts like the keyCode.
• • Integration: Although we can keep keyCodes to maintain support with older libraries, not moving forward by adding official support and docs everywhere for the modern alternatives might mean losing the ability to intuitively integrate with libraries.

Cons (updated based on community comments)

• Work: It'll take some work to replace it when keyCodes shouldn't get removed from browsers for at least a couple years if not more than a decade.

Proposal status

Under review

[RandomGamingDev]

Note: This issue is related to #6798

[Vaivaswat2244]

Hey, I'd like to work on this. Can this be assigned?

[Vaivaswat2244]

hey, these are the proposed changes

// new implementation using KeyboardEvent.code
function keyPressed(event) {
  switch(event.code) {
    case 'ArrowLeft':
      break;
    case 'ArrowRight':
    break;
    case 'ArrowUp':
      break;
    case 'ArrowDown':
      break;
    case 'Space':
      break;
  }
}

// alternative of using KeyboardEvent.key
function keyPressed(event) {
  switch(event.key) {
    case 'ArrowLeft':
      break;
    case 'ArrowRight':
      break;
    case 'ArrowUp':
      break;
    case 'ArrowDown':
      break;
    case ' ':  // spacebar
      break;
  }
}

and regarding the sketches which already use keyCode functionality, this creates a compatability layer that maintains support for keyCode

p5.prototype._setProperty = function(prop, value) {
  this[prop] = value;
  if (prop === 'keyCode') {
    this.key = KeyboardEvent.keyFromCode(value); 
    this.code = KeyboardEvent.codeFromCode(value);
  }
};

also we can probably add warnings for for using keyCode to promote migration.

[davepagurek]

Thanks @Vaivaswat2244, I'll assign this to you!

I think since the property is deprecated, we can go ahead and implement what this issue is recommending. In addition to no longer using keyCode, we were planning on implementing this issue #6798 to change keyIsDown to allow the characters themselves to be passed in (and a draft PR #6993 has been open for a while starting to implement that.) Would you also be open to taking on that issue in addition to this, so that we can fully deprecate keyCode in p5?

Since code and key represent two distinct but both useful things (the physical key on the keyboard being pressed vs the value corresponding to that key, which might change depending on the mapping of the keyboard), maybe we could support both in keyIsDown? When I press the A key, the event has key: 'a' and code: 'KeyA', and it seems like in general the codes have a different format. So we may be able to track pressed keys and codes separately, and make keyIsDown work for whichever you pass in.