This is a follow-up to #704, which was closed without a resolution. Re-raising it here with an additional related proposal (quick-option suggestions), since both address the same underlying gap: shape authors currently have no way to hint at an example or likely value for an empty field without that value being enforced, derived, or committed to a closed enumeration.
1. shui:placeholder — inline placeholder text
Request for a shui:placeholder that specifies a string value to display when a property lacks a current value.
- Strictly not an actual enforced, derived, or default value for that property — unlike
sh:defaultValue or sh:hasValue.
- Likely only meaningful for
PropertyShapes without sh:node, or with sh:nodeKind of IRI or a literal (i.e. single-value, text-like widgets such as shui:TextFieldEditor / shui:IRIEditor), rather than blank-node or nested-form fields.
- Maps cleanly to the HTML
<input placeholder="example@example.com"> attribute, so it's trivial for shui:TextFieldEditor/shui:IRIEditor implementations to support.
2. Quick-option / suggestion values below the field
A lighter-weight companion to shui:searchQuery and, more distantly, dash:propertySuggestionGenerator: a static (or simply-derived) list of candidate values a renderer can display as clickable "quick option" chips beneath a field, letting the user fill the field in one click.
- Not a validity constraint — unlike
sh:in / shui:EnumSelectEditor, which restrict the property to only the listed values, these are just suggestions; the user remains free to enter something else.
- No live query/search step required, unlike
shui:searchQuery, which is designed for dynamic, typed-input-driven lookups. This is closer to a small, precomputed candidate set.
- Exact term is open —
shui:suggestedValues, shui:quickOptions, or similar — happy to defer to WG naming conventions.
Where this might fit
The spec currently has an open placeholder section, "Enumerations, Select Lists, and Autocomplete", marked TODO, which explicitly calls out the need to "distinguish static enumerations from dynamic lookups." Both proposals above seem like natural additions to that section and to the Built-in Widgets list (as new widget-score criteria for shui:TextFieldEditor etc.), rather than new top-level sections.
Happy to help draft the syntax rules / scoring criteria if there's WG interest.
This is a follow-up to #704, which was closed without a resolution. Re-raising it here with an additional related proposal (quick-option suggestions), since both address the same underlying gap: shape authors currently have no way to hint at an example or likely value for an empty field without that value being enforced, derived, or committed to a closed enumeration.
1.
shui:placeholder— inline placeholder textRequest for a
shui:placeholderthat specifies a string value to display when a property lacks a current value.sh:defaultValueorsh:hasValue.PropertyShapes withoutsh:node, or withsh:nodeKindofIRIor a literal (i.e. single-value, text-like widgets such asshui:TextFieldEditor/shui:IRIEditor), rather than blank-node or nested-form fields.<input placeholder="example@example.com">attribute, so it's trivial forshui:TextFieldEditor/shui:IRIEditorimplementations to support.2. Quick-option / suggestion values below the field
A lighter-weight companion to
shui:searchQueryand, more distantly,dash:propertySuggestionGenerator: a static (or simply-derived) list of candidate values a renderer can display as clickable "quick option" chips beneath a field, letting the user fill the field in one click.sh:in/shui:EnumSelectEditor, which restrict the property to only the listed values, these are just suggestions; the user remains free to enter something else.shui:searchQuery, which is designed for dynamic, typed-input-driven lookups. This is closer to a small, precomputed candidate set.shui:suggestedValues,shui:quickOptions, or similar — happy to defer to WG naming conventions.Where this might fit
The spec currently has an open placeholder section, "Enumerations, Select Lists, and Autocomplete", marked TODO, which explicitly calls out the need to "distinguish static enumerations from dynamic lookups." Both proposals above seem like natural additions to that section and to the Built-in Widgets list (as new widget-score criteria for
shui:TextFieldEditoretc.), rather than new top-level sections.Happy to help draft the syntax rules / scoring criteria if there's WG interest.