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

Change styles dropdown behavior for enabling styles #12416

Closed
scofalik opened this issue Sep 6, 2022 · 4 comments
Closed

Change styles dropdown behavior for enabling styles #12416

scofalik opened this issue Sep 6, 2022 · 4 comments
Labels
package:style resolution:expired This issue was closed due to lack of feedback. status:stale type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@scofalik
Copy link
Contributor

scofalik commented Sep 6, 2022

📝 Provide a description of the improvement

Originally reported in + context: https://github.com/ckeditor/ckeditor5/pull/12160#issuecomment-1237246940

Currently, styles dropdown works as follows:

  1. Enabled styles are styles that can be selected from the dropdown (and -- by assumption -- applied).
  2. Enabled styles are taken only from the first selected block element and all its ancestors.
  3. If a selection spans over bigger chunk of content, the enabled styles might be confusing:
    1. For example, let's say you have a mix of headings + paragraphs.
    2. Only heading styles are enabled as the first element is heading.
    3. Applying heading style won't have an effect on paragraphs.
    4. If you wanted to change paragraphs styles, you can't do this.
    5. You may wonder, why headings styles (not applicable to paragraphs) are enabled but paragraph styles (not applicable to headings) are not?
  4. Current solution is the worst of two worlds: it's neither precise nor flexible.

I propose two solutions:

  1. Enable all styles that are applicable to any of the selected elements. This one I like more. You can Ctrl + A and transform all paragraphs to given style and you won't be limited by having heading as the first element. I like this one more.
  2. Enable only styles that are applicable to all of the selected elements. This is more precise. Non-applicable styles cannot be chosen anymore, so you won't be confused that part of the selection didn't change after applying a style. But in reality, if you select multiple elements, in most cases all block styles will be disabled. This is why I don't like this solution.
@scofalik scofalik added type:improvement This issue reports a possible enhancement of an existing feature. package:style labels Sep 6, 2022
@oleq
Copy link
Member

oleq commented Sep 6, 2022

I agree that the current UX is confusing. I also suppose this is closely related to #11579.

I propose two solutions:

We may consider either of these as a quick fix.

Honestly though, I'd rather make the feature able to rename elements in the model and act like style feature in almost any popular desktop text processor. For instance, you could select [ heading, paragraph, image, paragraph ] choose "Fancy paragraph" and turn it all into [ fancy paragraph, fancy paragraph, image, fancy paragraph ] retaining the content inside. That would require a lot of work, though.

@scofalik
Copy link
Contributor Author

scofalik commented Sep 6, 2022

☝️ I agree with you. I thought it was a product decision that we do not want to rename elements.

@CKEditorBot
Copy link
Collaborator

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

@CKEditorBot
Copy link
Collaborator

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).

@CKEditorBot CKEditorBot added the resolution:expired This issue was closed due to lack of feedback. label Nov 1, 2023
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:style resolution:expired This issue was closed due to lack of feedback. status:stale type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

No branches or pull requests

3 participants