Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Support nested list indentation limit #1332

Open
richardtagger opened this issue Oct 13, 2022 · 2 comments
Open

Feature request: Support nested list indentation limit #1332

richardtagger opened this issue Oct 13, 2022 · 2 comments

Comments

@richardtagger
Copy link

We only support 3 levels of nesting in our lists at Yammer. We have implemented custom content correction to flatten any list items that indent too deeply. I'd like to request Rooster handle this natively so all we need to do is supply a config option. We have no requirements that vary between UL vs OL type of lists so unsure if you want to separate those out in your config expression. We also don't support mixing list types so that simplifies things for us somewhat. Whatever the solution it should ensure the content in the editor is never nested beyond some pre-defined limit whether that's via pasting, tabbing, using indent button etc. Our patch solution uses query selectors on content change to detect levels of nesting and re-arrange the DOM to move LI's up a level until they're not past the max depth - there is likely a better way to do this internally within Rooster. It may also be easier to preserve document selection / cursor anchor + focus positions.

@romanisa
Copy link
Contributor

@richardtagger This feature asks demands a full spec in order to specify what will happen to the list levels that exceed the limit. For eg: what happens when user presses a tab key after 3rd level of list, or what happens when user pastes content that has more levels. Is there a PM that can spec all the cases?
Also, if there is somebody from your team who wants to implement this feature in Rooster, you are more than welcome and we are happy to support.
Otherwise, we can take up the feature ourselves based on the spec and our team's bandwidth.

@richardtagger
Copy link
Author

Sure thing - I've asked a PM here to spec this out and we'll circle back :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants