There is a pretty major usability issue relating to how textboxes interact with the WYSIWYG.
The Issue
There is currently no way to change the type of textbox you want for a given selection, and if you try to change it the text ends up in a broken state that can only be fixed by carefully editing the HTML through the text editor view.
To reproduce this, try adding a textbox to a selection of text. Then, select the same text and try to change the type of textbox using the textbox drop down menu. Instead of changing the type of textbox used, it adds an additional textbox between the existing text and the exiting textbox. Using the “clear formatting” button only works on textboxes without headers, and breaks the text further when used on textboxes with headers. I don’t think there is a real world use case for the current behavior (nested textboxes) and it seems non-intentional.
This issue can be somewhat insidious because there are some textbox combination that look intentional. So, when you have more than one person working on a text and decide to change which textbox selection to use, one person might think they are changing the textbox type when they are really making franken-boxes. Fixing those nested textboxes is time intensive and error-prone because it involves making manual adjustments to HTML.
Developing a Solution
Because error recovery is a major factor in usability, addressing this will be a priority for us. A common pattern I’ve seen before is to first check to see if the group class (in this case textbox) is present, and, if so, replace any styling sub-classes (e.g., textbox--sidebar) with the new selection’s styling classes, and this is where I wanted to start. However, I noticed that not all of the textbox styling classes use the leading textbox--, (shaded does not). So, instead of looking for classes that start with textbox-- I’ll need to remove all classes from the textbox div and replace them with classes from the new selection.
But I wanted to double-check to see if there is any other component that would add a class to the div created by the textbox button. So, can I safely assume that all classes for the div that contains textbox are related to the textbox selection? (Aside–I think the best solution would be to always use textbox-- to lead all classes inserted by the textbox selection and textbox__ to lead all textbox heading classes, but that would make our fork harder to maintain unless it was adopted upstream.)
Switching between textbox options with headers to textbox options without them will be the next issue to address (e.g., switching from [standard|shaded] to [examples|exercises|key takeaways|learning objectives]), but I wanted to get a sanity check on my general solution and flag the issue first.
Thanks,
Alex