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
Is your feature request related to a problem? Please describe.
I have the editor in a form which manages progression such that the user cannot skip fields - this is done mostly by disabling future inputs. With native input elements, we have a distinction between readonly and disabled wherein the latter prevents focus events from either a mouse or keyboard. With the Stacks-Editor, we have a readonly property which can be set using disable()/enable(). The mix in language is not only confusing but for my purposes above, readonly alone is insufficient to stop users from navigating through the editor's internal elements (i.e. the toolbar items) via TAB keyboard navigation (despite stopping focus via mouse).
Describe the solution you'd like
I would like to have a disabled state which holds similar behavior to a regular ol' <input disabled ... /> and is separate from the readonly state. Specifically, if disabled, the editor should not be focusable and when navigating through a parent form via TAB, the editor should be skipped.
I'd expect navigation behavior similar to native HTML inputs like attempting to tab through the following:
readonly should change to have its own modifiers to avoid confusion.
Describe alternatives you've considered
Without this functionality inside of Stacks-Editor, I can add event listeners and hijack TAB-key events but that quickly snowballs to handling the editor in different states, moving between interactive elements inside of the editor like the toolbar and content, and then doing it all over again for SHIFT + TAB to go in reverse.
Additional context
Could be a breaking change in that ideally pre-existing disable()/enable() would be used to modify the disable state rather than readonly.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I have the editor in a form which manages progression such that the user cannot skip fields - this is done mostly by disabling future inputs. With native
input
elements, we have a distinction betweenreadonly
anddisabled
wherein the latter prevents focus events from either a mouse or keyboard. With the Stacks-Editor, we have areadonly
property which can be set usingdisable()/enable()
. The mix in language is not only confusing but for my purposes above,readonly
alone is insufficient to stop users from navigating through the editor's internal elements (i.e. the toolbar items) viaTAB
keyboard navigation (despite stopping focus via mouse).Describe the solution you'd like
I would like to have a
disabled
state which holds similar behavior to a regular ol'<input disabled ... />
and is separate from thereadonly
state. Specifically, if disabled, the editor should not be focusable and when navigating through a parent form viaTAB
, the editor should be skipped.I'd expect navigation behavior similar to native HTML inputs like attempting to tab through the following:
Proposal
readonly
should change to have its own modifiers to avoid confusion.Describe alternatives you've considered
Without this functionality inside of Stacks-Editor, I can add event listeners and hijack
TAB
-key events but that quickly snowballs to handling the editor in different states, moving between interactive elements inside of the editor like the toolbar and content, and then doing it all over again forSHIFT + TAB
to go in reverse.Additional context
Could be a breaking change in that ideally pre-existing
disable()/enable()
would be used to modify the disable state rather thanreadonly
.The text was updated successfully, but these errors were encountered: