- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I'm working on a Workspace form and configured a Client Script to add a placeholder text to a multi-line String field (description).
The script works as expected (the text disappears when typing and reappears when cleared also it's not saved), but the field's default height is too small for the placeholder text. Because of this, the text gets cut off, requiring users to either scroll or manually resize the field by dragging the bottom-right corner.
Is there a standard way to ensure the field automatically displays at a height that fits the entire placeholder text without manual resizing?
I tried with the following attributes:
edge_encryption_enabled=true,rows=100I also tried adding this plus code to the client script which i use to populate the field with:
function onLoad() {
// 1. setting up placeholder(this works without any issue):
var placeholderText = getMessage('your_description_placeholder_key');
g_form.setFieldPlaceholder('rich_description', placeholderText);
// 2. finding the field and overwriting the CSS
var control = g_form.getControl('rich_description');
if (control) {
control.style.setProperty('--now-textarea--field-height', '20rem', 'important');
control.style.setProperty('min-height', '320px', 'important');
var parentComponent = control.closest('now-textarea');
if (parentComponent) {
parentComponent.style.setProperty('--now-textarea--field-height', '20rem', 'important');
}
}
}
This is how it looks
This is how big it should be by default without me dragging the field to the correct size.
Any advice or best practices would be greatly appreciated!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @BenceZ
The now-textarea component used by Workspace does support configurable height, rows and auto-resizing, but those properties are not normally exposed for an individual String field when it is rendered through the standard Workspace Record Form. This is also why adding rows=100 as a dictionary attribute does not necessarily affect the Workspace rendering.
I would avoid manipulating the component with g_form.getControl() and CSS because this depends on the rendered Workspace component implementation and is not a maintainable solution.
In this use case, the better design is to keep the placeholder short and place the longer instructions in helper text, an annotation, or informational text directly above the Description field.
ServiceNow’s Horizon guidance specifically recommends using body/helper text when the placeholder contains too much guidance.
If a larger text area is an absolute requirement, a standalone now-textarea can be added through UI Builder/custom component and configured with properties such as rows, autoresize, and resize.
However, you would then need to bind that component to the record field yourself, so this is more customisation than I would recommend purely to accommodate a long placeholder.
If my response helped, please mark it as correct and close the thread, this helps future readers find the solution faster!!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I don't think any solution is available for this
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @BenceZ ,
Unfortunately, there isn't an out-of-the-box way to automatically resize a multi-line String field in Workspace based on the placeholder text. The rows dictionary attribute and CSS overrides that work in the classic UI are generally not respected by the Now Experience textarea component used in Workspace.
A few options you can consider:
If the field is a Multi-line Text field, check whether the dictionary supports a default row count. This may work in some contexts but is not consistently honored in Workspace.
Avoid relying on client-side CSS overrides (g_form.getControl().style...), as the Workspace components use Shadow DOM/CSS variables that are often reset during rendering.
If a larger default height is a strict requirement, the recommended approach is to customize the field using UI Builder or create a custom Now Experience component where you can control the textarea height.
Based on your example, your placeholder implementation is correct—the limitation is the Workspace form component itself. If you need the field to always open at a larger height, a UI Builder customization is likely the most reliable solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @BenceZ
The now-textarea component used by Workspace does support configurable height, rows and auto-resizing, but those properties are not normally exposed for an individual String field when it is rendered through the standard Workspace Record Form. This is also why adding rows=100 as a dictionary attribute does not necessarily affect the Workspace rendering.
I would avoid manipulating the component with g_form.getControl() and CSS because this depends on the rendered Workspace component implementation and is not a maintainable solution.
In this use case, the better design is to keep the placeholder short and place the longer instructions in helper text, an annotation, or informational text directly above the Description field.
ServiceNow’s Horizon guidance specifically recommends using body/helper text when the placeholder contains too much guidance.
If a larger text area is an absolute requirement, a standalone now-textarea can be added through UI Builder/custom component and configured with properties such as rows, autoresize, and resize.
However, you would then need to bind that component to the record field yourself, so this is more customisation than I would recommend purely to accommodate a long placeholder.
If my response helped, please mark it as correct and close the thread, this helps future readers find the solution faster!!!