Skip to content
This repository was archived by the owner on May 24, 2024. It is now read-only.

[terra-form-input][terra-form-textarea] Remove prop placeholder #3075

Merged
merged 18 commits into from
Jul 23, 2020

Conversation

pranav300
Copy link
Contributor

@pranav300 pranav300 commented Jul 12, 2020

Summary

This PR:

  • Deprecates prop placeholder from form-input and form-textarea
  • Removes/updates tests and examples using prop placeholder
  • Removes themeable variables:
    ** --terra-form-input-placeholder-color
    ** --terra-form-input-placeholder-font-style
    ** --terra-form-input-placeholder-disabled-color
    ** --terra-form-input-placeholder-disabled-font-style
    ** --terra-form-textarea-placeholder-color
    ** --terra-form-textarea-placeholder-font-style
    ** --terra-form-textarea-placeholder-disabled-color
    ** --terra-form-textarea-placeholder-disabled-font-style
  • Updates wdio snapshots in search-field for changes made in form-input

Closes #2992 along with #3078

Deployment Link

https://terra-core-deployed-pr-3075.herokuapp.com/

Testing

Additional Details

Thank you for contributing to Terra.
@cerner/terra

@mjhenkes mjhenkes temporarily deployed to terra-core-deployed-pr-3075 July 12, 2020 20:50 Inactive
@mjhenkes mjhenkes temporarily deployed to terra-core-deployed-pr-3075 July 13, 2020 19:39 Inactive
Comment on lines +151 to +153
if (attributes.placeholder) {
attributes.placeholder = null;
}
Copy link
Contributor

@StephenEsser StephenEsser Jul 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a more aggressive approach than we usually take. Generally we allow consumers to pass native attributes through the custom props even if they are not officially supported/listed on the documentation site. I think we'll need to document the input does not allow a placeholder (and why) since this is an explicit/strict detail. Otherwise we'll want to allow the placeholder to pass through as a custom prop, but not provide any first class API for it/log a warning if it is detected.

Copy link
Contributor Author

@pranav300 pranav300 Jul 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a Note on the doc pages for the component not allowing placeholder: c212ae8

Copy link
Member

@neilpfeiffer neilpfeiffer Jul 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@StephenEsser this is a special case where UX intentionally not only wants to discourage use of placeholders, but outright disallow it as an accessibility best practice so consumers aren't still reliant on using them, particularly if they don't have direct support from UX and able to get guidance. Documentation will be the best approach, I think as we continue to improve the docsite, having standout sections similar to Mozilla and W3C that calls out special details or best practice notes will be a good place to call this out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to being heavy handed. Let's document that this is the UX requirement though and that a passed in placeholder will be dropped.

@mjhenkes mjhenkes temporarily deployed to terra-core-deployed-pr-3075 July 14, 2020 08:10 Inactive
* Removed `placeholder` prop.

### Changed
* Updated UpgradeGuide
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should provide more detail about what the change to the upgrade guide implies. What was updated/added/changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update here ad81efd.

@@ -5,7 +5,7 @@ import Input from 'terra-form-input';
const NumberInputExample = () => (
<div>
<Field label="Numeric Input" htmlFor="numeric">
<Input name="number input" placeholder="Enter Digits" id="numeric" type="number" ariaLabel="Numeric Input" />
<Input name="number input" id="numeric" type="number" ariaLabel="Numeric Input" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The number example in input field was updated to provide help text when the placeholder was removed, we should probably to the same here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will necessary as this may mislead users to use Input and FormField as separate components rather than directly consuming InputField.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example is already using the FormField component

Copy link
Member

@neilpfeiffer neilpfeiffer Jul 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Stephen, I made this new issue #3084 to remove the Fields as part of the raw examples for our text-input, so users do not get confused what they are seeing and testing on this page. The use of Field here is now duplicative, since these example originally did not have the example template housing it, which now provides its own title and descriptions.

As part of our best practice UX Audits, it was identified that UX would like to showcase the InputField and other Field componsitions as the primary form components, and then either move or segment raw building block components, like the solo input element component, into a separate location. See: UX Audit: terra-form-input

@@ -24,6 +23,8 @@ import FormInputPropsTable from 'terra-form-input/src/Input?dev-site-props-table

Generic input which represents an HTML input element directly.

**Note:** To follow UX Best Practices, this component does not allow `placeholder`.
Copy link
Contributor

@StephenEsser StephenEsser Jul 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At some point we should have a writeup about why we made this decision and link out to it here (and anywhere else this note is written)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added link to w3 Placeholder Research in Note section.

Comment on lines 24 to 26
* `Input` component will not be supporting `placeholder` prop and `native placeholder`. If consumers want to provide a detailed text guidance they can upgrade to `InputField`.

* `InputField` component will not be supporting `placeholder` prop and `native placeholder`. But consumers can provide a help text using the `help` prop.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should provide more guidance on what the upgrade entails for these sections.

If consumers want to provide a detailed text guidance they can upgrade to InputField .....

After switching to an InputField a consumer may utilize the help text field properties to provide similar guidance to the user. If we have any UX design standards/recommendations this may be a good place to mention a few of those details.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update here ad81efd.

Copy link
Contributor

@StephenEsser StephenEsser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on the code changes. I think adding some detailed documentation prior to releasing will help users transition and understand the changes.

@@ -145,7 +140,6 @@ const InputField = (props) => {
labelAttrs,
maxWidth,
onChange,
placeholder,
Copy link
Contributor

@benbcai benbcai Jul 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should placeholder also be deleted from the customProps just like in Input.jsx if we outright disallow it? Otherwise, it would get spread onto FormField.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update here ad81efd.

Copy link
Contributor

@tbiethman tbiethman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this'll be good to go once Ben's comment is addressed.

@@ -137,7 +132,6 @@ const TextareaField = (props) => {
required,
showOptional,
onChange,
placeholder,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as this comment: #3075 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update here ad81efd

@mjhenkes mjhenkes temporarily deployed to terra-core-deployed-pr-3075 July 20, 2020 19:57 Inactive
@pranav300
Copy link
Contributor Author

pranav300 commented Jul 20, 2020

Do not merge this PR until placeholder has been removed from search-field(PR #3078)

@mjhenkes mjhenkes temporarily deployed to terra-core-deployed-pr-3075 July 22, 2020 17:51 Inactive
@neilpfeiffer
Copy link
Member

neilpfeiffer commented Jul 22, 2020

Tested: PR #3075
Resolves: Issue #2992 along with #3078

Reviewed:

  • Follows pattern considerations documented in Cerner Design Standards: Text Input, Text Area and Input Field
  • Follows UX defined design implementation for Input & Textarea
  • Follows defined theme designs: terra-default-theme, orion-fusion-theme, clinical-lowlight-theme


Related Updates (also will be updating usage of placeholders):
terra-core: issue #3083
terra-clinical: issue #680
terra-framework: issue #1193



Verified by @neilpfeiffer, ready to merge after #3078,

Pass
UX Review

@neilpfeiffer neilpfeiffer added ⭐ UX Reviewed UX Reviewed and approved. and removed UX Review Ready labels Jul 22, 2020
@mjhenkes mjhenkes temporarily deployed to terra-core-deployed-pr-3075 July 22, 2020 22:42 Inactive
@mjhenkes mjhenkes merged commit 9d2d436 into main Jul 23, 2020
@mjhenkes mjhenkes deleted the remove-placeholder-from-input-and-textarea branch July 23, 2020 13:28
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[terra-form-input] Insufficient color-contrast for placeholder
8 participants