Posted by & filed under Forms.


The PatternFly team is working to define recommendations for the placement and functionality of syntax hints as they are used in forms.

The focus for this user story

This user story includes discovery and exploration around recommendations for globally universal field inputs; such as character counts, types of characters allowed, urls, and email addresses, just to name a few. The team will also define guidelines on syntax hints usage: When are they needed? In what scenarios would they distract a user from completing their task?

What is out of scope?

We’ve seen a lot of interesting questions come up on the PatternFly email list around syntax hints. This is a complex topic with lots of variables and we will address some of these issues in a later user story, for example:

  • Local standards for syntax, including:
    • Phone numbers
    • Mailing address
    • IP address
    • Naming fields (first name/last name, surname, family name, etc)
  • When to explain how input data is used (help) vs. showing the user the format that data must be in (syntax)
  • When do we use data validation instead of syntax hints?

While we won’t address every issue related to syntax hints, the solution in this user story should consider other design patterns for forms already in use, such as Errors and Validation, Field Level Help, and Form Field Layouts.

Discovery Phase

During our discussions and research, we found a few design solutions to consider:

Option 1: Placeholder syntax hints




  • Uses limited vertical space, making the form easier to scan quickly
  • Limits the need for information recall because the syntax hint disappears only after the user starts typing, not when the field is clicked
  • Layout can easily be used for responsive websites. Placeholder syntax hints don’t require layout adjustments for mobile or tablet devices.


  • If used on all fields, the form could be visually overwhelming
  • Contrast will be a challenge. We will need to be consider how to balance hierarchy between the label, input field, and hint text
  • Length of syntax text will be limited to character count of form field
  • It will be difficult for users to confirm the correctness of their responses before submitting the form if syntax hints disappear after user input
  • Placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers

Option 2: Syntax hints below input field



  • Allows fields to remain empty, drawing attention to empty fields and encouraging completion
  • Hints are always visible, reducing strain on short term memory and chance of user error
  • Layout can easily be used for responsive websites.


  • Increases vertical length of the form
  • If used on all fields, the form could be visually overwhelming – reducing completion rates and increasing user errors
  • Maintaining typographic hierarchy through font size and contrast could be challenging.

Option 3: Syntax hints in-line with form field



  • Additional vertical space needed in form layout is minimal
  • Length of hints is flexible, allowing for clear instructions that may be longer in length
  • Keeps user focus on empty form fields, encouraging completion


  • Translating this layout to mobile would require using responsive breakpoints, forcing the layout to change
  • Typographic contrast could be challenging. The hierarchy between label, input field, and hint text will need to be considered.
  • The horizontal layout will increase the time it takes users to scan the page because of additional eye movement

Next steps

Since we are in the early phase of exploring this topic, we’d love to hear your input. Do you have a preference for one of the three options above? What scenarios do you think we should use syntax hints?

Leave a Reply

(will not be published)