add custom value for show() function for p5.Elements #7388

[rbottura]

Increasing access

we could deal with flex-type elements, and be able to toggle there visibility with a simple show('flex'). Or with a combined use with hide(), store the initial display value in p5.Element memory and re-use it when calling show() on same element.

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)

Feature enhancement details

p5.Element.prototype.show = function (value = 'block') {
  // List of valid CSS display values
  const validDisplayValues = [
    'block', 'inline', 'inline-block', 'flex', 'inline-flex', 'grid',
    'inline-grid', 'table', 'table-row', 'table-cell', 'contents', 'list-item', 
    'none', 'initial', 'inherit', 'unset', 'run-in', 'ruby', 'ruby-base', 
    'ruby-text', 'ruby-base-container', 'ruby-text-container'
  ];

  if (validDisplayValues.includes(value)) {
    this.elt.style.display = value;
  } else {
    console.error(`Invalid value for displaying element: "${value}"`);
  }

  return this;
};

[wayneharish10]

Hi! Can I work on this enhancement request. I consider myself a newbie to open source and to p5.js for that matter. And I'd do good with a little bit of help.

[rbottura]

Sure, I'd like also to become a contributor to the library, I have a few blocks of code i'd like to see in the lib and as addons. Maybe we wait for a steward for a review, go free with this one I see you already forked the lib, may be a merge request on main with this implementation would go faster, idk

[wayneharish10]

Thank you! I think we might need approval from at least 1 steward before we start the work, as this is feature enhancement. Let's see.

[davepagurek]

I think something like this makes sense, @limzykenneth how do you feel about the proposed API here?

[limzykenneth]

I'm thinking whether block is a good default or would initial be better, or maybe one of the other reverting ones, would need to consider edge cases if so though. For the implementation itself, there's no need to check within the code valid CSS value for display, it can be checked by FES if necessary.

[rbottura]

I forked the library to make tests with the 'style' function to go through the _validateParameters() process. That being said I'm having some troubles figuring the impletation of such built-in tools since I'm quite new with the architecture, but I'll get there !
As now, the code looks like this :

p5.Element.prototype.show = function (value) {
  // check if value is a valid value for display prop
  p5._validateParameters('show', arguments);
  //affect const diplayValue either passed-in value, previous value (different from none) or default;
  const displayValue = value || this._prevDisplay || 'revert';
  //apply value to object with p5 style function
  this.style('display', displayValue);
  return this;
};

p5.Element.prototype.hide = function () {
  // Store the current display style if not already set
  this._prevDisplay = this.style('display');
  // use p5 style to hide p5 elt
  this.style('display', 'none');
  return this;
};

This way I think it's more clear that we want to consider that the element we want to .show() had a (visible) display value different from block. If you some1 has advices on how to use _validateParameters on style or show functions would be really helpful !

[limzykenneth]

_validateParameters works based on the documentation and it may not work correctly for something attached to p5.Element at this stage, you can leave it out for now. In 2.0 we have a new system which we can integrate then.