You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a usecase where a user has to choose a node in a tree structure.
I could represent that choice as a select/radio input but it could grow too big and it would be nicer if the real tree structure was shown in the form (instead of an flattened structure).
I would prefer to keep select/radio as input type over a new/custom one (tree) because select/radio are standard and degrade gracefully if the client would not know about the new (non-standard) type.
Therefore, I need some extra information about how my input could be rendered.
Is there anything in the current spec that would allow me to do that?
there is nothing built into the spec right now to handle this, i think.
however, if you'd like to build up a working extension that would be backward compatible, that'd be a great first step.
one you have a working vesrion to share, we can talk about whether it becomes a listed extension and, if it gets uptake, eventually moves along to become a feature at some future point.
I have a usecase where a user has to choose a node in a tree structure.
I could represent that choice as a select/radio input but it could grow too big and it would be nicer if the real tree structure was shown in the form (instead of an flattened structure).
I would prefer to keep select/radio as input type over a new/custom one (tree) because select/radio are standard and degrade gracefully if the client would not know about the new (non-standard) type.
Therefore, I need some extra information about how my input could be rendered.
Is there anything in the current spec that would allow me to do that?
I had something like this in mind:
The text was updated successfully, but these errors were encountered: